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

# MCP Test Kitchen

A hosted MCP server that fails on command, so you can watch what your client does when a server misbehaves.

The MCP Test Server answers the Model Context Protocol (MCP) and gets things wrong on purpose. You pick a failure, point your client at one endpoint and run the task you would run against a healthy server. The server writes down every request it saw.

It does not tell you whether your client is correct. It tells you what your client did.

***

## Why This Exists

MCP puts failures in two places. A protocol error arrives in the response's `error` field. A tool execution error arrives inside `result`, flagged with `isError: true`, carried on an HTTP 200. Anything watching status codes reads the second one as a success, and so does every dashboard downstream of it.

Failures also arrive late. A server that breaks on every call gets caught on the first run. The one that costs you a morning worked four times first.

You cannot arrange either condition against a healthy server, and you cannot see your own client's side of the exchange from inside your own client. That is the gap this server fills.

***

## How You Use It

1. Sign in and pick a scenario in the console.
2. Point your MCP client at the endpoint with your access token.
3. Run the task you would run against a working server.
4. Read the record the server kept, then read what your client showed the user.

The distance between those last two is the finding. A [Quickstart](/start-here/quickstart.md) run takes about five minutes.

***

## What Ships

[Six scenarios](/scenarios/scenarios.md), each breaking a different layer: HTTP transport, the JSON-RPC envelope, the tool result, server to client elicitation requests and the protocol revision itself. One of them breaks nothing and exists as the control case.

Every session also advertises four always on catalog items, so you can exercise `resources/read` and `prompts/get` against valid and schema invalid responses without changing your scenario.

The [record](/reading-the-record/record.md) holds one entry per request, with the headers your client sent, the protocol revision it declared and how long the server took. Entries are scoped to your account and deleted after seven days.

***

## What It Will Not Do

* **Return a verdict.** No pass, no fail, no score. The [official conformance suite](https://github.com/modelcontextprotocol/conformance) answers that question and needs a server that behaves.
* **Test your server.** The direction is fixed: this server misbehaves, your client responds. [MCP Inspector](https://github.com/modelcontextprotocol/inspector) works the other way round.
* **Break the network.** Every failure here is a well formed HTTP response. Resets, truncated bodies and TLS failures need a proxy, not a server.

The full list is in [Scope and Limits](/reference/scope-and-limits.md), and every scenario page closes on its own.

***

## Start Here

| If you want to                  | Go to                                               |
| ------------------------------- | --------------------------------------------------- |
| Get a first record on screen    | [Quickstart](/start-here/quickstart.md)             |
| Wire up your own client         | [Connect a Client](/start-here/connect-a-client.md) |
| Understand how scenarios behave | [How Scenarios Work](/scenarios/scenarios.md)       |
| Read what the server captured   | [Reading the Record](/reading-the-record/record.md) |