> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allgoodhq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tool reference

> Every action the allGood ERM MCP can take: look at configurations, manage Test Suite cases, run the suite, and edit a draft.

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](/use-cases/erm-mcp/workflows).

New to MCP, or wondering what connecting it does? See the [Overview](/use-cases/erm-mcp/index) first.

***

## Before you start

The ERM MCP must be active in your conversation. See [Using with Claude Desktop](/use-cases/erm-mcp/claude-desktop) or [Using with ChatGPT Desktop](/use-cases/erm-mcp/chatgpt-desktop) for setup.

Each tool needs one of two permissions:

| Permission | Tools |
| - | - |
| **View reply management** | Everything under *Looking at your configuration*, plus listing test cases and reading suite results |
| **Manage reply management** | Creating and updating test cases, creating and editing a draft, and running the suite |

<Note>
  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?](/use-cases/erm-mcp/faq#can-i-control-which-actions-need-my-approval-first) in the FAQ.
</Note>

## 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?"*

<Note>
  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.
</Note>

***

## 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](/use-cases/erm/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?"*

<Tip>
  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.
</Tip>

### 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](mailto:sarah.chen@acme.com) as the replacement, and check both fields."*

<Note>
  - 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.
</Note>

### 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."*

<Warning>
  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](/use-cases/erm/test-suite) page in the web app.
</Warning>

***

## 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?"*

<Note>
  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](mailto:support@allgoodhq.com) if they persist.
</Note>

***

## 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."*

<Note>
  A new draft has an empty Test Suite. Copy the live suite over before re-running, or the re-run will tell you nothing.
</Note>

### 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."*

<Warning>
  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.
</Warning>

<Danger>
  Nothing here publishes the draft. Review it in the allGood web app and promote it yourself when you're satisfied.
</Danger>

***

## Related articles

* [Overview](/use-cases/erm-mcp/index)
* [Guided workflows](/use-cases/erm-mcp/workflows)
* [ERM MCP FAQ](/use-cases/erm-mcp/faq)
* [Test Suite](/use-cases/erm/test-suite)
* [Categories](/use-cases/erm/categories)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.