> For the complete documentation index, see [llms.txt](https://docs.flowcp.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flowcp.ai/guides/test-your-mcp-server.md).

# Test your MCP server

Before you publish, run the **Tests** page to confirm every capability your MCP server exposes — tools, authentication, skills, widgets, and prompts — registers correctly. The suite runs entirely against your server's configuration, so it is safe to run as often as you like and never makes a live API call on a user's behalf.

## Running the tests

1. Open your app and go to **Servers**.
2. Click **Test** on the server (branch) you want to check. The suite runs automatically when the page opens.
3. Review the results. Click **Run tests** at any time to re-run after you make a change.

Each check reports one of four outcomes:

* **Passed** — the capability registers cleanly.
* **Failed** — the capability is broken or unsafe to publish. Fix it before publishing.
* **Warning** — the capability registers, but something may not behave as you expect (for example, a tool missing a description). Publishing is still allowed.
* **Skipped** — there was nothing to check (for example, no skills configured).

## What the suite checks

| Check                                  | Category       | Fails when                                                                         |
| -------------------------------------- | -------------- | ---------------------------------------------------------------------------------- |
| At least one tool is enabled           | Tools          | No tools are enabled — the server would expose nothing.                            |
| Tool input schemas are valid           | Tools          | A tool's stored input schema can't be turned into a valid MCP schema.              |
| Tools have descriptions                | Tools          | *(Warning)* An enabled tool has no description for AI clients to read.             |
| Authentication is configured           | Authentication | The server's auth mode has no usable credential (e.g. OAuth config or API key).    |
| Destructive tools require confirmation | Safety         | An enabled `destructive` tool can run without **Require confirmation**.            |
| Skills are valid                       | Skills         | An enabled skill has an empty body. *(Warning)* a skill name collides with a tool. |
| Widgets are valid                      | Widgets        | An enabled widget has empty HTML. *(Warning)* a tool links a disabled widget.      |
| Prompts are valid                      | Prompts        | An enabled prompt has an empty body.                                               |

## Live conformance checks

The checks above are **static** — they read your server's configuration. The **Conformance** checks go one step further: they open a real MCP session against your **published** server's runtime and confirm that what the runtime actually registers matches what you configured.

| Check                                | Category    | Fails when                                                     |
| ------------------------------------ | ----------- | -------------------------------------------------------------- |
| Runtime handshake succeeds           | Conformance | The runtime won't accept an MCP session for this server.       |
| Tools register at runtime            | Conformance | An enabled tool (or a skill's `skill_…` tool) doesn't appear.  |
| Prompts register at runtime          | Conformance | An enabled prompt doesn't appear in the runtime's prompt list. |
| Skills & widgets register at runtime | Conformance | An enabled widget or skill resource doesn't appear.            |

These checks only issue read-only protocol calls (`initialize` and the capability `…/list` methods) — they **never invoke a tool**, so like the static suite they make no upstream API call and have no side effects.

Conformance checks run only for a **published** server (the runtime serves published branches). For a draft branch they report **Skipped** with a "publish to run" note. If the runtime is temporarily unreachable, they also report **Skipped** rather than failing — a transient outage never looks like a broken server. Because of that, conformance results are **not** publish-critical: they surface real registration problems but never block the publish gate.

## Publish readiness

The summary banner tells you whether the server is ready to publish. The **publish-critical** checks are:

* At least one tool is enabled
* Tool input schemas are valid
* Authentication is configured
* Destructive tools require confirmation

If all four pass, the server clears the publish gate and you can head to the [Publish page](/guides/publish-your-mcp-server.md). Warnings never block publishing, but they are worth resolving so your tools behave the way AI clients expect.

## Go further: catch response-shape regressions

The Tests page confirms your capabilities *register* correctly. To also catch an upstream API silently changing a tool's **response shape**, record [golden scenarios](/guides/golden-scenario-replay.md) for your read-only tools and replay them after a change.

## Go further: chat-test in the Playground

The Tests page confirms your capabilities *register* correctly without making any live calls. To watch a real model *use* your tools end to end — making live requests in your own authorization context — open the [Playground](/guides/chat-test-your-mcp-server.md).