01
Any client, any protocol version
No wrapper, no subprocess. Any client that accepts a URL and an Authorization header can be tested, including clients that do not run as a command you can start from a shell.
MCP 2026-07-28 · Stateless · Legacy clients welcome
Every MCP client is tested against a server that behaves. Ours doesn't.
A hosted MCP server that fails on purpose, open source under the MIT License. Paste the endpoint and a bearer token into the client you already run. No wrapper, no subprocess, no code changes.
# Run the reference test client
npm start
Connected (protocol 2026-07-28, era modern)
Tools (1):
- run_configured_test_scenario: MCP Test Server fixture. Runs the active test scenario…
# Tool error scenario, armed for invocation 1
{"scenarioId":"errors.tool_error","invocation":1,"errorMessage":"Tool-side failure"}
Why we built it
We had no way to test what our client does when a server gets it wrong.
We were building an MCP gateway of our own. Testing it against first-class MCP servers went fine at first and then stopped going fine: elicitation was redesigned under us and client support went uneven, and the servers we were testing against offered no resources and no prompts at all, so there was nothing to exercise those against.
A correct server will not misbehave on request, and it cannot expose what it does not have. We needed one that does both, so we built it (internally nicknamed the WTF Simulator) and then made it public.
What you get
Everything you need to test your MCP stack.
Connect a client over HTTP, select a fault scenario and read the request log. The server and a TypeScript reference client are both public on GitHub under the MIT License.
02
Fault injection scenarios
Faults land at different layers of the MCP stack: HTTP transport errors, JSON-RPC error envelopes and tool-level isError results. Each layer breaks a client in a different way. The JSON-RPC and tool error scenarios can be armed for a specific call, so the first invocation succeeds and the second fails: the case a fixed mock cannot express.
03
Live Messages panel
One row per request: time, status, duration, method, the active scenario and the protocol revision the client declared. Open a row for the rest: request id, status code, whether it cancelled and the headers with every sensitive value redacted. Tool-call arguments are dropped, not recorded. The panel streams while you test and filters by date, category, phase or caller.
04
MIT-licensed reference client
A TypeScript reference client pinned to protocol 2026-07-28, public on GitHub under the MIT License. Read it, clone it, copy what you need into your own code.
Scenario catalog
Tool scenarios
Six scenarios ship today. Pick one, save it and it applies to your next connection.
Baseline
Baseline (success)
Answers normally, with an optional delay before returning. The control case.
A correct client completes the call and renders the result. If the delay trips a timeout you never configured, you have already learned something.
C# SDK v2
C# SDK v2 backward compatibility
Tests whether your client handles the new revision's multi round-trip requests or falls back to the older path. This is the one scenario that exposes four tools rather than one. The catalog is set when the connection is established and does not change while you are connected.
A correct client either completes the round trip or falls back to the older path and says which.
Elicitation
Elicitation approval
Calls elicitation so your client can prompt a person before continuing.
A correct client puts the question to a person and returns the answer. A client that cannot do elicitation should say so plainly, not hang and not quietly continue without an answer.
HTTP & protocol errors
HTTP transport error
Returns a configured sequence of status codes across successive requests, so the failure sits below MCP.
A correct client treats this as a transport failure, retries or stops and never presents it as a tool result. The body is empty, so anything it claims to have read came from somewhere else.
HTTP & protocol errors
JSON-RPC error
Returns HTTP 200 with an error object in the body, on the call you name.
A correct client reads the envelope rather than the status code, and surfaces the error. A client that trusts the 200 will report success on a call that failed.
HTTP & protocol errors
Tool error (isError)
Returns a valid result carrying isError on the call you name, so the failure sits inside a success.
A correct client checks the flag, treats the call as failed and passes the message on to the model or the person. Everything about the response looks fine except the one field that matters.
Always on
Resources & prompts
On their own tabs, always on for every session, no scenario configuration. Each ships a valid and an invalid variant: valid_resource / invalid_resource, valid_prompt / invalid_prompt.
The invalid ones are advertised normally and then answer with a payload that does not match the schema they announced.
Setup
How to run it
Use the copy we host, or run your own from the public repository.
Hosted
- Sign in to the console with Google or GitHub.
- Copy your personal access token.
- Pick a scenario and set its parameters.
If you have no client to point at it yet, the console generates a working TypeScript client wired to the endpoint.
For which scenario to pick first, what the log columns mean and how to read the result, read How to use the MCP Test Kitchen.
Client config
{
"mcpServers": {
"mcp-test-kitchen": {
"url": "https://mcp-test-kitchen.cakewalk.security/mcp",
"headers": { "Authorization": "Bearer <your-token>" }
}
}
}Run it yourself
The server is open source under the MIT License. Docker Compose builds the image and starts the server, the console and Postgres on your machine. Docker is all the quick start needs.
The console signs you in with Google or GitHub, so a local copy needs an OAuth app of your own. Without one, the MCP endpoint still answers to a shared development token, but the console stays locked and you cannot pick a scenario.
Run your own copy to keep test traffic on your machine or to add new scenarios. Configuration and a guide to adding scenarios are in the README.
Quick start
git clone https://github.com/cakewalk-security/cakewalk-mcp-test-kitchen
cd cakewalk-mcp-test-kitchen
cp docker-compose.override.yml.template-mac docker-compose.override.yml
docker compose up --build
# MCP endpoint: http://localhost:5094/mcpOn Linux or Windows, copy the -linux or -win template instead.
What you need to know
Frequently asked questions
General
What is the MCP Test Kitchen?
A fault-injection sandbox built on the MCP 2026-07-28 spec. You point a client at it, select a fault scenario and observe how the client handles the failure.
What is the Model Context Protocol?
The open protocol for connecting AI applications to tools and data sources. Specification: modelcontextprotocol.io.
How is this different from the other MCP testing tools?
Most of them point the other way. MCPJam Inspector, MCP Playground and the MCP Inspector are all clients you drive by hand to test a server you are building: browse its tools, call them, read the JSON-RPC log. The thing under test is the server. Here the server is the instrument and your client is the thing under test.
The official conformance suite does test clients, but it asks a different question: whether your client follows the spec. This asks what your client does when the server does not: a malformed payload, a transport error, a failure inside the tool result.
One overlap that is easy to assume: the suite does carry backward-compatibility scenarios, but there are exactly two of them and both are OAuth, covering metadata discovery and endpoint fallback against the 2025-03-26 spec. Neither asks what a client does when the server answers on an older protocol revision. That is what our C# SDK v2 scenario tests, so it is not covered there.
The mechanism differs too. The conformance CLI tests a client by launching it: you supply a command, and it appends the server URL as an argument. The client under test has to be startable from a shell with a URL, which is why the repo targets SDK maintainers and ships a GitHub Action for SDK CI. This is a hosted endpoint, so nothing is launched.
And the honest concession: nothing here is magic. A misbehaving server is a few hundred lines, and if you would rather run your own you should. What you get by using ours is that you do not have to write and maintain the faults, and that the log tells you what your client actually sent.
Run both. They do not overlap.
Do I need to change my client's code?
No. You paste an endpoint and a bearer token into the MCP server config your client already has. No SDK integration, no CLI wrapper, no build step, no subprocess.
Why do I need to sign in?
Signing in with Google or GitHub mints a personal access token and ties it to the scenario you selected. The server needs that to know which fault to inject on your next connection, and to attribute each recorded request to an account.
We ask for your email address and nothing else. No name, no avatar, no repository access and we do not store the provider's tokens. Your sign-in email is recorded with your requests and is not used for marketing.
Do I have to use your client?
No. Connect an existing client, or clone the public reference client and run it locally.
Protocol versions
Do I need to upgrade my client first?
No. The server answers on both revisions now in circulation (2025-11-25 and 2026-07-28), so you can point the same scenario at each and compare. On both, over the stateless transport: a 2025-11-25 client gets down-level guidance rather than a refusal.
Is the transport stateless?
Yes. The server cannot bridge state across a live connection, so stateful paths stay out of scope. A 2026-07-28 client opens with server/discover; a 2025-11-25 client opens with initialize, and that difference decides which path runs and what the log keeps.
How does the server know which revision my client speaks?
Your client declares one, and the server records it on every row of the log. A client sends whatever its SDK defaults to, which may differ from what you configured and that is what decides which path runs.
Which clients can connect?
Any client that accepts a URL and an Authorization header. That includes the MCP Inspector, which is what we connected first and clients you cannot start from a command line.
Scenarios
Which fault scenarios are available?
On the Tools tab: Baseline (success), C# SDK v2 backward compatibility, Elicitation approval, HTTP transport error, JSON-RPC error and Tool error (isError). One is active at a time, applied to your next connection. Resources and prompts are always on, need no scenario configuration and each ships a valid and an invalid variant.
What does the server record while I test?
One row per request, carrying the method, the phase, the status, the duration, a summary of the parameters your client sent, whether it cancelled and the protocol revision it declared. Tool-call arguments are dropped rather than recorded. The full list is under "What do you log?" below.
Reference client
What is the reference test client?
A TypeScript reference client pinned to protocol 2026-07-28, shipped with full source.
Is the server itself open source?
Yes. The server, its console and its scenarios are public on GitHub under the MIT License: github.com/cakewalk-security/cakewalk-mcp-test-kitchen. You can read the code, run your own copy or add a scenario.
The TypeScript reference client is separate. It is public on GitHub under the MIT License.
Can I run it myself?
Yes. The repository at github.com/cakewalk-security/cakewalk-mcp-test-kitchen has a Docker quick start that runs the server, the console and Postgres on your machine. Console sign-in needs a Google or GitHub OAuth app of your own. Without one, only the MCP endpoint works.
Cost and data
Is it free?
Yes, and there is no time limit on that. No card, no trial, no usage tier.
See the Data page for everything else the service does and does not do with what you send it.
How long do you keep my records?
Seven days, then they are deleted. Pull anything you want to keep into your own tracker before that.
The Data page has the full retention and deletion detail, including what the erase button does and does not reach.
Where does it run?
Amsterdam. The service and its database are in the EU and your records are stored there.
One exception: feedback you submit in the console goes out through a US email provider. The Data page spells that out.
Do you track me?
No. No analytics, no error tracking, no session recording, no third-party scripts. Sign-in talks to Google and GitHub, feedback goes out by email and that is the whole list.
The Data page has the rest of what we hold.
What do you log?
One row per request: the method, the phase, the status, the duration, whether you cancelled, the protocol revision your client declared, the scenario that was active and the email you signed in with.
Parameters are summarised rather than captured. On a tool call we keep the tool name and drop the arguments entirely. On a legacy connection we keep the protocol version and your client's name and version. Any other params are kept only if they are 512 characters or fewer. We never store response bodies.
Six header values are kept by allowlist: accept, content-type, content-length, host, user-agent, mcp-protocol-version. Every other value is replaced with [redacted], so the value of your Authorization header is never recorded. Header names are kept, values are not.
None of that is a reason to send us anything real. Use synthetic data.
How do I delete my data?
The console has an ERASE EVERYTHING button. It permanently deletes your observations, your saved scenario, your MCP access token and your live sessions and signs you out. It cannot be undone. We hold no separate account record, so those rows are everything of yours we have.
One thing it cannot do: revoke this app's access to your Google or GitHub account. That lives on their side and you have to remove it there.
Are there rate limits?
Yes. 120 requests a minute on the MCP endpoint, partitioned by IP and a 429 if you go over. Console actions are limited separately: 30 a minute for token operations and 5 per ten minutes for feedback and for erasure.
How do I send feedback?
There is a feedback box in the console, up to 2000 characters.
Feedback is the one thing on this service that leaves the EU: it goes out through Resend, a US email provider, which keeps the message about 30 days. ERASE EVERYTHING does not reach it. Do not put anything in the box you would not put in an email.
See how your client handles a misbehaving server.
Sign in with Google or GitHub, copy your access token, then select a scenario and point a client at the endpoint. Free, and you can erase everything in one click when you are done.
MCP Test Kitchen was built by the engineers at Cakewalk, where we work on agent access and permissions. We ship an MCP client of our own, and a client that mishandles what a server sends it is not only a bug: it is a guardrail that did not hold. We needed a server that gets it wrong on demand, so we built one. Read the full story or learn about Cakewalk.