Skip to main content
Once the allGood ERM MCP is connected, you can do everything below directly in conversation. Tools are grouped by what they do. For end-to-end recipes that combine them, see Guided workflows. New to MCP, or wondering what connecting it does? See the Overview first.

​
Before you start

The ERM MCP must be active in your conversation. See Using with Claude Desktop or Using with ChatGPT Desktop for setup. Each tool needs one of two permissions:
Every tool can be set individually to run automatically, ask you first, or be turned off. See Can I control which actions need my approval first? in the FAQ.

​
Live, draft, and the Test Suite

Three ideas explain most of how these tools behave.
  • Live vs. draft. A live configuration is what’s classifying your mail right now. A draft is a full copy you can edit safely. The ERM MCP only edits drafts. You publish a draft yourself in the web app.
  • Each version has its own Test Suite. A new draft starts with no test cases, even though it’s a copy of the live categories. To test a draft, copy the live suite over first. The guided workflows do this for you.
  • Runs are asynchronous. Running the suite starts it and returns straight away. You then check the results until it finishes.

​
Looking at your configuration

​
List configurations

What it does: Lists the Email Reply Management configurations in your workspace, with each one’s name, status, whether it’s a draft (and which live configuration it belongs to), and how many categories it has. When to use it: Start here to find the configuration you want to work on, or to check whether a draft already exists. Example prompts:
  • “List my reply management configurations.”
  • “Is there already a draft of our main configuration?”

​
Get a configuration

What it does: Returns one configuration in full: its status, draft information, and every category with its definition, flags, extract fields, and actions. When to use it: Before changing anything, and whenever you want a category explained or compared. Example prompts:
  • “Show me the categories in configuration QU8RSBZL.”
  • “Which categories have extract fields, and what do they extract?”
A category’s flags (Spam, Bounce, Out of Office, Auto Response, Other) tell the assistant how serious a mistake involving that category is. A category with no flags is treated as a real human reply, so burying one of those is the costliest mistake.

​
Working with the Test Suite

A test case is an example reply, plus the category it should land in and, optionally, the values that should be extracted from it. See Test Suite for how this looks in the web app.

​
List test cases

What it does: Lists the test cases in a configuration’s suite, a page at a time, with the latest result for each. By default it returns a lightweight summary (name and latest pass, fail, or error). Ask for full detail to also see each case’s email, expected result, checks, and what the model actually produced. When to use it: To see what your suite already covers, to find stale cases, or to read specific failures in depth. Example prompts:
  • “How many test cases does the draft have, and how many are failing?”
  • “Show me the full detail of the failing cases from that last run.”
  • “Which categories have fewer than three test cases?”
Large suites come back in pages. The assistant keeps fetching pages automatically, so counts and coverage summaries cover the whole suite, not just the first page.

​
Create a test case

What it does: Adds a new test case to a configuration’s suite. Each test case has:
  • A name, such as “Left Company, with replacement contact”
  • The email: body (required), and optionally subject, from, and to
  • The expected category
  • Checks: categorize, and optionally extract
  • Expected extracted values (only when checking extraction), and for each value whether to compare it exactly or by meaning
When to use it: To cover a category that has no examples, to turn a real misclassified reply into a regression test, or to add an edge case you’ve seen in production. Example prompts:
  • “Add a test case where someone replies ‘please remove me from your list’ and make sure it lands in Unsubscribe.”
  • “Write a Left Company test where the reply names Sarah Chen at sarah.chen@acme.com as the replacement, and check both fields.”
  • Use exact matching for structured values like emails and IDs. Use by meaning for names, dates, and free text the model may reword.
  • Every expected extracted value must be a real value. To say a field isn’t present in the email, leave it out rather than expecting an empty value.
  • Skip your catch-all Other category. It’s meant to be a leftover bucket, so tests for it tend to be flaky. The guided workflow skips it for you.

​
Update a test case

What it does: Changes an existing test case. You only provide the parts that change (its name, email, expected result, or checks). Everything else stays as it was. When to use it: When an expected category is wrong, an email isn’t realistic, or a comparison should be by meaning instead of exact. Example prompts:
  • “Change the expected category on that test from Other to Left Company.”
  • “Make the name comparison on the Sarah Chen test semantic instead of exact.”
Test case changes apply immediately. There’s no tool to delete a test case, so remove ones you no longer want from the Test Suite page in the web app.

​
Running the suite and reading results

​
Run the test suite

What it does: Runs every test case in a configuration’s suite against either the live or the draft version. It starts the run and returns right away. Nothing is sent to anyone: the run is offline. When to use it: To get a baseline before you change anything, to check the effect of a draft edit, or after adding new test cases to confirm they pass. Example prompts:
  • “Run the test suite against the live configuration.”
  • “Re-run the suite on the draft and compare it to the last run.”

​
Get suite results

What it does: Summarizes a run: total, passed, failed, errored, and not yet run, whether the run is still in progress, and the list of currently failing cases. When to use it: After starting a run, to see when it’s finished and how it went. The assistant checks every 10 to 15 seconds until the run completes. Example prompts:
  • “How did that run go?”
  • “What’s our accuracy now compared to before the change?”
A failed case means the model gave a wrong answer. An errored case means something went wrong running it (not the model’s answer). Report errors to allGood support if they persist.

​
Editing a draft

​
Create a draft

What it does: Makes a full, editable copy of a live configuration, without affecting the live one. Returns the draft’s ID, which is what you use for every later step. When to use it: Once you know what you want to change. You can only have one draft per live configuration. This fails if the configuration is already a draft, or already has one. Example prompts:
  • “Create a draft of configuration QU8RSBZL so we can try some fixes.”
A new draft has an empty Test Suite. Copy the live suite over before re-running, or the re-run will tell you nothing.

​
Update a draft

What it does: Changes the categories on a draft: a category’s definition, its extract fields, and its actions. It refuses to touch a live configuration. When to use it: To tighten a category’s definition, fix an extract field, or adjust what happens when a category matches. Example prompts:
  • “Update the Left Company definition so a named replacement contact in the signature still counts as Left Company.”
This replaces the whole list of categories on the draft, not just the ones you mention. The assistant always starts from the full current list and changes only what you approved, so categories it doesn’t mention are kept. Review the before and after text it shows you before agreeing.
Nothing here publishes the draft. Review it in the allGood web app and promote it yourself when you’re satisfied.