# MCP Playground — Full Content > Complete text of every tool page plus the guide library for MCP Playground (https://mcpplaygroundonline.com), a free browser-based toolkit for the Model Context Protocol. Test any remote MCP server, run evals that prove an AI agent can use its tools, build agents across 70+ models, and audit servers for security issues. Contents: 11 tool and landing pages (in full), 114 guides, 41 curated MCP server pages, 51 agent templates. Curated index: https://mcpplaygroundonline.com/llms.txt · Any page also renders as Markdown at its own URL with `.md` appended, or via `Accept: text/markdown`. --- # Part 1 — Tools # MCP Playground — Test MCP Servers Online, Free > A free browser-based toolkit for the Model Context Protocol. Connect to any remote MCP server, inspect and call its tools, run evals against 70+ AI models, and audit it for security issues — without installing anything. **Source:** https://mcpplaygroundonline.com/ --- ## What this site is for If you are building or consuming an MCP server, these are the questions this site answers: - **Does my MCP server work at all?** → [MCP Server Tester](https://mcpplaygroundonline.com/mcp-server-tester) — connect, list tools/prompts/resources, call them with real arguments, watch the raw JSON-RPC. - **Can an AI agent actually use my server?** → [MCP Evals](https://mcpplaygroundonline.com/mcp-evals) — auto-generated test suites that prove an agent can answer real questions with your tools. - **Does it behave the same across models?** → [MCP Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio) — run the same server against 70+ models and compare tool-selection behaviour side by side. - **Is it safe to expose?** → [MCP Security Scanner](https://mcpplaygroundonline.com/mcp-security-scanner) — 35+ checks across transport, auth, protocol compliance, injection and disclosure, graded A–F. - **Is my MCP *client* correct?** → [MCP Test Client](https://mcpplaygroundonline.com/mcp-test-client) and [Mock MCP Servers](https://mcpplaygroundonline.com/mock-mcp-servers) — six hosted servers with public URLs, including deliberate-failure endpoints. ## Tools - [MCP Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio) — browser AI agent over any MCP server, 70+ models, saved agents, live tool-call inspection, eval runs. - [MCP Server Tester](https://mcpplaygroundonline.com/mcp-server-tester) — validate schemas and exercise `tools/call` before you ship. - [MCP Inspector Online](https://mcpplaygroundonline.com/mcp-inspector-online) — the MCP Inspector without `npx`, Node, or local setup. - [MCP Evals](https://mcpplaygroundonline.com/mcp-evals) — generated eval suites with deterministic checks plus model-graded agentic tasks. - [MCP Security Scanner](https://mcpplaygroundonline.com/mcp-security-scanner) — graded security audit of any MCP server URL. - [MCP Test Client](https://mcpplaygroundonline.com/mcp-test-client) — validate a client implementation against hosted mock servers. - [Mock MCP Servers](https://mcpplaygroundonline.com/mock-mcp-servers) — six free public MCP endpoints, no sign-up. - [MCP Agent Templates](https://mcpplaygroundonline.com/templates) — 51 ready-to-run agents for Notion, GitHub, Jira, Sentry, Stripe, Linear, Slack, Supabase and more. - [MCP Server Registry](https://mcpplaygroundonline.com/mcp-registry) — searchable directory of MCP servers, with 41 hand-written setup pages. - [MCP With Different AI Models](https://mcpplaygroundonline.com/mcp-model-comparison) — which models support MCP and how their tool calling differs. ## Machine-readable index - [https://mcpplaygroundonline.com/llms.txt](https://mcpplaygroundonline.com/llms.txt) — curated index of every tool and guide. - [https://mcpplaygroundonline.com/llms-full.txt](https://mcpplaygroundonline.com/llms-full.txt) — the tool pages and top guides inlined in full. - Append `.md` to any blog or server-page URL, or send `Accept: text/markdown`, for a clean Markdown rendering. --- _Canonical page: https://mcpplaygroundonline.com/_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # MCP Agent Studio — Run Evals & Test MCP Servers with AI Models > Run any hosted or remote MCP server against 70+ AI models in your browser — Claude, GPT-5, Gemini, DeepSeek, Grok, Qwen and more. Auto-generate evals that prove an agent can answer using your tools, compare models side by side, and save reusable agents. No install. **Source:** https://mcpplaygroundonline.com/mcp-agent-studio --- ## What it does Agent Studio is a browser-based MCP client with a model picker. You paste an MCP server URL, choose a model, and chat. Every tool call is shown inline with its full JSON input and output, so you can see exactly which tool the model picked, what arguments it constructed, and what came back. Nothing is installed. There is no local Node process, no `npx`, and no config file — the connection is made from the browser session. ## Why the model matters The same MCP server behaves differently depending on which model is driving it. Anthropic's API is the only one that speaks MCP natively; every other provider reaches MCP tools through a translation layer. That means tool-selection quality, argument construction, and error recovery all vary by model — and a server that works perfectly in Claude Desktop can fail against GPT or Gemini for reasons that have nothing to do with your code. Agent Studio exists to make that difference visible. Run the same prompt against 70+ models and compare which one picks the right tool. **Model families available:** - Claude (Anthropic) - GPT (OpenAI) - Gemini and Gemma (Google) - DeepSeek - Grok (xAI) - Qwen (Alibaba) - GLM (Z.AI) - Kimi (Moonshot) - MiniMax - Nemotron (NVIDIA) - Mistral ## MCP evals Evals answer a different question than a tester does. A tester tells you the server responds; an eval tells you an *agent can actually accomplish something* with it. Agent Studio reads every tool on your server, writes a test suite from the real schemas, and runs it. The suite has two halves: - **Direct checks — decided deterministically by code.** Output-schema conformance, JSON-RPC error codes, pagination behaviour, result caps, idempotency. No model judges these; they pass or fail on the response. - **Agentic tasks — driven by one model, graded by another.** A realistic question is posed to an agent connected to your server; a second model grades whether the answer is actually supported by the tool output. The result is a pass/fail report per tool, with evidence attached to each result. Re-run the same suite after a change to see what regressed. Full walkthrough: [https://mcpplaygroundonline.com/mcp-evals](https://mcpplaygroundonline.com/mcp-evals) ## What people build with it - Run an eval suite against your own MCP server and find the tool an agent cannot use, before your users do - Chat with a Postgres or Supabase database in plain English, without writing SQL - Triage Sentry errors, find the offending commit, and draft a fix - Run Amazon Ads, Meta Ads or LinkedIn Ads campaigns from chat - Manage Linear, Jira or Asana sprints conversationally - Query HubSpot or Salesforce with natural language - Inspect a Shopify store, Stripe billing or Vercel deployments without leaving the chat - Compare Claude vs GPT-5 vs Gemini on the same MCP task to find the cheapest model that still succeeds ## Getting started 1. Open [https://mcpplaygroundonline.com/mcp-agent-studio](https://mcpplaygroundonline.com/mcp-agent-studio). 2. Paste your MCP server URL, or start from a [template](https://mcpplaygroundonline.com/templates) if you are connecting to a service like Notion, GitHub or Stripe. 3. Pick a model and start chatting. Sign-up grants free credits. No MCP server of your own yet? Use one of the [hosted mock servers](https://mcpplaygroundonline.com/mock-mcp-servers) — they are public URLs that need no sign-up. ## Frequently asked questions ### What is MCP Agent Studio? MCP Agent Studio is a browser-based AI agent that connects to any Model Context Protocol (MCP) server and lets you query your data in plain English using 60+ AI models including Claude, GPT-5, Gemini, DeepSeek, Mistral, Grok, Qwen, NVIDIA Nemotron, and more. It also runs evals against your server — an auto-generated test suite that proves an AI agent can actually answer questions using your tools. Sign up for free — no credit card required. ### What are MCP evals and how do they work? An eval is a test that checks whether an AI agent can complete a real task using your MCP server. MCP Agent Studio connects to your server, reads every tool and its schema, and writes an eval suite for you. Running the suite has four phases: connect (handshake and tool discovery), harvest (pull real values from read-only tools so the tasks use genuine data), run (a driver model works your tools like a real client would), and score (grade the answers). Direct evals are decided deterministically by code — schema conformance, JSON-RPC error codes, pagination termination, result caps, idempotency — so a failure is a confirmed defect, not a model opinion. Agentic evals send a plain-English task through the driver model and a scoring model grades the final answer. ### How do I test if my MCP server actually works with an AI agent? Paste your server URL into the Evals workspace and run a suite. Instead of eyeballing a tool list in an inspector, you get a pass/fail report per tool with the evidence behind each verdict: the arguments that were sent, the raw response, and which check tripped. Typical failures it catches are tool descriptions too vague for the model to pick the right tool, list endpoints that ignore their own limit parameter, missing-record cases that return null instead of an error, and agent loops that burn dozens of calls without answering. ### Do evals call destructive tools on my server? No. Tools are classified before anything runs — read-only, idempotent, unknown, or destructive. Anything that could mutate or delete your data is excluded from the run and reported as "untestable" rather than being quietly called, and you review and approve the tool list before the suite is generated. Mutation checks are proved indirectly with a read-only witness tool instead. ### Can I re-run the same eval suite after I change my server? Yes. Suites are saved against your organization and versioned, so you can replay one after every schema change and compare the new report against the last run. Writing a suite is charged once per version; replaying it only costs the run, which is why regression checks stay cheap. You can also add your own assertions in plain English alongside the generated ones. ### Do I need to write code to use MCP Agent Studio? No. MCP Agent Studio is a no-code interface. You paste your MCP server URL, pick an AI model, and start chatting. The agent discovers the available tools automatically and calls them for you as needed. ### Which AI models can I use with MCP Agent Studio? You can use 60+ models from every major provider, including Claude Opus 4.6, Claude Sonnet 4.6, GPT-5.4, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4, Mistral Small 2603, Grok 4.6, Qwen 3, NVIDIA Nemotron Super 120B, Google Gemma 4, Z.AI GLM 4.5 Air, and more. You can switch models mid-conversation to compare responses on the same task. ### What is an MCP server and do I need one? An MCP server is a lightweight service that exposes tools (functions, database queries, API calls) over the Model Context Protocol so any AI agent can use them. Popular public MCP servers include GitHub, Supabase, Notion, Slack, Stripe, Postgres, Linear, and Playwright. You can also connect your own custom MCP server over HTTP, SSE, or Streamable HTTP. ### How does pricing work? MCP Agent Studio is free to sign up — no credit card required. Running AI models costs credits, which you can purchase in packs from your Settings page. New accounts may receive a small starter credit to try the product. Credit costs vary by model; check the Settings › Credits page for current pricing. ### Can I query my own database with MCP Agent Studio? Yes. Connect the official Postgres or Supabase MCP server (or any MCP server that wraps your database) and ask questions in plain English: "Show me my top 10 customers by revenue this month." The AI generates the SQL, runs it through the MCP server, and returns the results with a natural-language summary. ### How is this different from ChatGPT or Claude Desktop? Claude Desktop only works with Claude. ChatGPT only works with OpenAI models. MCP Agent Studio works with any model from any provider — swap between Claude, GPT, Gemini, DeepSeek, and Grok on the same MCP server without re-configuring anything. It also runs entirely in your browser with no local installation. ### Can I run an MCP server with GPT-5? Yes. MCP Agent Studio connects any MCP server (HTTP, SSE, or Streamable HTTP) to GPT-5.4, GPT-5.5, GPT-5 mini, and the rest of the GPT-5 family. Paste your server URL, pick the model, and every tool call streams live — no OpenAI SDK or glue code required. ### Which AI model is best for MCP tool calling? It depends on your server. Claude Sonnet 4.6 and Opus 4.6 are the strongest default tool-callers; GPT-5.4 leads on structured outputs; Gemini 3.1 Pro handles long tool lists; DeepSeek V4 and GLM 5.1 are the budget picks. Compare Mode in MCP Agent Studio scores all of them on your actual server. ### Is there a hosted MCP server URL I can test with? Yes. Official hosted endpoints include Notion (https://mcp.notion.com/mcp), Stripe (https://mcp.stripe.com/), GitHub (https://api.githubcopilot.com/mcp/), Linear (https://mcp.linear.app/sse), and Sentry (https://mcp.sentry.dev/mcp). Paste any of them into MCP Agent Studio, or deploy your own sandboxed hosted MCP server with a live URL in under a minute. ### How do I connect to a remote or hosted MCP server? Paste the server URL into MCP Agent Studio, add an auth token if the server requires one, and click connect — the agent lists the tools automatically. Remote HTTP, SSE, and Streamable HTTP transports are all supported, entirely in the browser with nothing to install. ### Can I use the GitHub MCP server with Claude? Yes — and with GPT-5, Gemini, Grok, or any of 60+ models. MCP Agent Studio connects the official GitHub MCP server (https://api.githubcopilot.com/mcp/) to whichever model you pick, so you can review PRs or triage issues with Claude and re-run the same prompt on GPT-5 to compare. ### Does MCP work with Gemini? Yes. The Model Context Protocol is model-agnostic, and MCP Agent Studio acts as a Gemini MCP client: connect any server and run it with Gemini 3.1 Pro or Gemini 3 Flash. Gemini Flash is one of the cheapest models that still calls MCP tools reliably. ### Is my data secure? Your MCP server credentials stay in your browser session and are never stored on our servers. Conversations are scoped to your Supabase-authenticated organization. We never train on your data, and you can delete your history at any time from Settings. ### Can I compare multiple AI models on the same task? Yes — this is one of the core reasons people use MCP Agent Studio. Run the same prompt against Claude, GPT-5, and Gemini side by side, inspect every tool call in the live trace panel, and find the cheapest model that still gives great results. Teams routinely cut inference costs 5–10× this way. ### What MCP servers work with Agent Studio? Any MCP server that speaks HTTP, SSE, or Streamable HTTP. That includes official servers for GitHub, Supabase, Postgres, Notion, Slack, Stripe, Linear, Playwright, Filesystem, Memory, Sequential Thinking, and hundreds of community servers. You can also point it at your own custom server deployed on Cloudflare Workers, Vercel, Fly, or anywhere else. ### Do you have pre-built templates I can use? Yes. MCP Agent Studio ships with ready-to-run templates covering Notion, GitHub, Amazon Ads, Jira, Confluence, Sentry, HubSpot, Stripe, Linear, Slack, Supabase, Vercel, Shopify, Cloudflare, Zapier, and more — including multi-server combos like GitHub + Vercel + Sentry and Amazon Ads + Stripe for blended ROAS. Pick a template, add your access token, and start chatting in seconds. Browse all templates at /templates. ### Can I save an agent configuration and reuse it? Yes. Once you set up a model, one or more MCP servers, and a system prompt, you can save the whole configuration as a named agent with one click. Open it again any time from "My Agents" — your servers, tools and model selection are all restored. Agents can be private or shared with your team. ### Can I export my agent as code? Export is coming soon. Save your agent and open Export in the studio toolbar to preview a Next.js App Router layout or a Python starter (MCP wiring, prompts, .env.example, deploy targets). Downloadable ZIP packs and one-click deploy will ship in a follow-up release; until then you can explore the preview and recreate wiring manually if you self-host. --- _Canonical page: https://mcpplaygroundonline.com/mcp-agent-studio_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # MCP Server Tester — Validate Your MCP Server Before You Ship > Free browser-based MCP server tester. Validate tool schemas, exercise `tools/call` with real arguments, watch raw JSON-RPC frames, and catch protocol bugs before you publish. **Source:** https://mcpplaygroundonline.com/mcp-server-tester --- ## Who this is for MCP server *developers* — people who are writing a server and need to know it is correct before it reaches a client. If you want to drive someone else's server with an AI agent instead, use [Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio). ## What it checks - **Connection and handshake** — does `initialize` succeed, and what capabilities does the server negotiate? - **Discovery** — `tools/list`, `prompts/list`, `resources/list`, including pagination. - **Tool schemas** — are the declared input schemas well-formed and complete enough for a model to construct arguments from? - **Execution** — call any tool with arguments you supply and inspect the full result. - **Raw protocol** — every JSON-RPC frame, in both directions, as it goes over the wire. This is usually where the real bug is. ## Why raw frames matter Most MCP bugs are not logic bugs, they are protocol bugs: a malformed `content` array, a missing `isError`, a tool result that is technically valid JSON-RPC but unusable by a model. A client that hides the frames hides the bug. This tester shows them. ## Typical workflow 1. Paste your server URL (http or SSE transport). 2. Confirm the handshake and check the negotiated capabilities. 3. Walk the tool list and read each schema as a model would see it. 4. Call the tools that matter with realistic arguments. 5. When it passes here, run [evals](https://mcpplaygroundonline.com/mcp-evals) to confirm an agent can actually use it, and the [security scanner](https://mcpplaygroundonline.com/mcp-security-scanner) before you expose it publicly. ## Related - [MCP Inspector Online](https://mcpplaygroundonline.com/mcp-inspector-online) — same connection, framed as the browser equivalent of `npx @modelcontextprotocol/inspector`. - [MCP Test Client](https://mcpplaygroundonline.com/mcp-test-client) — the inverse: validate a *client* against hosted mock servers. - [Mock MCP Servers](https://mcpplaygroundonline.com/mock-mcp-servers) — known-good and known-bad endpoints to test your tooling against. --- _Canonical page: https://mcpplaygroundonline.com/mcp-server-tester_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # MCP Inspector Online — Browser Alternative to npx @modelcontextprotocol/inspector > The MCP Inspector, online. Connect to any remote MCP server in the browser, inspect tools, prompts and resources, view raw JSON-RPC frames, and call tools with custom arguments. No npx, no Node, no local setup. **Source:** https://mcpplaygroundonline.com/mcp-inspector-online --- ## The problem this solves The official inspector is run with `npx @modelcontextprotocol/inspector`. That requires Node on the machine, a terminal, and a local port — which is fine on your laptop and awkward everywhere else: a locked-down work machine, a phone, a code review, a support thread where you want a colleague to reproduce something in one click. This is the same inspection surface, reachable from a URL. ## What you get - Connect to any **remote** MCP server over http or SSE - Browse tools, prompts and resources with their full schemas - Call any tool with arguments you construct - Read every raw JSON-RPC request and response - Share the session context by sharing the URL — no "install Node first" preamble ## What it cannot do Local **stdio** servers are out of reach from a browser tab: stdio means a child process on your machine, and a web page cannot spawn one. For a stdio server, either run the official inspector locally, or put an http transport in front of it and point this at that. ## Related - [MCP Server Tester](https://mcpplaygroundonline.com/mcp-server-tester) — the same connection, framed around validating a server you are building. - [MCP Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio) — drive the server with a real AI model instead of calling tools by hand. - [Mock MCP Servers](https://mcpplaygroundonline.com/mock-mcp-servers) — public URLs to point the inspector at right now. --- _Canonical page: https://mcpplaygroundonline.com/mcp-inspector-online_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # MCP Evals — Test Whether an AI Agent Can Actually Use Your MCP Server > Generated eval suites for MCP servers. Direct checks are decided deterministically by code; agentic tasks are driven by one model and graded by another. Get a pass/fail report per tool, with evidence. **Source:** https://mcpplaygroundonline.com/mcp-evals --- ## Why a tester is not enough A server tester answers "does this respond correctly?". That is necessary and not sufficient. The failure mode that actually hurts is different: the server responds perfectly, and the agent still cannot use it — because a tool description is ambiguous, a schema does not say which field is required, an error is returned as a 200 with prose in it, or two tools are indistinguishable from their names. None of that shows up in a protocol check. It shows up the first time a real user asks a real question. ## How the suite is built The eval generator reads every tool on your server and writes a suite from the **real schemas** — not from a template, and not from a description you wrote by hand. That matters because the suite is testing exactly what a model would see. ## The two halves **Direct checks — graded by code, not by a model.** These are deterministic and repeatable: - Output-schema conformance - JSON-RPC error codes (is a failure actually reported as a failure?) - Pagination behaviour - Result caps and truncation - Idempotency **Agentic tasks — one model acts, another grades.** A realistic question is put to an agent connected to your server. A separate grading model then judges whether the answer is genuinely supported by the tool output, rather than guessed around it. This is the half that catches ambiguous descriptions and unusable schemas. ## What you get back A pass/fail report per tool, with the evidence attached — the actual calls, arguments and responses behind each verdict. Re-run the same suite after changing your server to see precisely what regressed. ## Safety Evals are generated from your tool schemas, so read-only servers stay read-only. Review the generated suite before running it against a server with destructive tools — the same caution you would apply to any test suite that talks to a live system. Run one at [https://mcpplaygroundonline.com/mcp-agent-studio](https://mcpplaygroundonline.com/mcp-agent-studio). --- _Canonical page: https://mcpplaygroundonline.com/mcp-evals_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # MCP Security Scanner — Free Online MCP Server Security Audit > Runs 35+ checks against any MCP server URL across transport security, authentication, protocol compliance, injection risk, information disclosure, CORS policy, security headers and rate limiting. Graded A–F in seconds. **Source:** https://mcpplaygroundonline.com/mcp-security-scanner --- ## What it scans - **Transport security** — TLS posture and downgrade exposure - **Authentication** — is the server actually protected, and does it challenge correctly? - **MCP protocol compliance** — spec conformance issues that become security issues - **Injection risk** — prompt-injection and tool-poisoning surface in tool descriptions and results - **Information disclosure** — what leaks in errors, metadata and verbose responses - **CORS policy** — who is allowed to talk to this server from a browser - **Security headers** - **Rate limiting** ## Stateless 2026-07-28 coverage The scanner supports the stateless 2026-07-28 revision, including checks specific to it: **`requestState` tampering** and **cache-scope leaks**. These are new classes of issue that did not exist in the session-based model — state that used to live on the server now travels with the request, so its integrity and its scoping both become attack surface. ## Why MCP servers need this specifically An MCP server is not just an API — it is an API that an autonomous agent will call with arguments it constructed itself, based on descriptions you wrote. That widens the threat model: a tool description is an input to a model, which makes it an injection vector. A permissive CORS policy on a normal API is a nuisance; on an MCP server holding a user's tokens it is an exfiltration path. ## Using it Paste a server URL at [https://mcpplaygroundonline.com/mcp-security-scanner](https://mcpplaygroundonline.com/mcp-security-scanner) and read the graded report. It is free and needs no sign-up. Scan servers you own or are authorised to test. --- _Canonical page: https://mcpplaygroundonline.com/mcp-security-scanner_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # MCP Test Client — Validate Any MCP Client Against Hosted Mock Servers > Validate an MCP client implementation against six hosted mock servers in the browser — echo, Bearer auth, deliberate errors, complex nested schemas, MCP Apps `ui://` resources, and the stateless 2026-07-28 revision. No install, no API key. **Source:** https://mcpplaygroundonline.com/mcp-test-client --- ## The inverse problem Most MCP tooling helps you test a *server*. This helps you test a *client* — the thing doing the connecting. To do that you need servers that behave in known ways, including behaving badly on purpose. ## What gets exercised - **Connection lifecycle** — `initialize`, capability negotiation, shutdown - **Capability negotiation** — does your client correctly honour what the server declares? - **Tool discovery** — listing and pagination - **Error handling** — the part that is almost never tested until production - **Authentication** — 401 handling and Bearer-token retry ## The mock servers behind it - **Echo server** (`https://mcpplaygroundonline.com/mcp-echo-server`) — A single `echo` tool, no authentication. The simplest possible connectivity check. (Temporarily offline.) - **Auth server** (`https://mcpplaygroundonline.com/mcp-auth-server`) — Returns 401 with a `WWW-Authenticate` challenge until a Bearer token is supplied. Use it to exercise a client's auth flow. - **Error server** (`https://mcpplaygroundonline.com/mcp-error-server`) — Returns validation, not_found, rate_limit, timeout and five more error types on demand, so you can test how a client surfaces failures. - **Complex server** (`https://mcpplaygroundonline.com/mcp-complex-server`) — Four deeply-nested tool schemas. Use it to test tool selection and argument construction under realistic schema pressure. - **MCP Apps server** (`https://mcpplaygroundonline.com/mcp-app-server`) — Returns a `ui://` MCP Apps resource, for clients that render interactive tool output. - **Stateless 2026-07-28 server** (`https://mcpplaygroundonline.com/mcp-stateless-server`) — Multi Round-Trip Requests and signed `requestState` from the 2026-07-28 revision. Every endpoint serves both the stateless 2026-07-28 revision and the 2025-era `initialize` handshake. Append `?rev=2026-07-28` or `?rev=2025-11-25` to pin one and test your rejection paths. These are public URLs — see [Mock MCP Servers](https://mcpplaygroundonline.com/mock-mcp-servers) to use them directly from your own test suite, curl, or any other MCP client. --- _Canonical page: https://mcpplaygroundonline.com/mcp-test-client_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # Mock MCP Servers — Free Public MCP Server URLs for Testing > Six free hosted mock MCP servers with public URLs you can paste into any MCP client — echo, Bearer auth (401), deliberate errors, complex nested schemas, MCP Apps `ui://` resources, and a stateless 2026-07-28 server. No install, no sign-up, no API key. **Source:** https://mcpplaygroundonline.com/mock-mcp-servers --- ## The endpoints These are real, publicly reachable MCP servers. Paste them into Claude Desktop, Cursor, your own client, or curl. No account, no key, no rate-limit signup. ### Echo server `https://mcpplaygroundonline.com/mcp-echo-server` A single `echo` tool, no authentication. The simplest possible connectivity check. (Temporarily offline.) ### Auth server `https://mcpplaygroundonline.com/mcp-auth-server` Returns 401 with a `WWW-Authenticate` challenge until a Bearer token is supplied. Use it to exercise a client's auth flow. ### Error server `https://mcpplaygroundonline.com/mcp-error-server` Returns validation, not_found, rate_limit, timeout and five more error types on demand, so you can test how a client surfaces failures. ### Complex server `https://mcpplaygroundonline.com/mcp-complex-server` Four deeply-nested tool schemas. Use it to test tool selection and argument construction under realistic schema pressure. ### MCP Apps server `https://mcpplaygroundonline.com/mcp-app-server` Returns a `ui://` MCP Apps resource, for clients that render interactive tool output. ### Stateless 2026-07-28 server `https://mcpplaygroundonline.com/mcp-stateless-server` Multi Round-Trip Requests and signed `requestState` from the 2026-07-28 revision. ## Protocol revision pinning Every endpoint above serves **both** the stateless 2026-07-28 revision and the 2025-era `initialize` handshake, negotiated normally. To force one, append a query parameter: - `?rev=2026-07-28` — pin the stateless revision - `?rev=2025-11-25` — pin the session-based revision Pinning is how you test rejection paths: point a 2025-only client at a `?rev=2026-07-28` endpoint and confirm it fails the way you expect, rather than failing silently. ## What each one is for - Building a client and need a known-good target → **echo** - Implementing OAuth/Bearer flows → **auth** (returns a real `WWW-Authenticate` challenge) - Testing how your UI surfaces failures → **error** (nine error types on demand) - Testing tool selection and argument construction → **complex** (deeply nested schemas) - Rendering interactive tool output → **MCP Apps** (`ui://` resource) - Migrating to the 2026 spec → **stateless** (Multi Round-Trip Requests, signed `requestState`) To drive these from a UI instead of your own code, use the [MCP Test Client](https://mcpplaygroundonline.com/mcp-test-client). --- _Canonical page: https://mcpplaygroundonline.com/mock-mcp-servers_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # MCP Agent Templates — Pre-Built AI Agents for Any MCP Server > 51 ready-to-run MCP agent templates for the tools you already use — Notion, GitHub, Jira, Sentry, HubSpot, Stripe, Linear, Slack, Supabase, Vercel, Shopify and more. Pick a template, add your token, start chatting. **Source:** https://mcpplaygroundonline.com/templates --- ## How a template works A template is a preconfigured agent: an MCP server URL, a model chosen to suit that server, and a system prompt written for the job. You supply your own access token for the service, and the agent is live. Nothing is installed. All 51 templates run inside [MCP Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio), so you can swap the model, edit the prompt, or point the same setup at a different server at any time. ## Credentials Templates that talk to a private service require a token you provide — a GitHub PAT, a Notion integration secret, a Stripe restricted key, and so on. Grant the narrowest scope that does the job; an agent will call whatever the token allows. ## Available templates ### Development - GitHub Code Review — Review PRs, inspect diffs, summarise commits and suggest improvements across any repository. - Cloudflare Developer — Manage Workers, KV, D1 databases, R2 buckets and DNS records via natural language. - Engineering Lead · GitHub, Linear & Slack — Review PRs on GitHub, move Linear tickets through the board, and post standup summaries to Slack — all in one conversation. - DevOps · GitHub, Cloudflare & Zapier — Ship code from GitHub to Cloudflare Workers, track deployments as Linear issues and automate post-deploy tasks via Zapier. - Infra Monitor · Cloudflare, GitHub & Linear — Monitor Cloudflare performance and error logs, correlate with GitHub deploys, and file Linear incidents automatically. - Sentry Error Triage — Triage Sentry errors in natural language — inspect stack traces, group issues and spot the commits that caused them. - Supabase Builder — Query Postgres, manage tables, run migrations and inspect auth users on your Supabase project — all from chat. - Vercel Deploy Assistant — Manage Vercel deployments, inspect build logs, check env vars and run rollbacks through conversational commands. - Full-Stack Shipper · GitHub, Vercel & Sentry — GitHub PRs, Vercel deploys and Sentry errors in one chat — the complete Next.js ship-and-debug loop. - Context7 Docs Assistant — Get live, version-specific library docs injected into every prompt — never hallucinate an API again. - Sprint Retro · Linear, Calendar & Slack — End-of-sprint autopilot: pull completed work from Linear, match it against sprint ceremonies on Calendar, and post the retro summary to Slack. - Post-Incident Review · Sentry, Linear & Slack — After an outage: pull the Sentry error timeline, create a Linear post-mortem issue, and post the incident summary to Slack. - Figma Design-to-Code Agent — Extract design specs, tokens and component details from Figma frames — then generate production-ready code. ### Productivity - Linear Project Manager — Create issues, triage backlogs, track progress and summarise sprint status directly from chat. - Zapier Automator — Trigger automations, list Zaps and manage workflows across 6,000+ connected apps. - Sprint Manager · Linear, GitHub & Slack — Run your sprint entirely from chat — groom the Linear backlog, review GitHub PRs and keep Slack informed on progress. - Notion Knowledge Agent — Chat with your Notion workspace — search pages, summarise docs, create new entries and keep your knowledge base tidy. - Jira & Confluence Agent — Search Confluence pages, manage Jira tickets and cross-reference documentation with active work from a single chat. - Asana Task Manager — Manage projects, create tasks from natural language, track timelines and summarise team workloads. - Monday.com Board Ops — Manage boards, items, updates and automations on Monday.com through conversational commands. - Meeting Follow-Up · Google Calendar, Notion & Slack — Pull meeting details from Google Calendar, create follow-up notes in Notion, and post action items to Slack — automatic post-meeting workflow. - Event Planner · Google Calendar, Asana & Slack — Plan conferences, webinars and launches: schedule milestones on Google Calendar, track tasks in Asana, and keep stakeholders updated on Slack. - PagerDuty Agent — Triage incidents, query on-call schedules, manage services and analyse incident history on PagerDuty — through chat. ### Data - Stripe Billing Assistant — Query customers, subscriptions, invoices and payment events without leaving your chat. - Shopify Storefront — Browse a Shopify store’s catalog, search products and build a cart from chat — powered by the store’s own hosted Storefront MCP. - Revenue Ops · Stripe, Linear & Slack — Correlate Stripe billing events with Linear bug reports and alert the team on Slack when revenue metrics change. - Neon Data Ops — Manage your Neon Postgres database and stream query results and alerts directly to your Slack workspace. - HubSpot CRM Assistant — Query contacts, deals and companies in HubSpot — update records, spot pipeline risks and draft personalised outreach. - Amazon Ads Operator — Query Sponsored Products, Brands and Display campaigns in plain English — bid adjustments, keyword analysis and performance reports without Seller Central tab-switching. - Amazon Ads Agent (Official API) — Connect directly to Amazon's official Ads MCP server — manage Sponsored Products, Brands & Display campaigns, pull performance reports, and optimise bids through natural conversation. - Meta Ads Agent (Pipeboard) — Analyse Facebook and Instagram campaigns, surface creative fatigue, audit audiences, and optimise budgets — all through natural conversation. Powered by Pipeboard's hosted Meta Ads MCP. - Paid Media ROAS · Meta, Amazon & Stripe — Meta Ads, Amazon Ads and Stripe in one chat — see true blended ROAS across Facebook, Instagram and Amazon with live revenue attribution. - Salesforce CRM Agent — Query leads, update opportunities, inspect pipelines and draft outreach — all via natural language. - Product Analytics · Amplitude, Linear & Slack — Monitor product metrics in Amplitude, auto-create Linear tickets on anomalies, and alert the team on Slack. - Sales Intelligence · Salesforce, Clay & Slack — Enrich leads with Clay, update your Salesforce pipeline, and notify reps on Slack — end-to-end sales ops. - Data Analyst · Neon, Hex & Slack — Run SQL on Neon Postgres, build interactive charts in Hex, and share insights to Slack — analyst workflow in chat. - Sales Call Prep · HubSpot, Calendar & Exa — Before any sales call: pull the meeting from Google Calendar, research the prospect with Exa, enrich with HubSpot CRM data — one-page brief ready in seconds. - Sales Follow-Up · Salesforce, Notion & Slack — After every sales call: update the deal in Salesforce, log notes in Notion, and Slack the AE a follow-up checklist — all from one prompt. - Airtable Operations Hub — Query bases, create and update records, and build reports from your Airtable data using plain English. - MongoDB Agent — Query collections, run aggregation pipelines, inspect schemas and analyse indexes on any MongoDB or Atlas cluster — in plain English. - Datadog Agent — Triage alerts, query metrics, summarise logs and pull APM traces from your Datadog account — observability through chat. - BigQuery Agent — Query BigQuery datasets in plain English, inspect schemas, estimate query costs and run analytics — Google's warehouse, AI-driven. - Snowflake Agent — Query Snowflake warehouses in plain English, inspect schemas, monitor warehouse credits and run analytics — through chat. - Grafana Agent — Query dashboards, inspect panels, manage alert rules and pull metrics from Grafana Cloud — observability ops through chat. ### Research - Web Research Agent · Exa — Search the live web, fetch pages and synthesise findings into clear, cited summaries. - Research & Report · Exa, Postgres & Zapier — Search the live web with Exa, enrich findings from your Postgres database and share the report via Zapier or Slack. - SEO Strategist · Ahrefs, Exa & Notion — Research keywords with Ahrefs, analyse competitors with Exa, and plan your content calendar in Notion — full SEO workflow in one chat. - SEO Research · OpenSEO — Keyword research, live SERPs, rank tracking, Search Console and Google Business Profile audits — one server, one conversation. ### Communication - Slack Team Assistant — Search messages, summarise threads, post updates and keep your team in sync. - Customer Success · Stripe, Slack & Linear — Pull customer billing details from Stripe, search conversation history in Slack and create follow-up tickets in Linear. - Sales Pipeline · HubSpot, Slack & Linear — HubSpot deals, Slack conversations and Linear feature requests — end-to-end lead-to-close visibility in chat. Browse and launch any of them at [https://mcpplaygroundonline.com/templates](https://mcpplaygroundonline.com/templates). --- _Canonical page: https://mcpplaygroundonline.com/templates_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # MCP Server Registry — Browse and Test MCP Servers > A searchable directory of MCP servers across databases, dev tools, productivity, cloud services and more — with 41 hand-written setup pages for the servers people actually use. Test any of them instantly in the browser. **Source:** https://mcpplaygroundonline.com/mcp-registry --- ## What is here A browsable index of MCP servers, plus **41 curated setup pages** written by hand. A curated page tells you what the server actually does, which tools it exposes, whether it needs authentication, which model handles it best and why, and example queries that work. Each curated page has a clean Markdown rendering — append `.md` to its URL, or request it with `Accept: text/markdown`. ## Curated server pages - [GitHub](https://mcpplaygroundonline.com/mcp-servers/github) — Drive GitHub repos, PRs and issues with an AI agent. - [Notion](https://mcpplaygroundonline.com/mcp-servers/notion) — Search, summarise and edit your Notion workspace with AI. - [Stripe](https://mcpplaygroundonline.com/mcp-servers/stripe) — Query customers, subscriptions and payments with an AI agent. - [Supabase](https://mcpplaygroundonline.com/mcp-servers/supabase) — Manage Supabase projects, run SQL and inspect schemas with AI. - [Linear](https://mcpplaygroundonline.com/mcp-servers/linear) — Triage issues, run cycles and update your product backlog with AI. - [Exa](https://mcpplaygroundonline.com/mcp-servers/exa) — Give an agent live web search and clean page reads — no API key to get started. - [GitLab](https://mcpplaygroundonline.com/mcp-servers/gitlab) — Review merge requests, read pipeline logs and search code from an MCP client. - [PayPal](https://mcpplaygroundonline.com/mcp-servers/paypal) — Create invoices, capture orders, issue refunds and track disputes from an MCP client. - [TikTok for Business](https://mcpplaygroundonline.com/mcp-servers/tiktok) — Create campaigns, pull performance reports and manage TikTok Ads from an MCP client — no developer app required. - [X (Twitter)](https://mcpplaygroundonline.com/mcp-servers/x-twitter) — Search posts, read profiles, track trends and publish to X from an MCP client. - [Slack](https://mcpplaygroundonline.com/mcp-servers/slack) — Search workspace, read threads, post updates and work with Slack from chat. - [Cloudflare](https://mcpplaygroundonline.com/mcp-servers/cloudflare) — Drive Workers, DNS, R2, D1 and the rest of the Cloudflare API with AI. - [Vercel](https://mcpplaygroundonline.com/mcp-servers/vercel) — List deployments, read logs, manage env keys and roll back from natural language. - [Sentry](https://mcpplaygroundonline.com/mcp-servers/sentry) — Triage issues, stack traces and releases from chat without opening ten browser tabs. - [HubSpot](https://mcpplaygroundonline.com/mcp-servers/hubspot) — Query CRM, deals and tickets — and draft follow-ups with full record context. - [Jira & Confluence](https://mcpplaygroundonline.com/mcp-servers/jira) — Search Jira and Confluence, move tickets, and keep docs aligned with in-flight work — plus JSM, Bitbucket and Compass. - [Zapier](https://mcpplaygroundonline.com/mcp-servers/zapier) — List Zaps, inspect runs and trigger automations across thousands of apps. - [Asana](https://mcpplaygroundonline.com/mcp-servers/asana) — Create tasks, triage projects, and summarise team workload from chat. - [Salesforce](https://mcpplaygroundonline.com/mcp-servers/salesforce) — Query CRM records, update pipeline, and draft outreach in natural language. - [Monday.com](https://mcpplaygroundonline.com/mcp-servers/monday) — Query boards, move items, and summarise work across your workspaces. - [PostgreSQL](https://mcpplaygroundonline.com/mcp-servers/postgres) — Chat with any Postgres database using AI. - [Playwright](https://mcpplaygroundonline.com/mcp-servers/playwright) — Give AI models real browser control — navigate, click, fill forms and screenshot any page. - [Figma](https://mcpplaygroundonline.com/mcp-servers/figma) — Read design files, inspect components and extract assets with an AI agent. - [MongoDB](https://mcpplaygroundonline.com/mcp-servers/mongodb) — Query collections, run aggregations and inspect schemas with natural language. - [Neon](https://mcpplaygroundonline.com/mcp-servers/neon) — Query serverless Postgres, manage branches and run migrations with AI. …and 16 more at [https://mcpplaygroundonline.com/mcp-registry](https://mcpplaygroundonline.com/mcp-registry). ## Testing one Every server in the registry can be opened directly in [Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio) — paste your token if it needs one, and start asking questions. Nothing to install. --- _Canonical page: https://mcpplaygroundonline.com/mcp-registry_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # Test Your MCP Server With Any AI Model — DeepSeek, Claude, GPT, Gemini, Grok, Qwen > Paste your MCP server URL and run it against any AI model in the browser — DeepSeek, Claude, GPT-5, Gemini, Grok, Qwen, GLM, Kimi, MiniMax, Nemotron and Mistral. See which model actually picks the right tool. Free, no install. **Source:** https://mcpplaygroundonline.com/mcp-model-comparison --- ## The core fact **Anthropic is the only provider whose API speaks MCP natively.** Every other model family reaches MCP tools through a translation layer — the host converts MCP tool definitions into that provider's own function-calling format, and converts the calls back. That translation is where behaviour diverges. The same server, the same prompt, and the same tools can produce different tool selections, differently-shaped arguments, and very different error recovery depending on which model is driving. ## What this means in practice A server that works flawlessly in Claude Desktop can fail against GPT or Gemini for reasons that are not bugs in your code: - Tool descriptions that are unambiguous to one model are ambiguous to another - Schema features (nested objects, unions, optional-with-default) survive translation unevenly - Error conventions that one model recovers from cause another to loop or give up - Models differ sharply in how many tools they can choose between before selection quality degrades If you publish an MCP server, you cannot know it works for your users by testing it with one model. ## Model families you can test against - **Claude** (Anthropic) — native MCP - **GPT** (OpenAI) - **Gemini** and **Gemma** (Google) - **Grok** (xAI) - **DeepSeek** - **Qwen** (Alibaba) - **GLM** (Z.AI) - **Kimi** (Moonshot) - **MiniMax** - **Nemotron** (NVIDIA) - **Mistral** 70+ individual models across those families. ## How to run the comparison 1. Open [https://mcpplaygroundonline.com/mcp-model-comparison](https://mcpplaygroundonline.com/mcp-model-comparison) and paste your MCP server URL. 2. Pick a model and run a task that exercises the tool you care about. 3. Repeat with a model from a different family and compare tool selection. 4. For a systematic answer rather than a spot check, run an [eval suite](https://mcpplaygroundonline.com/mcp-evals) — it grades tool usability rather than leaving you to eyeball transcripts. --- _Canonical page: https://mcpplaygroundonline.com/mcp-model-comparison_ _MCP Playground (mcpplaygroundonline.com) is a free, browser-based toolkit for the Model Context Protocol: test any remote MCP server, run evals that prove an AI agent can use its tools, build reusable agents across 70+ models, and audit servers for security issues. No install, no local Node, free to start._ --- # Part 2 — Guides # Is MCP Dead? What the CLI Backlash Gets Right — and Wrong > A post called "MCP is dead. Long live the CLI" hit the top of Hacker News and the argument still has not settled. Three of its five complaints are fair. Two were fixed by the 2026-07-28 spec. Here is how to tell which side your project is on. **Source:** https://mcpplaygroundonline.com/blog/is-mcp-dead-cli-debate **Author:** Nikhil Tiwari **Published:** 2026-09-07 **Updated:** 2026-09-07 **Category:** Comparison **Reading time:** 13 min read --- 📖 TL;DR - The backlash started with Eric Holmes' post **"MCP is dead. Long live the CLI"**, which hit the top of Hacker News with 400+ points. - His five complaints: **context cost, debuggability, composability, auth friction, operational overhead**. Three still land. Two were addressed in the **2026-07-28** spec. - Thoughtworks put **naive API-to-MCP conversion** in the Hold ring of their Technology Radar. That is the real target — thin REST wrappers, not the protocol. - **CLI wins** when three things are all true: the agent has a shell, a good CLI already exists, and the user is a developer on their own machine. - **MCP wins** the moment any one of those is false — remote users, non-shell runtimes, enterprise audit, or more than one client. - The ecosystem is not shrinking. PulseMCP listed **22,311 servers** in July 2026, and Tier 1 SDKs are near **half a billion downloads a month**. Table of Contents 1. [Where the Argument Came From](#where-it-came-from) 2. [The Five Complaints, Scored](#five-complaints) 3. [What the 2026-07-28 Spec Fixed](#what-changed) 4. [Where the CLI Genuinely Wins](#cli-wins) 5. [Four Places a CLI Cannot Go](#cli-cannot) 6. [The Numbers Behind "Dead"](#numbers) 7. [Which One Should You Ship?](#decision) 8. [Does Your Server Deserve to Exist?](#deserves) 9. [FAQ](#faq) Someone asks me **"is MCP dead"** roughly once a week now. Usually right after they read a thread telling them to delete their servers. The short answer: no. The longer answer is more useful, because **the critics are right about a specific failure mode** that a lot of teams shipped in 2025. I run a tool that connects to other people's MCP servers all day. I see the good ones and the ones that should have been a shell script. If the protocol itself is new to you, start with my [guide to the Model Context Protocol](/blog/what-is-model-context-protocol) — this post assumes you already know what a tool call is. This post walks the actual argument, scores each complaint honestly, and gives you a table for deciding which layer your next integration belongs on. I am not going to defend the protocol on principle. Some of the servers I connect to genuinely should not exist. ## Where the "MCP Is Dead" Argument Came From On 28 February 2026, Eric Holmes published _"MCP is dead. Long live the CLI."_ It went straight to the top of Hacker News. His thesis was not that agents should stop using tools. **It was that LLMs are already excellent at using the command line.** Models know `git`. They know `kubectl`, `docker`, `aws`, `jq`. That knowledge came free with pretraining. So when you wrap an existing CLI in an MCP server, he argues, you pay protocol cost to re-teach the model something it already knew. The thread hit 400+ points and nearly 300 comments. Pieter Levels called MCP "just as useless of an idea as llms.txt." Then Thoughtworks put **naive API-to-MCP conversion** in the Hold ring of their Technology Radar. That is the sharpest version of the critique. ⚠️ Read the Hold ring carefully Thoughtworks did not put _MCP_ in Hold. They put _naive API-to-MCP conversion_ in Hold — auto-generating one tool per REST endpoint and calling it an integration. That is a design failure, not a protocol failure. ## The Five Complaints, Scored Honestly Holmes made five distinct arguments. They do not all age the same way, so I scored each one against the current spec. Complaint Still fair in Sept 2026? Why **Context cost** **Yes** Most clients still load every tool schema up front. Progressive discovery is roadmap, not spec. **Composability** **Yes** You cannot pipe a tool result into `jq`. Filtering has to be built into the server. **Debuggability** **Partly** Stateless requests are now replayable with `curl`. Tooling closed most of this gap. **Auth friction** **Largely fixed** CIMD replaced Dynamic Client Registration as the preferred path, plus issuer validation. **Operational overhead** **Largely fixed** The stateless core removed sessions. A server is now a normal HTTP workload. ### Context cost is the one that still hurts This is the strongest complaint and nobody has solved it yet. **Connect eight servers with fifteen tools each and your context is gone before the first message.** Clients load names, descriptions and full input schemas into the system prompt at session start. Whether the agent uses them or not. The August roadmap lists _progressive tool discovery_ as a priority. It is not in a shipped spec revision yet. Until it is, the fix is discipline. Fewer tools, tighter descriptions, and measuring what you actually send. ### Composability is a real architectural loss A CLI returns text you can pipe. `terraform state list | grep aws_instance` costs you nothing in context. An MCP tool returns a result that lands whole in the conversation. **Either you dump 40KB of Terraform state into the window, or you build filtering into the server.** Holmes is right that this is a genuine tradeoff. Structured results buy you schema safety and cost you Unix pipes. ## What the 2026-07-28 Spec Actually Fixed Two of the five complaints were about operations, and the July 2026 revision went straight at them. The **stateless protocol core** removed the `initialize` handshake and the `Mcp-Session-Id` header entirely. Each request now carries its own protocol version, client identity and capabilities in `_meta`. No shared state between requests. That kills the "MCP servers are stateful things you have to babysit" argument. **A 2026-spec server is a stateless HTTP workload behind any load balancer.** Auth got the same treatment. RFC 9207 issuer validation landed as SEP-2468, issuer-bound client credentials as SEP-2352. Dynamic Client Registration was formally deprecated in favour of _Client ID Metadata Documents_. Fewer registration round trips, less token churn. There is also **Multi Round-Trip Requests** (SEP-2322), which replaced server-initiated requests. A server returns `resultType: "input_required"` and the client retries with answers. That is how elicitation and mid-call confirmation now work without a persistent stream. If you are still on the old revision, my [stateless migration guide](/blog/migrate-mcp-server-2026-07-28-stateless) covers the mechanics. **Worth noting:** a lot of the "MCP is bloated" takes are describing the 2025-03-26 or 2025-11-25 revision. The complaints about sessions, sticky routing and SSE streams are accurate — for a spec that is no longer current. ## Where the CLI Genuinely Wins I want to be blunt here, because pretending otherwise is how you end up shipping a server nobody uses. **If a good CLI already exists and your agent has a shell, use the CLI.** Wrapping `gh` in an MCP server is usually a waste of everyone's time. Three conditions have to hold for the CLI to be the better answer: 1. **The agent has shell access.** Claude Code, Codex and Cursor do. A web chat app does not. 2. **A mature CLI already exists** with stable flags and machine-readable output. 3. **The user is a developer on their own machine**, already authenticated through their normal profile. When all three are true the CLI wins on every axis. Zero context cost, real pipes, existing credentials, trivial debugging. The model already knows the tool. You add nothing by putting JSON-RPC in front of it. ## Four Places a CLI Cannot Go Now the other direction. **Break any one of those three conditions and the CLI stops being an option at all.** ### 1\. The client has no shell Claude's web and desktop apps, ChatGPT, and every consumer agent connect over HTTP. There is no terminal to run `kubectl` in. This is the case Holmes' post does not cover, and it is most of the market. **Remote MCP exists precisely because the caller is not sitting at a shell.** ### 2\. Enterprise auth and audit Giving an agent your AWS profile means giving it everything your profile can do. There is no scope in between. MCP puts a server between the agent and the system. You get per-tool scopes, an audit trail, and a place to deny a call. As one rebuttal put it: not giving an AI agent unrestricted root on enterprise systems is not obstruction, it is a CISO doing their job. ### 3\. More than one client needs the same tools A CLI wrapper is per-agent glue. **An MCP server is written once and consumed by every client that speaks the protocol.** This is the same argument that beat per-provider function calling. I unpacked it in [MCP vs function calling vs REST APIs](/blog/mcp-vs-function-calling-vs-api-comparison). ### 4\. There is no CLI Your internal ticketing system does not ship a CLI. Neither does your warehouse, your feature flag service, or that 2014 SOAP endpoint. "Just write a good CLI first" is real advice, but it is a second project. **Sometimes the MCP server is the cheapest honest interface you can build.** Not sure whether your server earns its context budget? Connect it in the browser, see every tool schema a model actually receives, and count the tokens before you ship. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Count your tool-schema tokens](https://mcpplaygroundonline.com/mcp-token-counter) ## The Numbers Behind "Dead" Declarations of death should survive contact with a download counter. These do not. 22,311 Servers listed on PulseMCP as of July 2026 ~500M Monthly downloads across Tier 1 SDKs 1B+ All-time downloads, TypeScript and Python SDKs each Dec 2025 Donated to the Linux Foundation's Agentic AI Foundation Governance is the part people skip. MCP is no longer an Anthropic project — **it sits under the Agentic AI Foundation with Anthropic, OpenAI, Google, Microsoft and AWS at the table.** Protocols with that shape of backing do not die from a Hacker News thread. They get boring, which is the goal. ## Which One Should You Ship? Here is the table I actually use. Find your row, ship that thing, stop reading threads. Your situation Ship this Coding agent, mature CLI exists, dev's own machine **CLI** — plus a Skill if the agent needs process knowledge Web or desktop chat client, no shell **Remote MCP server**, Streamable HTTP, 2026-07-28 Internal system, needs scoped access and audit **MCP server** with OAuth and per-tool scopes Three or more clients need the same tools **MCP server** — write once, reuse everywhere One app, one provider, you own every tool **Plain function calling** — MCP is pure overhead here Agent knows the tools, just not your process **Agent Skill** — no server needed at all Notice that two of six rows say "not MCP". **That is the honest read of the backlash** — not that the protocol failed, but that it got applied to rows it never fit. If the Skills row is new to you, I compared all four layers in [Agent Skills vs MCP vs function calling vs A2A](/blog/agent-skills-vs-mcp). ## Does Your MCP Server Deserve to Exist? Five questions. If you answer no to the first three, delete the server and write a CLI. 1. **Can a client without a shell reach this?** If every consumer has a terminal, you may not need a server. 2. **Does it enforce a scope the raw credentials do not?** A pass-through wrapper adds risk, not safety. 3. **Will more than one client use it?** One consumer means you built glue, not an integration. 4. **Are the tools task-shaped, not endpoint-shaped?** One tool per REST route is the Hold-ring anti-pattern. 5. **Do you know its token cost?** If you cannot state the schema size, you cannot defend it. Question four is where most servers fail. **Forty CRUD tools is a generated API client, not an agent interface.** Collapse them into the handful of tasks a user actually asks for. Tool descriptions matter more than tool count — see [why tool description quality decides tool selection](/blog/mcp-tool-description-quality). Question five is measurable in about a minute. Connect the server, look at the schemas the model receives, and count them. Then run the same prompt against a real model and watch which tool it picks. That is the only test that settles the argument for your server. Settle the argument with evidence, not threads Run your server against a real model, see every tool call, and check it for tool poisoning and over-broad scopes while you are there. [Run it in MCP Agent Studio →](https://mcpplaygroundonline.com/mcp-agent-studio) [Scan your MCP server →](https://mcpplaygroundonline.com/mcp-security-scanner) ## The Verdict MCP is not dead. **It got sorted.** The use cases that never needed it are moving to CLIs and Skills, which is healthy. The use cases that genuinely need a protocol are quietly shipping one. What died is the 2025 reflex of wrapping every API in a server because the tooling made it easy. If your server survives the five questions above, ignore the thread. If it does not, the thread did you a favour. And if it survives, make it findable. Publishing a [.well-known Server Card](/blog/mcp-server-cards-well-known-discovery) is the cheapest way to get listed by registries and client install dialogs. ## FAQ **Is MCP dead in 2026?+** No. PulseMCP listed 22,311 servers in July 2026, Tier 1 SDKs are near half a billion downloads a month, and the protocol has been under the Linux Foundation's Agentic AI Foundation since December 2025 with Anthropic, OpenAI, Google, Microsoft and AWS involved. What faded is the practice of wrapping every REST API in an MCP server. **Should I use a CLI instead of an MCP server?+** Use the CLI when all three of these hold: the agent has shell access, a mature CLI already exists, and the user is a developer on their own machine with existing credentials. Break any one of those and you need MCP — a web client has no shell, enterprise access needs scoped auth, and internal systems often have no CLI at all. **What did Thoughtworks actually put in the Hold ring?+** Naive API-to-MCP conversion, not MCP itself. The anti-pattern is auto-generating one tool per REST endpoint, which produces dozens of CRUD tools that burn context and confuse tool selection. The fix is designing task-shaped tools that match what a user asks for, rather than mirroring your API surface. **Did the 2026-07-28 spec answer the MCP criticism?+** Partly. The stateless core removed the initialize handshake and Mcp-Session-Id header, so a server is now a plain HTTP workload behind any load balancer, which answers the operational overhead complaint. Authorization hardening with RFC 9207 issuer validation and Client ID Metadata Documents answered the auth friction complaint. Context cost and composability were not addressed and remain valid criticisms. **Why do MCP servers use so much context?+** Most clients load every connected server's full tool list into the system prompt at session start, including names, descriptions and complete JSON input schemas, whether the agent uses them or not. Eight servers with fifteen tools each can consume a significant slice of the window before the first user message. Progressive tool discovery is listed as a priority in the August 2026 roadmap but is not in a shipped spec revision yet. **Can I pipe MCP tool output like CLI output?+** No, and this is the strongest surviving criticism. A CLI lets you chain through grep or jq before anything reaches the model, at zero context cost. An MCP tool result lands whole in the conversation, so filtering and pagination have to be built into the server as tool parameters. Structured, schema-validated results are what you buy in exchange. ## Frequently asked questions ### Is MCP dead in 2026? No. PulseMCP listed 22,311 servers in July 2026, Tier 1 SDKs are near half a billion downloads a month, and the protocol has been under the Linux Foundation Agentic AI Foundation since December 2025 with Anthropic, OpenAI, Google, Microsoft and AWS involved. What faded is the practice of wrapping every REST API in an MCP server. ### Should I use a CLI instead of an MCP server? Use the CLI when all three of these hold: the agent has shell access, a mature CLI already exists, and the user is a developer on their own machine with existing credentials. Break any one of those and you need MCP, because a web client has no shell, enterprise access needs scoped auth, and internal systems often have no CLI at all. ### What did Thoughtworks actually put in the Hold ring? Naive API-to-MCP conversion, not MCP itself. The anti-pattern is auto-generating one tool per REST endpoint, which produces dozens of CRUD tools that burn context and confuse tool selection. The fix is designing task-shaped tools that match what a user asks for rather than mirroring your API surface. ### Did the 2026-07-28 spec answer the MCP criticism? Partly. The stateless core removed the initialize handshake and the Mcp-Session-Id header, so a server is now a plain HTTP workload behind any load balancer, which answers the operational overhead complaint. Authorization hardening with RFC 9207 issuer validation and Client ID Metadata Documents answered the auth friction complaint. Context cost and composability were not addressed and remain valid criticisms. ### Why do MCP servers use so much context? Most clients load every connected server full tool list into the system prompt at session start, including names, descriptions and complete JSON input schemas, whether the agent uses them or not. Eight servers with fifteen tools each can consume a significant slice of the window before the first user message. Progressive tool discovery is a priority in the August 2026 roadmap but is not in a shipped spec revision yet. ### Can I pipe MCP tool output like CLI output? No, and this is the strongest surviving criticism. A CLI lets you chain through grep or jq before anything reaches the model, at zero context cost. An MCP tool result lands whole in the conversation, so filtering and pagination have to be built into the server as tool parameters. Structured, schema-validated results are what you buy in exchange. --- _Canonical page: https://mcpplaygroundonline.com/blog/is-mcp-dead-cli-debate — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # MCP Server Cards: The .well-known File Your Server Is Missing > Server Cards let a client, registry or crawler learn what your MCP server is before opening a single connection. SEP-2127 is still open, the path is still moving, and publishing one now costs about twenty lines. Here is the schema, the gotchas, and how to ship it. **Source:** https://mcpplaygroundonline.com/blog/mcp-server-cards-well-known-discovery **Author:** Nikhil Tiwari **Published:** 2026-09-07 **Updated:** 2026-09-07 **Category:** Development **Reading time:** 11 min read --- 📖 TL;DR - An **MCP Server Card** is a small JSON file at a `.well-known` URL that describes your server _before_ anyone connects to it. - Think `robots.txt` or `.well-known/openid-configuration` — a static file that unlocks discovery for clients, registries and crawlers. - The active proposal is **SEP-2127**, successor to SEP-1649. It is **still open** as of September 2026, and the exact filename has moved more than once. - The card carries **identity, docs links, remote endpoints and supported protocol versions**. It deliberately does **not** list your tools. - Tools stay dynamic and are discovered at runtime through `tools/list`. Baking them into a static file would go stale instantly. - It is **not the same thing** as `server.json` in the official registry, and not the same as an A2A Agent Card. Table of Contents 1. [What Is an MCP Server Card?](#what) 2. [Why Pre-Connection Discovery Matters](#why) 3. [The Path (and Why It Keeps Moving)](#path) 4. [What Goes in the Card](#fields) 5. [Why Tools Are Not in the Card](#omits) 6. [Server Card vs server.json vs Agent Card](#vs) 7. [How to Publish One](#publish) 8. [Five Mistakes I Keep Seeing](#mistakes) 9. [How to Verify It](#verify) 10. [FAQ](#faq) Right now, the only way to find out what an **MCP server** does is to connect to it. Handshake, auth, `tools/list`, then decide if you even wanted it. That is fine for one server. It is terrible for a registry indexing twenty thousand of them. **MCP Server Cards** fix that. One static JSON file at a `.well-known` URL, readable by anything that can make a GET request. I have been tracking this since SEP-1649 opened, and the proposal has changed shape twice. This post covers what is settled, what is not, and what I would ship today. Publishing one takes about twenty lines. Skipping it means registries and client UIs have nothing to show about your server. This assumes you already run a server. If not, my [introduction to the Model Context Protocol](/blog/what-is-model-context-protocol) is the place to start. ## What Is an MCP Server Card? A _Server Card_ is machine-readable metadata about an MCP server, served over plain HTTP at a well-known path. It answers the questions a client has **before** it commits to a connection: - What is this server called, and who publishes it? - Where are its remote endpoints? - Which protocol revisions does it speak? - Where are the docs and the source? The mental model that helped me most: **it is `robots.txt` for agents.** A tiny file that makes an entire discovery ecosystem possible. The Server Card Working Group is developing the convention as part of the MCP roadmap's discovery workstream. ## Why Pre-Connection Discovery Matters Four groups need this, and none of them can get it today without opening a session. **Registries.** Indexing servers means connecting to each one, authenticating, and hoping it is up. A card is a cheap crawl. **Client UIs.** Claude Desktop and Cursor want to show a name, icon and description in an install dialog before you approve anything. **Agents doing selection.** An agent choosing between three candidate servers should not have to open three connections to compare. **Security review.** Knowing which protocol revisions and auth methods a server claims, before you connect, is a real triage signal. **The SEO angle nobody mentions:** a Server Card is also how crawlers find you. If you publish a hosted MCP server and want it listed in directories like the [MCP registry](/mcp-registry), a static card is the lowest-effort way to be indexable. ## The Path (and Why It Keeps Moving) Here is the honest state of play, because most write-ups on this quote a path that is already out of date. **SEP-1649** opened the idea: HTTP server discovery via `.well-known`. **SEP-2127** is the active pull request that carries it forward. SEP-2127 proposes serving the card at: ``` https://example.com/.well-known/mcp/server-cards.json ``` Earlier drafts and several third-party guides use the singular `server-card.json`, and a mid-2026 draft suggested hanging it off the MCP endpoint as `/server-card` with a site-level catalog. ⚠️ SEP-2127 is still open As of September 2026 this is a proposal under active review, not a ratified part of the spec. The field names below are stable enough to build against, but do not treat the exact filename as final. Serve both spellings if you want to be safe — it is a static file. My advice: **publish at the SEP-2127 path and add a redirect from the singular form.** Two lines of config, and you stop caring how the vote goes. Note the deliberate separation from `.well-known/ai-catalog.json`. That is the protocol-agnostic AI Card standard, a different thing with a different audience. ## What Goes in the Card The schema is small on purpose. Here is what SEP-2127 carries. Field Purpose `name` Machine identifier, reverse-DNS style. Stable across releases. `title` Human-readable name for install dialogs and directory listings. `description` One or two sentences on what the server is for. `version` Your server's version, not the protocol version. `websiteUrl` Docs or landing page a human should read. `repository` Source location. Big trust signal for reviewers. `remotes` Array of connectable endpoints with transport type. `supportedProtocolVersions` Which revisions you speak. This is the dual-spec field. `icons` Icon URLs with sizes, for client UI. `_meta` Namespaced escape hatch for vendor-specific extras. A complete card for a hosted server looks like this. That is the whole file. /.well-known/mcp/server-cards.json ``` { "name": "com.acme/support-tools", "title": "Acme Support Tools", "description": "Read and triage Acme support tickets, and draft replies.", "version": "2.4.0", "websiteUrl": "https://acme.com/docs/mcp", "repository": { "url": "https://github.com/acme/support-mcp", "source": "github" }, "remotes": [ { "type": "streamable-http", "url": "https://mcp.acme.com/v1" } ], "supportedProtocolVersions": ["2026-07-28", "2025-11-25"], "icons": [ { "src": "https://acme.com/icon-256.png", "sizes": "256x256" } ] } ``` **The `supportedProtocolVersions` array is the field to get right.** It is how a client knows whether to send a 2026 stateless request or the older session handshake. If you support both revisions, list both. If you have already migrated, list only `2026-07-28` and let old clients fail fast. ## Why Tools Are Not in the Card This surprises people, and several third-party guides get it wrong by showing a `tools[]` array. **SEP-2127 deliberately omits tools, resources and prompts.** Community feedback drove that decision, and it is the right call. Servers are dynamic. Tool lists change with the caller's scopes, feature flags, tenant configuration and deploy cadence. A static file claiming eleven tools while the live server exposes seven is worse than no file at all. **Stale metadata is a bug that lies confidently.** So primitives stay where they belong: discovered at runtime through `tools/list`, which since the 2026-07-28 revision returns `ttlMs` and `cacheScope` so clients can cache the answer properly. That is the actual division of labour. **The card tells you whether to connect. The protocol tells you what you can do once you have.** ## Server Card vs server.json vs A2A Agent Card Three similar-sounding artifacts, three different jobs. I have watched this confusion cost people an afternoon. Artifact Lives where Answers **Server Card** On your own domain, at `.well-known` What is this server, and should I connect? **`server.json`** Submitted to the official MCP registry How do I install this, including local packages? **A2A Agent Card** On an agent's domain, at `.well-known` What can this _agent_ do, and can I delegate to it? The registry's `server.json` covers local packages too — npm, PyPI, Docker. The Server Card is **HTTP discovery only**, which is why it was scoped down. That scoping was deliberate: it avoids breaking changes to `server.json`. Publish both if you distribute a local package and host a remote endpoint. If registry publishing is the part you need, I wrote a walkthrough on [publishing an MCP server to the registry](/blog/how-to-publish-your-mcp-server-to-registry). And the A2A comparison is a genuinely different axis, covered in [MCP vs A2A](/blog/mcp-vs-a2a-agent2agent-protocol). ## How to Publish One It is a static JSON response with CORS enabled. Three flavours below. ### Next.js App Router app/.well-known/mcp/server-cards.json/route.ts ``` import { NextResponse } from 'next/server'; const card = { name: 'com.acme/support-tools', title: 'Acme Support Tools', description: 'Read and triage Acme support tickets.', version: process.env.npm_package_version ?? '1.0.0', websiteUrl: 'https://acme.com/docs/mcp', remotes: [{ type: 'streamable-http', url: 'https://mcp.acme.com/v1' }], supportedProtocolVersions: ['2026-07-28'], }; export function GET() { return NextResponse.json(card, { headers: { 'Cache-Control': 'public, max-age=3600', 'Access-Control-Allow-Origin': '*', }, }); } ``` ### Express ``` app.get('/.well-known/mcp/server-cards.json', (req, res) => { res.set('Access-Control-Allow-Origin', '*'); res.set('Cache-Control', 'public, max-age=3600'); res.json(card); }); ``` ### Cloudflare Workers ``` if (url.pathname === '/.well-known/mcp/server-cards.json') { return Response.json(card, { headers: { 'Cache-Control': 'public, max-age=3600', 'Access-Control-Allow-Origin': '*', }, }); } ``` **Serve it from the apex domain of your MCP endpoint's origin.** A card at `docs.acme.com` for a server at `mcp.acme.com` will not be found. Building on Workers? My [Cloudflare Workers MCP guide](/blog/build-mcp-server-cloudflare-workers-guide) covers the surrounding setup. Card published — does the server behind it actually work? Paste the URL from your `remotes` array, connect in the browser, and confirm the protocol revisions you claimed are the ones you speak. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Check server compliance](https://mcpplaygroundonline.com/mcp-checker) ## Five Mistakes I Keep Seeing **1\. Listing tools in the card.** They are not part of SEP-2127. If you copied a schema with a `tools[]` array, you copied an outdated draft. **2\. Claiming a protocol version you do not implement.** Putting `2026-07-28` in the array while still requiring `Mcp-Session-Id` will break stateless clients. **3\. Forgetting CORS.** Browser-based clients and web inspectors fetch this file directly. No `Access-Control-Allow-Origin` means invisible to half your audience. **4\. Putting it behind auth.** The entire point is pre-connection discovery. A card that returns 401 does nothing. **5\. Letting `version` go stale.** Wire it to your build. A card that says 1.0.0 eighteen months in tells reviewers you are not maintaining the server. Mistake two is the expensive one. If you are unsure which revision you actually implement, my [breakdown of the stateless changes](/blog/mcp-stateless-2026-release-candidate) has the checklist. ## How to Verify It Three checks, about ninety seconds total. **Fetch it cold.** Use curl with no cookies and no auth header: ``` curl -sI https://acme.com/.well-known/mcp/server-cards.json curl -s https://acme.com/.well-known/mcp/server-cards.json | jq . ``` You want a 200, `content-type: application/json`, and an `access-control-allow-origin` header. **Cross-check the endpoint.** Take the URL from `remotes` and connect to it. If it does not resolve, your card is pointing users at nothing. **Cross-check the versions.** Confirm the server really speaks every revision listed in `supportedProtocolVersions`. Claiming both and supporting one is the most common failure. That last check is what a browser-based tester is for. Connect, list tools, and see which revision the handshake actually negotiates. New to server testing generally? Start with [how to test MCP servers step by step](/blog/how-to-test-mcp-servers-step-by-step), then come back to the card. ## Ship the Card Now SEP-2127 is not final, but the cost of being early here is close to zero. It is a static JSON file with two fields you might have to rename. The cost of being late is that registries, client install dialogs and agent selection logic have nothing to say about your server. Publish the card, point `remotes` at a URL that works, and be honest in `supportedProtocolVersions`. Then verify all three against a live connection. One caveat worth holding onto: discovery only helps a server that deserved to be built. I worked through that question in [Is MCP dead? What the CLI backlash gets right](/blog/is-mcp-dead-cli-debate). ## FAQ **What is an MCP Server Card?+** A small JSON file served at a .well-known URL that describes an MCP server before any client connects to it. It carries identity, description, documentation and repository links, remote endpoints, supported protocol versions and icons. It exists so registries, client install dialogs, crawlers and agents can evaluate a server without opening a session and authenticating. **What is the .well-known path for an MCP Server Card?+** SEP-2127 proposes /.well-known/mcp/server-cards.json, served from the origin of your MCP endpoint. Earlier drafts and several third-party guides use the singular server-card.json, and one mid-2026 draft suggested hanging the card off the MCP endpoint itself. Because the proposal is still open, serving both spellings, or redirecting one to the other, is the safe move. **Do Server Cards list a server's tools?+** No. SEP-2127 deliberately omits tools, resources and prompts. Servers are dynamic, so the tool list can vary with the caller's scopes, tenant, feature flags and deploy version. A static file claiming a tool set that does not match the live server is worse than no file. Primitives stay discoverable at runtime through tools/list, which returns ttlMs and cacheScope in the 2026-07-28 revision so clients can cache them correctly. **Is a Server Card the same as server.json in the MCP registry?+** No. server.json is what you submit to the official MCP registry, and it covers local package distribution through npm, PyPI or Docker as well as remote endpoints. The Server Card is HTTP discovery only, served from your own domain, and was deliberately scoped down to avoid breaking changes to server.json. If you ship both a local package and a hosted endpoint, publish both artifacts. **Is SEP-2127 final?+** Not as of September 2026. SEP-2127 is an open pull request under active review, succeeding SEP-1649, and the Server Card Working Group is still refining conventions as part of the MCP roadmap. Field names such as name, title, description, version, remotes and supportedProtocolVersions are stable enough to build against, but the exact filename has changed more than once, so avoid hard-coding it in client logic. **Does the Server Card need CORS headers?+** Yes. Browser-based MCP clients, online inspectors and web install dialogs fetch the card directly from the browser, so without an Access-Control-Allow-Origin header the request fails silently. Serve it with Access-Control-Allow-Origin set to a wildcard, a JSON content type, and a Cache-Control max-age of around an hour. Never place the card behind authentication, since pre-connection discovery is its entire purpose. ## Frequently asked questions ### What is an MCP Server Card? A small JSON file served at a .well-known URL that describes an MCP server before any client connects to it. It carries identity, description, documentation and repository links, remote endpoints, supported protocol versions and icons. It exists so registries, client install dialogs, crawlers and agents can evaluate a server without opening a session and authenticating. ### What is the .well-known path for an MCP Server Card? SEP-2127 proposes /.well-known/mcp/server-cards.json, served from the origin of your MCP endpoint. Earlier drafts and several third-party guides use the singular server-card.json, and one mid-2026 draft suggested hanging the card off the MCP endpoint itself. Because the proposal is still open, serving both spellings, or redirecting one to the other, is the safe move. ### Do Server Cards list a server tools? No. SEP-2127 deliberately omits tools, resources and prompts. Servers are dynamic, so the tool list can vary with the caller scopes, tenant, feature flags and deploy version. A static file claiming a tool set that does not match the live server is worse than no file. Primitives stay discoverable at runtime through tools/list, which returns ttlMs and cacheScope in the 2026-07-28 revision so clients can cache them correctly. ### Is a Server Card the same as server.json in the MCP registry? No. server.json is what you submit to the official MCP registry, and it covers local package distribution through npm, PyPI or Docker as well as remote endpoints. The Server Card is HTTP discovery only, served from your own domain, and was deliberately scoped down to avoid breaking changes to server.json. If you ship both a local package and a hosted endpoint, publish both artifacts. ### Is SEP-2127 final? Not as of September 2026. SEP-2127 is an open pull request under active review, succeeding SEP-1649, and the Server Card Working Group is still refining conventions as part of the MCP roadmap. Field names such as name, title, description, version, remotes and supportedProtocolVersions are stable enough to build against, but the exact filename has changed more than once, so avoid hard-coding it in client logic. ### Does the Server Card need CORS headers? Yes. Browser-based MCP clients, online inspectors and web install dialogs fetch the card directly from the browser, so without an Access-Control-Allow-Origin header the request fails silently. Serve it with Access-Control-Allow-Origin set to a wildcard, a JSON content type, and a Cache-Control max-age of around an hour. Never place the card behind authentication, since pre-connection discovery is its entire purpose. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-server-cards-well-known-discovery — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Fable 5.1 vs GPT-6 Astra: Which Model Runs MCP Better? > Anthropic and OpenAI shipped flagship models 48 hours apart, at the identical $10/$50 price. For MCP agents the sticker price is a decoy — cache reads, forced tool calls, and approval gating are what actually decide your bill and your uptime. **Source:** https://mcpplaygroundonline.com/blog/fable-5-1-vs-gpt-6-astra-mcp **Author:** Nikhil Tiwari **Published:** 2026-09-05 **Category:** Development **Reading time:** 12 min read --- 📖 TL;DR - **Claude Fable 5.1** (Sept 1) and **GPT-6 Astra** (Sept 3) both list at **$10 in / $50 out** per million tokens. Identical sticker price. - The real gap is **cache reads**: Fable 5.1 charges **$0.25/MTok**, Astra charges **$1.00/MTok**. On a long MCP loop that is a **4x** difference on the tokens you resend most. - Astra edges Fable 5.1 on _Terminal-Bench 4.0_ — **57.7% vs 55.8%**. Close enough that integration details matter more than the leaderboard. - Two breaking changes will bite an existing harness: Fable 5.1 **rejects forced tool choice with a 400**, and Astra ships **approval gating** on every MCP tool by default. - Both are live in [MCP Agent Studio](/mcp-agent-studio) — connect your server, run the same prompt on each, watch every tool call land. Two flagship models landed **48 hours apart**. Anthropic shipped Claude Fable 5.1 on September 1. OpenAI shipped GPT-6 Astra on September 3. Both are aimed at the same job: **long-horizon agents that call real tools**. Which is to say, both are aimed at MCP. And they landed on the exact same price. **$10 per million input tokens, $50 per million output.** That symmetry is not an accident. So the interesting question is not which one is smarter. On _Model Context Protocol_ work, they are close. The question is which one is cheaper and less fragile **when it runs your tool loop twenty turns deep**. That answer is not on either pricing page. I spent this week pointing both at MCP servers — GitHub, Postgres, and a deliberately messy three-server setup. Here is what separates them. Get this wrong and you either pay 4x more than you needed to, or you ship a harness that returns a 400 on its first forced tool call. ## Fable 5.1 vs GPT-6 Astra: The Spec Sheet **Start with what both vendors publish.** The headline numbers are almost eerily matched. Spec Claude Fable 5.1 GPT-6 Astra **API model ID** `claude-fable-5-1` `gpt-6-astra` **Released** September 1, 2026 September 3, 2026 **Input / output per 1M** $10 / $50 $10 / $50 **Cache read per 1M** **$0.25** $1.00 **Context window** 1M tokens 1.05M tokens (922K max input) **Max output** 128K 128K **Effort levels** low → max (5 levels) low → max (5 levels) **Knowledge cutoff** Not published April 30, 2026 **Native MCP support** Yes — MCP connector (beta) Yes — `mcp` tool in Responses API Same price, same output ceiling, same five effort levels, both a hair over a million tokens of context. **On paper this is a tie.** One row is not a tie. **Cache reads differ by 4x** — and for MCP agents, cache reads are most of the bill. More on that shortly. New to the protocol both of these are calling? Start with [what is Model Context Protocol](/blog/what-is-model-context-protocol), then come back. ## How Each Model Connects to an MCP Server **Both support MCP natively now.** Neither makes you hand-roll a client. But the request shapes are not alike. ### Claude Fable 5.1: the MCP connector Anthropic's connector needs **two halves**, and this trips up almost everyone the first time. You declare the server, _and_ you declare a toolset that points back at it by name. Send only the first and the API rejects the request. ``` curl https://api.anthropic.com/v1/messages \ -H "anthropic-beta: mcp-client-2025-11-20" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5-1", "max_tokens": 16000, "mcp_servers": [ { "type": "url", "url": "https://your-server.com/mcp", "name": "issues" } ], "tools": [ { "type": "mcp_toolset", "mcp_server_name": "issues" } ], "messages": [{ "role": "user", "content": "List the open issues." }] }' ``` The `name` in `mcp_servers` and the `mcp_server_name` in `tools` must match exactly. **A typo there reads as a validation error, not a missing tool.** ### GPT-6 Astra: the mcp tool OpenAI folds the server into the regular `tools` array as a single object. **One block, no pairing.** ``` { "model": "gpt-6-astra", "tools": [ { "type": "mcp", "server_label": "issues", "server_url": "https://your-server.com/mcp", "require_approval": "never", "allowed_tools": ["list_issues", "create_issue"] } ], "input": "List the open issues." } ``` Astra's version carries two fields Anthropic's does not. **`allowed_tools` narrows the surface**, and **`require_approval` gates execution**. Both connectors speak _Streamable HTTP_ and _HTTP/SSE_. So a server built on the current spec works with either without changes. If your server still runs the old stateful handshake, read the [2026-07-28 stateless migration guide](/blog/migrate-mcp-server-2026-07-28-stateless) before you point a flagship model at it. **Skip the curl entirely.** Paste your server URL into [Test any MCP server free →](/mcp-test-server) and confirm the handshake and tool schemas are clean before you spend a token on either model. ## The Cache Read Gap Decides Your MCP Bill Here is the finding that surprised me. **The advertised price is a decoy for agent work.** An MCP agent loop is repetitive by design. Every turn resends the system prompt, the full tool schemas, and the entire conversation so far. That resent prefix is what caching exists for. And on a twenty-turn run, **cached reads dwarf fresh input**. So compare the number that actually scales: - **Claude Fable 5.1 — $0.25 per million cached read tokens.** Anthropic cut this by 75% versus Fable 5. - **GPT-6 Astra — $1.00 per million cached input tokens.** Four times more. Put real numbers on it. Say your agent holds **100K tokens of schemas and history** and runs **20 turns**. That is 2M cached read tokens for one session. **Fable 5.1 bills $0.50. Astra bills $2.00.** Cache _writes_ are a wash — both land around $12.50 per million. **The divergence is entirely on reads**, the operation an agent performs constantly. Astra has a second cost cliff worth knowing. **Requests over 272K input tokens reprice the whole request at $20 in / $75 out.** MCP hits that ceiling faster than chat does. A few verbose tool outputs and a large schema set will get you there. Astra does claw some back elsewhere. **Batch and flex run at half price** — $5 in, $25 out — which is real money for offline evals and backfills. Anthropic's counter is that Fable 5.1 costs roughly **25% less than Fable 5 on typical workloads, and up to 45% less on heavily agentic ones**. That gap is the cache read cut showing up in the invoice. My read: **if your workload is a live, chatty MCP loop, Fable 5.1 is meaningfully cheaper**. If it is a large offline batch, Astra's half-price batch tier closes the gap. ## Benchmarks That Actually Predict MCP Tool Calling Most benchmark tables are useless for MCP. **Chat quality does not predict whether a model picks `complete_task` over `delete_task`.** Two published benchmarks do correlate with agent behaviour: terminal work and computer use. Both measure multi-step tool sequences that recover from failure. Benchmark Fable 5.1 GPT-6 Astra **Terminal-Bench 4.0** 55.8% **57.7%** **Humanity's Last Exam (tools)** 65.0% Not published in this format **Terminal-Bench-Science 0.1** 52.6% Not published **OSWorld 2.0** 77.9% partial / 41.7% strict 72.6% (single figure) **Terminal-Bench 4.0 is the only clean head-to-head**, and Astra takes it by 1.9 points. That is a real but narrow win. Do not read the OSWorld row as a comparison. **Anthropic reports partial and strict scoring; OpenAI reports one number.** Different rulers. Vendors also grade their own homework. So treat both columns as directional, not decisive. A 1.9-point spread on one benchmark will not decide your architecture. **The integration constraints in the next section will.** For the broader picture across model families, see [the best AI model for MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling). ## Two Breaking Changes That Will Bite Your MCP Harness This is the part nobody puts in a launch post. **Both models changed rules your existing agent code probably depends on.** ### Fable 5.1 rejects forced tool choice If your harness sets `tool_choice` to `any` or names a specific tool, **Fable 5.1 returns a 400**. Not a warning. A hard error. That pattern is everywhere in MCP code. It is the standard way to guarantee the model calls a tool instead of answering in prose. The error also fires on token counting and the Batch API, so a test suite will catch it in odd places. Three fixes, in order of how well they work: - **Use `tool_choice: auto` plus an explicit instruction** naming the tool you want called. - **Set `strict: true` on the tool** so arguments still validate against your schema exactly. - **Switch to structured outputs** if the forced call only existed to get JSON back. There is a second, quieter one on Fable 5.1: **conversation history must be append-only**. Editing an earlier turn invalidates the thinking blocks attached to it. Any MCP harness that rewrites or trims history mid-run — a common context-saving trick — needs a look before you switch models. ### Astra gates every MCP tool behind approval Astra's `require_approval` field defaults to asking. **Your loop must handle an approval round-trip** or it will appear to stall. Set it to `never` for servers you trust and control. Leave it on for anything third-party. That default is a feature, not friction. It is the API admitting that **a remote MCP server sees everything in the model's context**. OpenAI's own docs put it bluntly: a malicious server can exfiltrate sensitive data from anything that enters the model's context. If your servers are private, both vendors point you at a tunnel rather than a public URL. **Do not expose an internal MCP server to the internet just to satisfy a connector.** ## Astra's Cyber Rating Changes How You Secure MCP Servers One difference has no equivalent on the Anthropic side. **Astra is the first OpenAI model rated Critical for cybersecurity capability.** In plain terms: it can find previously unknown security flaws and develop working exploits **without a person guiding each step**. OpenAI gated the rollout because of it, shipping first to customers on its Daybreak cybersecurity program. Here is why that lands on your desk. **An MCP server is an unusually attractive target** — it is an authenticated, tool-shaped door into your systems. Tool poisoning, prompt injection through tool descriptions, over-broad scopes. These were already the top MCP risks. A model this capable raises the floor for whoever is probing your server. **The defender needs to move first.** Scan before you connect anything to a production server. [Scan your MCP server →](/mcp-security-scanner) for tool poisoning and injection paths. Then work through the [MCP server security guide](/blog/mcp-server-security-complete-guide-2026) for the full checklist. ## Which One Should You Pick for MCP? **Neither wins outright.** They win different workloads, and the split is cleaner than the benchmarks suggest. Your workload Pick Why Long live agent loops, many turns **Fable 5.1** 4x cheaper cache reads compound every turn Offline evals, batch, backfills **Astra** Batch and flex at half price Terminal and shell-heavy agents **Astra** Leads Terminal-Bench 4.0, 57.7% to 55.8% Untrusted third-party MCP servers **Astra** Built-in approval gate and `allowed_tools` Harness that forces tool calls today **Astra** Fable 5.1 needs a rewrite first Very large tool output per request **Fable 5.1** No 272K repricing cliff My default would be **Fable 5.1 for anything interactive and long-running**. The cache read economics are hard to argue with. I would reach for **Astra on shell-shaped agents and on servers I do not own**. The approval gate earns its place there. And honestly? **Run the same prompt on both against your own server.** Your tool schemas will decide this more than any benchmark. That is a five-minute test now that [both models are in the Agent Studio list](/mcp-agent-studio). No keys, no install. ## How MCP Playground Helps **This is exactly the comparison MCP Playground exists for.** It runs in the browser, with no local install and no API keys of your own. Connect any MCP server, pick _Claude Fable 5.1_, _GPT-6 Astra_, or any of 70+ models, and watch each tool call land with its real input and output. Server testing is free, agent runs spend credits by model tier, and sign-up includes free credits. Both flagships sit in the **Frontier tier at 50 credits per run** — they list at the same $10/$50 per million tokens, so they price the same here too. That makes the head-to-head in this post cheap to reproduce. **Run one prompt, switch model, compare the tool calls** — same server, same schemas, same turn count. Spend Frontier credits where a wrong tool call costs more than the model does. For everyday reads, drop to Sonnet 5 or Haiku 4.5. ## Frequently Asked Questions **Is Fable 5.1 or GPT-6 Astra better for MCP?** Fable 5.1 is cheaper on long interactive loops thanks to $0.25 cache reads. Astra leads Terminal-Bench 4.0 and ships built-in approval gating. Pick by workload shape, not leaderboard. **Do both models support MCP natively?** Yes. Fable 5.1 uses the MCP connector with paired `mcp_servers` and `mcp_toolset` entries. Astra takes a single `mcp` tool object in the Responses API. **Why is my Fable 5.1 request returning a 400?** Most likely forced tool choice. Fable 5.1 rejects `tool_choice: any` and named tools. Switch to `auto` with an explicit instruction. **Do they really cost the same?** Only at the sticker. Both are $10/$50 per million, but Astra's cache reads cost 4x more and its long-context tier reprices requests over 272K tokens. **How do I connect an MCP server to GPT-6 Astra?** Add one tool object with type `mcp`, a `server_label`, and your `server_url`. Use `require_approval` to gate execution and `allowed_tools` to narrow the surface. **What does Astra's Critical cyber rating mean for my server?** It raises the baseline capability of anyone probing you. Scan for tool poisoning, injection through tool descriptions, and over-broad scopes before exposing a server. **What do they cost per run in MCP Playground?** Both sit in the Frontier tier at 50 credits, matching their identical $10/$50 list price. Server testing is free and unlimited, so verify schemas before you spend anything. ## Conclusion **Two flagship models, one price, and a genuinely close race on capability.** The deciding factors are cache read economics, one removed API feature, and one new safety default. Fable 5.1 wins the long agent loop on cost. Astra wins terminal work and untrusted servers. Both will run a spec-compliant MCP server without changes. The only test that settles it is your own server, with your own tool schemas. [Test any MCP server free →](/mcp-test-server) and then switch between Fable 5.1 and Astra mid-chat to see which one holds the plan. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work and what to measure. Other guides in this series: [Claude Fable 5](/blog/claude-fable-5-mcp-servers), [Claude Opus 5](/blog/claude-opus-5-mcp-servers), [GPT-5.6 Sol, Terra & Luna](/blog/gpt-5-6-mcp-servers-sol-terra-luna), [GLM 5.3](/blog/glm-5-3-mcp-servers), [MCP agent tool calling](/blog/what-is-mcp-agent-tool-calling). ## Frequently asked questions ### Is Claude Fable 5.1 or GPT-6 Astra better for MCP servers? It depends on the workload. Fable 5.1 is cheaper for long interactive MCP agent loops because cached reads cost $0.25 per million tokens against Astra $1.00, a 4x gap on the tokens an agent resends every turn. Astra leads the one clean head-to-head benchmark, Terminal-Bench 4.0, at 57.7% versus 55.8%, and ships approval gating plus an allowed_tools filter that make it the safer default for third-party MCP servers you do not control. ### Do Claude Fable 5.1 and GPT-6 Astra cost the same? Only at the headline. Both list $10 per million input tokens and $50 per million output tokens. The real difference is in caching: Fable 5.1 charges $0.25 per million cached read tokens while Astra charges $1.00. Astra also reprices any request over 272K input tokens at $20 in and $75 out, though its batch and flex tiers run at half price. ### How do I connect an MCP server to Claude Fable 5.1? The MCP connector needs both halves of the request. Add the server to mcp_servers as a url entry with a name, then add a matching mcp_toolset entry to tools with mcp_server_name set to that same name, and send the mcp-client-2025-11-20 beta header. Sending mcp_servers alone is rejected as a validation error. The connector speaks Streamable HTTP and HTTP/SSE. ### How do I connect an MCP server to GPT-6 Astra? Set model to gpt-6-astra in a Responses API request and add a single tool object with type mcp, a server_label, and the server_url. Optional fields include require_approval to gate execution, allowed_tools to restrict which tools the model may call, and authorization for an OAuth access token. Remote servers need a public URL, or a Secure MCP Tunnel for private and on-premises servers. ### Why does Claude Fable 5.1 return a 400 on my tool call? Forced tool use was removed. Fable 5.1 returns a 400 for tool_choice type any and for a named tool, including on count_tokens and the Batch API. Replace it with tool_choice auto plus an explicit instruction naming the tool, set strict true on the tool definition to keep arguments schema-valid, or move to structured outputs if the forced call only existed to return JSON. ### What does the Critical cybersecurity rating on GPT-6 Astra mean for MCP servers? GPT-6 Astra is the first OpenAI model to reach the Critical level of cybersecurity capability, meaning it can find previously unknown security flaws and develop exploits without step-by-step human guidance. OpenAI gated its rollout because of it. For MCP operators it raises the baseline capability of anyone probing your server, so scan for tool poisoning, prompt injection through tool descriptions, and over-broad scopes before exposing a server. ### How many credits do Claude Fable 5.1 and GPT-6 Astra cost per run in MCP Playground? Claude Fable 5.1 and GPT-6 Astra both run at 50 credits per agent run, in the Frontier tier alongside Claude Fable. They list at the same $10 in and $50 out per million tokens, so they cost the same to run here, which makes a direct head-to-head cheap. Server testing itself is free and unlimited, so connect, list tools, and verify schemas first, then spend Frontier credits only on the agent runs where reasoning quality actually decides the outcome. --- _Canonical page: https://mcpplaygroundonline.com/blog/fable-5-1-vs-gpt-6-astra-mcp — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Agent Skills vs MCP vs Function Calling vs A2A (2026 Guide) > Agent Skills, MCP, function calling and A2A are four different layers of the same agent stack, not four competing choices. Here is what each one actually does, the context cost of picking wrong, and a decision table you can apply to your next build. **Source:** https://mcpplaygroundonline.com/blog/agent-skills-vs-mcp **Author:** Nikhil Tiwari **Published:** 2026-09-02 **Updated:** 2026-09-02 **Category:** Comparison **Reading time:** 14 min read --- 📖 TL;DR - **Agent Skills** teach an agent _how_ to do something. A folder with a SKILL.md file. No server, no auth, no runtime. - **MCP** gives an agent _access_ to something. A live JSON-RPC server exposing tools, resources and prompts. - **Function calling** is the model-level primitive underneath both. Provider-specific JSON schemas, no discovery, no transport. - **A2A** connects one agent to _another agent_. A horizontal link, where MCP is the vertical one. - Rule of thumb: **knowledge → Skill. Connectivity → MCP. One provider, one app → function calling. Cross-agent delegation → A2A.** - They compose. The MCP working group is now standardising [Skills over MCP](#skills-over-mcp), which merges the top two. Table of Contents 1. [Four Layers, Not Four Choices](#four-layers) 2. [What Are Agent Skills?](#agent-skills) 3. [What Is MCP?](#what-is-mcp) 4. [What Is Function Calling?](#function-calling) 5. [What Is A2A?](#a2a) 6. [Agent Skills vs MCP: The Real Difference](#skills-vs-mcp) 7. [Side-by-Side Comparison](#comparison) 8. [When to Use Each](#when-to-use) 9. [Skills over MCP](#skills-over-mcp) 10. [One Real Stack, All Four](#real-stack) 11. [Five Expensive Mistakes](#mistakes) 12. [How to Test the MCP Layer](#testing) 13. [FAQ](#faq) Every week someone asks me whether **Agent Skills replace MCP**. The question is wrong, and picking the wrong one is expensive. Wrap procedural knowledge in an MCP server and you burn context on every session. Wrap live database access in a Skill and it simply cannot reach the database. I have shipped both. **Agent Skills vs MCP is not a versus at all** — they sit at different layers, alongside function calling and A2A. This post gives you the one-sentence distinction for each, a decision table you can paste into a design doc, and the five mistakes I see teams make. I also cover _Skills over MCP_, the MCP working group effort that merges the two standards. It changed how I plan agent architecture in 2026. ## Four Layers, Not Four Choices Here is the whole argument in one table. **Each row answers a different question**, which is why teams end up shipping all four. Layer Answers Shape Runtime? **Agent Skills** How do I do this task? Folder with SKILL.md No **MCP** What can I reach? JSON-RPC client/server Yes **Function calling** How does the model ask? JSON schema in the API call Your code **A2A** Who else can do this? Agent-to-agent HTTP protocol Yes **Function calling is the floor.** MCP standardises what sits on top of it. Skills sit above MCP as instructions. A2A sits beside all three. ## What Are Agent Skills? An _Agent Skill_ is a folder containing a `SKILL.md` file. That is the entire required surface area. Anthropic shipped Skills in Claude in October 2025 and **released the format as an open standard on 18 December 2025** at agentskills.io. The frontmatter needs exactly two fields. Everything else is optional. ``` my-skill/ ├── SKILL.md # required: metadata + instructions ├── scripts/ # optional: executable code ├── references/ # optional: docs loaded on demand └── assets/ # optional: templates, schemas ``` ``` --- name: incident-postmortem description: Write a blameless postmortem from an incident timeline. Use when the user mentions an outage, incident review, or RCA. license: Apache-2.0 allowed-tools: Bash(git:*) Read --- ## Steps 1. Pull the incident timeline from the linked doc. 2. Separate trigger, contributing factors and detection gap. 3. Never name individuals. Name systems and processes. ``` The rules are tight. **`name` is max 64 characters**, lowercase alphanumerics and single hyphens, and must match the directory name. `description` is max 1024 characters and does the real work. It is the only thing the agent sees until the skill fires. ### Progressive disclosure is the whole trick Skills load in three stages, and this is why they are cheap. 1. **Discovery** — only `name` and `description` load at startup, roughly 100 tokens per skill. 2. **Activation** — the full SKILL.md body loads when a task matches. Keep it under 5,000 tokens. 3. **Execution** — bundled scripts and reference files load only if the instructions reach for them. **You can install fifty skills and pay almost nothing until one fires.** Try that with fifty MCP servers and your context window is gone before the first message. **Portability check:** the same SKILL.md folder is read by Claude Code, ChatGPT and Codex, Cursor, GitHub Copilot, VS Code, Gemini CLI, JetBrains Junie, Kiro, Goose and OpenCode. Write once, run in any of them. ## What Is MCP? The _Model Context Protocol_ is a live client-server protocol. It gives an agent access to systems it does not already have. MCP uses **JSON-RPC 2.0 between hosts, clients and servers**. Servers expose three primitives: tools, resources and prompts. The current revision is **2026-07-28**, which moved the base protocol to stateless, self-contained requests with per-request capability negotiation. That matters for deployment. Stateless servers scale horizontally without sticky sessions, which the older session-bound transport required. If MCP is new to you, start with my [guide to the Model Context Protocol](/blog/what-is-model-context-protocol) before going further. The critical property: **an MCP server does something**. It queries Postgres, hits the Stripe API, reads a file. A Skill cannot do any of that on its own. ### The context cost nobody warns you about Most MCP clients load **every connected server's full tool list into the system prompt at session start**. Names, descriptions and complete input schemas. Connect eight servers with fifteen tools each and you have spent a serious chunk of the context window before the user types anything. This is the single strongest practical argument for Skills. It is also why [tool description quality](/blog/mcp-tool-description-quality) is worth obsessing over. Not sure how much context your MCP server is costing? Connect it in the browser, see every tool schema the model receives, and watch a real model decide which one to call. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Count your tool-schema tokens](https://mcpplaygroundonline.com/mcp-token-counter) ## What Is Function Calling? _Function calling_ is a model capability, not a protocol. You pass JSON schemas in the API request and the model returns a structured call. **You still write every piece of plumbing.** Execution, auth, retries, error shaping, and a new adapter for each provider you support. There is no discovery. The model cannot ask what tools exist — you hand it the list on every request. Function calling is the right choice when **one app talks to one provider and owns all its tools**. Adding MCP there is pure overhead. It is the wrong choice the moment a second client needs the same tools. I unpacked the trade-offs in [MCP vs function calling vs REST APIs](/blog/mcp-vs-function-calling-vs-api-comparison). Worth remembering: **MCP does not replace function calling**. Under the hood an MCP client still converts tools into function-calling schemas for the model. ## What Is A2A? _A2A_ (Agent2Agent) connects agents to other agents. Google announced it in April 2025 and donated it to the Linux Foundation that June. An agent publishes an **Agent Card** at a well-known URL describing its skills, endpoint and auth. Other agents read it to decide whether to delegate. Note the collision: A2A uses the word "skills" for advertised agent capabilities. **Those are not Agent Skills as in SKILL.md.** Different concept, same word. The axis is what separates them. **MCP is vertical, agent down to tools. A2A is horizontal, agent across to agents.** Full breakdown in my [MCP vs A2A comparison](/blog/mcp-vs-a2a-agent2agent-protocol). ## Agent Skills vs MCP: The Real Difference Strip everything else away and it comes down to one line. **MCP gives an agent a capability it did not have. A Skill gives an agent judgment it did not have.** Ask one question about your use case: **does the agent need to reach a system it cannot currently reach?** Yes means MCP. The agent has no path to your warehouse, your ticketing system, your internal API. No means a Skill. The agent already has the tools — it just does not know your process, your naming conventions, your review checklist. ### Four differences that show up in production **Context cost.** Skills load metadata first, body on demand. MCP tool schemas load in full, up front, whether used or not. **Operations.** A Skill is Markdown in git. An MCP server is running software with uptime, tokens, versioning and a protocol to track. **Failure mode.** A bad Skill produces bad output you can read and fix. A broken MCP server produces timeouts, 401s and [\-32602 errors](/blog/mcp-error-32602). **Security surface.** A Skill runs bundled scripts with your agent's permissions. An MCP server is an external system that can return prompt-injection payloads in tool results. Neither is safe by default. **Both need review before you point an autonomous agent at them.** ⚠️ Skills are executable, not documentation A skill can bundle scripts and declare `allowed-tools` to pre-approve them. Installing a skill from a public marketplace is closer to installing an npm package than reading a README. Audit it. [Scan your MCP server →](https://mcpplaygroundonline.com/mcp-security-scanner) ## Side-by-Side Comparison Agent Skills MCP Function calling A2A **Provides** Procedural knowledge Live system access Structured intent Delegation **Artifact** SKILL.md folder Server process JSON schema Agent Card + endpoint **Context cost** ~100 tokens idle Full schemas, always Full schemas, always Card only, on discovery **Needs hosting** No Yes Your app Yes **Cross-vendor** Yes, 40+ clients Yes No, per provider Yes **Governance** Open spec, agentskills.io Linux Foundation Each model vendor Linux Foundation **Best for** Repeatable workflows Shared integrations Single-app tools Multi-agent systems ## When to Use Each ### Build an Agent Skill when… - The task is **process and judgment**, not access — a code review checklist, a brand style guide, a postmortem format. - You keep pasting the same instructions into chat. - The agent already has the tools and just applies them wrongly. - You want the same behaviour across Claude Code, Codex and Cursor without maintaining three configs. - The knowledge changes often and non-engineers should be able to edit it. ### Build an MCP server when… - The agent needs **live data or a real side effect** — a query, a write, a deploy. - Access requires credentials the agent must not see in plaintext. - Multiple clients or teams need the same integration. - You need an audit trail of every call. - You are exposing your product to customers' agents. See [why your SaaS needs an MCP server](/blog/why-your-saas-needs-an-mcp-server). ### Use plain function calling when… - One app, one model provider, three or four tools you fully own. - Nothing external will ever consume those tools. - You want the smallest possible dependency footprint. ### Reach for A2A when… - Independent agents, owned by **different teams or vendors**, must hand work to each other. - The remote side should stay a black box, exposing outcomes rather than tools. - Tasks are long-running and need their own status lifecycle. ## Skills over MCP: The Two Standards Are Converging Here is what most comparison posts miss. **MCP is absorbing skills as a first-class concept.** The _Skills over MCP_ effort started as an interest group in February 2026 and became a full working group on 16 April 2026. It is co-led by maintainers from Nordstrom and Anthropic, with participants from Google, GitHub, AWS, Databricks, Bloomberg and Saxo Bank. The current direction is **SEP-2640, a Skills Extension built on MCP's existing Resources primitive**, on the Extensions Track rather than the core spec. The practical result: an MCP server will be able to ship **both the tools and the instructions for using them**, discovered through one connection. That is a real shift. Today you install a Postgres MCP server and separately write a Skill explaining your schema conventions. Under the extension, the server hands over both. **Progressive disclosure, currently a Skills-only property, comes to MCP.** It is still in review, so do not build on it yet. But it settles the strategic question — **Skills and MCP were never going to be rivals**. MCP already has precedent for this pattern. [Tasks](/blog/mcp-tasks-extension-long-running-operations) and MCP Apps landed the same way, as opt-in extensions negotiated at initialization. ## One Real Stack, All Four Take a support-triage agent I would actually build. Every layer earns its place. 1. **MCP** connects it to Linear, Sentry and Postgres. That is how it reads the ticket, the stack trace and the affected rows. 2. **An Agent Skill** holds your triage policy — severity ladder, escalation thresholds, the exact template your team expects. 3. **Function calling** happens invisibly underneath, when the model emits the structured call your MCP client executes. 4. **A2A** delegates anything billing-related to the finance team's agent, which owns credentials you should never hold. Remove the Skill and the agent files sloppy, inconsistent tickets. **Remove MCP and it cannot see the incident at all.** That asymmetry is the answer to the whole debate. They fail differently because they do different jobs. ## Five Expensive Mistakes **1\. Wrapping documentation in an MCP server.** If the tool just returns static text, it should have been a Skill. You are paying schema tokens for a Markdown file. **2\. Expecting a Skill to fetch live data.** A Skill has no network of its own. It can only tell the agent to use tools the agent already has. **3\. Writing vague descriptions.** The `description` field is the entire retrieval signal. "Helps with PDFs" will never fire; naming the trigger conditions will. **4\. Connecting every MCP server you find.** Tool schemas compound. Eight servers of marginal value can crowd out the two that matter. **5\. Shipping either one untested.** Teams test the model and skip the tool layer. Then a renamed parameter breaks production silently. Build [MCP evals](/blog/what-is-an-mcp-eval) before you need them. ## How to Test the MCP Layer Skills are easy to review — they are Markdown, you read them. **The MCP layer is where things break quietly.** I use MCP Playground for this. Paste a server URL, see every tool and schema the model would receive, then let a real model try to call them. That last part matters. A server that passes `tools/list` can still confuse a model into never calling the right tool. Only a live model run reveals that. Skills are Markdown. Your MCP server is production software. Test it against Claude, GPT and Gemini in the browser — no install, no config file, no local setup. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Chat with your server in Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio) ## The Decision, In One Paragraph Ask whether the gap is knowledge or access. **Knowledge gaps are Skills. Access gaps are MCP servers.** Keep function calling for single-app tools you own outright, and reach for A2A only when a separate team's agent owns the work. Then test the layer that can actually fail at runtime. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) ## Frequently Asked Questions **Do Agent Skills replace MCP?+** No. Skills package procedural knowledge as a SKILL.md folder with no runtime; MCP is a live client-server protocol that gives an agent access to external systems. A skill cannot query a database or call an API on its own. Most production agents use both, and the MCP Skills over MCP working group is standardising a Skills Extension so one server can deliver tools and instructions together. **Which is cheaper on context, a Skill or an MCP server?+** A skill, by a wide margin, when idle. Skills use progressive disclosure: only the name and description load at startup, roughly 100 tokens each, and the full body loads only when the task matches. Most MCP clients load every connected server's complete tool schemas into the system prompt at session start, whether or not those tools are ever used. **Are Agent Skills Claude-only?+** No. Anthropic released the format as an open standard on 18 December 2025 at agentskills.io. The same SKILL.md folder is read by Claude and Claude Code, ChatGPT and Codex, Cursor, GitHub Copilot, VS Code, Gemini CLI, JetBrains Junie, AWS Kiro, Block Goose and roughly forty other clients listed on the official showcase. **Is MCP just function calling with extra steps?+** No, though MCP sits on top of function calling. Function calling is a model capability: you pass JSON schemas per request and write all the execution, auth and error handling yourself, per provider. MCP standardises discovery, transport, auth and execution so one server works with any MCP client. An MCP client still converts tools into function-calling schemas before sending them to the model. **What are the required fields in a SKILL.md file?+** Two: name and description. The name is max 64 characters, lowercase letters, numbers and single hyphens, and must match the parent directory name. The description is max 1024 characters and should state both what the skill does and when to use it. Optional fields are license, compatibility, metadata and the experimental allowed-tools. **Are the "skills" in an A2A Agent Card the same as Agent Skills?+** No, and the naming collision causes real confusion. A2A skills are capability advertisements inside an Agent Card, telling other agents what a remote agent can do. Agent Skills are SKILL.md folders of instructions loaded into a single agent's context. Different specs, different purposes, same English word. **Can I test a Skill and an MCP server the same way?+** Not really. A skill is Markdown, so review is reading it and running the agent against sample tasks. An MCP server is running software with a wire protocol, so it needs connection, handshake, tool schema and error testing against a real model. A browser tester such as MCP Playground covers the second case without any local setup. ## Related Guides - [What Is the Model Context Protocol (MCP)? A Developer's Guide](/blog/what-is-model-context-protocol) - [MCP vs Function Calling vs REST APIs: When to Use Each](/blog/mcp-vs-function-calling-vs-api-comparison) - [MCP vs A2A: Model Context Protocol vs Agent2Agent](/blog/mcp-vs-a2a-agent2agent-protocol) - [AI Agent + MCP Explained: What Every Developer Needs to Know](/blog/ai-agent-mcp-explained) - [What Is an MCP Agent? Tool Calling Explained](/blog/what-is-mcp-agent-tool-calling) - [Migrating to the 2026-07-28 Stateless MCP Spec](/blog/migrate-mcp-server-2026-07-28-stateless) - [What Is an MCP Eval, and Why You Need One](/blog/what-is-an-mcp-eval) ## Further Reading - [Official: Agent Skills Specification](https://agentskills.io/specification) - [Agent Skills spec and reference library on GitHub](https://github.com/agentskills/agentskills) - [Claude Code: Extend Claude with skills](https://code.claude.com/docs/en/skills) - [OpenAI Codex: Skills documentation](https://developers.openai.com/codex/skills/) - [Official: MCP Specification (2026-07-28)](https://modelcontextprotocol.io/specification/latest) - [MCP: Skills over MCP Working Group charter](https://modelcontextprotocol.io/community/working-groups/skills-over-mcp) - [SEP-2640: Skills Extension proposal](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2640) - [Official: A2A Protocol Docs](https://a2a-protocol.org/) 🤖 See which layer your agent is actually missing Connect your MCP server in [MCP Agent Studio](/mcp-agent-studio) and watch a real model pick tools from your schemas. If it picks the right tool and still does the task wrong, you need a Skill — not another server. Works with Claude, GPT, Gemini and more. Free credits on sign-up. ## Frequently asked questions ### Do Agent Skills replace MCP? No. Skills package procedural knowledge as a SKILL.md folder with no runtime; MCP is a live client-server protocol that gives an agent access to external systems. A skill cannot query a database or call an API on its own. Most production agents use both, and the MCP Skills over MCP working group is standardising a Skills Extension so one server can deliver tools and instructions together. ### Which is cheaper on context, a Skill or an MCP server? A skill, by a wide margin, when idle. Skills use progressive disclosure: only the name and description load at startup, roughly 100 tokens each, and the full body loads only when the task matches. Most MCP clients load every connected server complete tool schemas into the system prompt at session start, whether or not those tools are ever used. ### Are Agent Skills Claude-only? No. Anthropic released the format as an open standard on 18 December 2025 at agentskills.io. The same SKILL.md folder is read by Claude and Claude Code, ChatGPT and Codex, Cursor, GitHub Copilot, VS Code, Gemini CLI, JetBrains Junie, AWS Kiro, Block Goose and roughly forty other clients listed on the official showcase. ### Is MCP just function calling with extra steps? No, though MCP sits on top of function calling. Function calling is a model capability: you pass JSON schemas per request and write all the execution, auth and error handling yourself, per provider. MCP standardises discovery, transport, auth and execution so one server works with any MCP client. An MCP client still converts tools into function-calling schemas before sending them to the model. ### What are the required fields in a SKILL.md file? Two: name and description. The name is max 64 characters, lowercase letters, numbers and single hyphens, and must match the parent directory name. The description is max 1024 characters and should state both what the skill does and when to use it. Optional fields are license, compatibility, metadata and the experimental allowed-tools. ### Are the skills in an A2A Agent Card the same as Agent Skills? No, and the naming collision causes real confusion. A2A skills are capability advertisements inside an Agent Card, telling other agents what a remote agent can do. Agent Skills are SKILL.md folders of instructions loaded into a single agent context. Different specs, different purposes, same English word. ### Can I test a Skill and an MCP server the same way? Not really. A skill is Markdown, so review is reading it and running the agent against sample tasks. An MCP server is running software with a wire protocol, so it needs connection, handshake, tool schema and error testing against a real model. A browser tester such as MCP Playground covers the second case without any local setup. --- _Canonical page: https://mcpplaygroundonline.com/blog/agent-skills-vs-mcp — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Unity MCP: 10 Things You Can Do (And The Deprecation Nobody Mentions) > Unity MCP connects Claude Code, Cursor and Codex straight into a running Unity Editor so an agent can build scenes, edit C#, read the console and run Play Mode tests. Unity deprecated its own in-Editor MCP server in 2026 and moved it into the Unity CLI, which is the part every other guide still gets wrong. **Source:** https://mcpplaygroundonline.com/blog/unity-mcp-server-guide **Author:** Nikhil Tiwari **Published:** 2026-08-31 **Category:** Development **Reading time:** 13 min read --- TL;DR - **Unity MCP puts an AI agent inside a running Unity Editor.** Scenes, GameObjects, C# scripts, the console, tests and builds. - **Unity deprecated its own in-Editor MCP server.** The docs now say to use the **Unity CLI** instead. - The replacement is `unity mcp configure `, backed by the Unity Pipeline package. Free, local, no Unity AI subscription. - The community **MCP for Unity** server is still the widest surface: **47 tool entrypoints**, MIT, Unity 2021.3 through 6.x. - Every Unity MCP path is **stdio on your own machine**, so it inherits stdio risk. [Read this before you install one.](/blog/mcp-stdio-rce-vulnerability) The pitch for **Unity MCP** sounds like marketing until you watch it work. You type "create a cube at the origin and give it a Rigidbody" into Claude Code. The cube appears in your open Editor. Seconds, not minutes. That is the whole idea. _Model Context Protocol_ gives an AI agent a typed set of tools, and Unity MCP makes those tools reach into a live Editor session. **But there is a catch that most guides published this year have not caught up with.** Unity shipped an official in-Editor MCP server, then deprecated it. If you follow a tutorial from six months ago you will wire up a path Unity is actively moving off. So this covers what works, what moved, and ten things worth doing once it is connected. Table of Contents 1. [What Is Unity MCP?](#what-is-unity-mcp) 2. [Three Unity MCP Servers, One Deprecated](#three-paths) 3. [10 Things You Can Do With Unity MCP](#ten-things) 4. [How to Set Up Unity MCP](#setup) 5. [Unity MCP Security: What Actually Worries Me](#security) 6. [Where Unity MCP Falls Over](#limits) 7. [Unity MCP FAQ](#faq) ## What Is Unity MCP? **Unity MCP is an MCP server that exposes the Unity Editor as a set of callable tools.** Your agent becomes the client. Unity describes it plainly in its own docs: MCP "connects large language model (LLM)-based agents, such as Claude Code and Cursor, to the Unity Editor through standardized MCP tools." New to the protocol itself? Start with [what the Model Context Protocol is](/blog/what-is-model-context-protocol), then come back. The architecture matters here because it explains every failure mode you will hit later. ``` AI client (Claude Code, Cursor, Codex, Windsurf) | | MCP over stdio v Relay / server process (local, on your machine) | | IPC: named pipe on Windows, Unix socket on macOS + Linux v Unity Editor (bridge + registered tools) ``` **Notice what is missing: a network hop.** There is no hosted Unity MCP URL you paste into a client. The Editor has to be **open and running**. Close Unity and every tool call fails. That is the single most common support question in every Unity MCP project. ## Three Unity MCP Servers, One Deprecated Search "Unity MCP" and you get three different things wearing the same name. They are not interchangeable. Path Status (Aug 2026) Unity versions **Unity CLI** — `unity mcp` **Current official path** Unity 6.0 LTS or later **In-Editor server** — `com.unity.ai.assistant` **Deprecated** Unity 6 (6000.0)+ **MCP for Unity** — CoplayDev, community Active, MIT, v10.1.2 2021.3 LTS through 6.x **Straight from Unity's own documentation:** "Unity MCP server is deprecated. Use the Unity command-line interface (CLI) instead. Unity CLI provides faster iteration times, improved stability, and the ability to target runtime and the Editor." That banner sits on top of [every Unity MCP page in the 2.18 docs](https://docs.unity3d.com/Packages/com.unity.ai.assistant@2.18/manual/integration/unity-mcp-overview.html). The migration is not painful. Unity built the CLI replacement **on the same protocol**, so your agent does not know the difference. **The important detail is licensing.** Unity states the CLI is free and separate from Unity AI, and installing it does not require a Unity AI subscription. If you are on Unity 2022 or an older LTS, the official path is closed to you. Unity CLI needs 6.0 LTS to drive a running Editor. That is why [MCP for Unity](https://github.com/CoplayDev/unity-mcp) still has 13,000+ stars. ## 10 Things You Can Do With Unity MCP Tool names below are from **MCP for Unity v10**, which publishes its catalog openly. The official surface covers the same ground under Unity's own naming, such as `Unity_ManageScript`. ### 1\. Build scenes and GameObjects by describing them This is the demo everyone leads with, and it is genuinely the fastest win. `manage_scene`, `manage_gameobject` and `find_gameobjects` let the agent open scenes, spawn objects, set transforms and attach components. **Where it earns its keep is grey-boxing.** "Lay out a 3-lane corridor 40 units long with cover blocks every 8 units" is tedious by hand and trivial for a tool loop. ### 2\. Write and patch C# without leaving the chat `manage_script` creates and reads scripts. `script_apply_edits` applies targeted edits instead of rewriting whole files. **That distinction is the difference between usable and infuriating.** Whole-file rewrites blow away code the model never read. Unity's official server exposes a _Validation Level_ setting for its script tool, with `basic`, `standard`, `comprehensive` and `strict` options. MCP for Unity ships Roslyn validation for the same reason. Turn validation up. A rejected edit costs you one retry. A silently broken script costs you a domain reload and a confused debugging session. ### 3\. Close the compile-error loop automatically Here is where Unity MCP stops being a party trick. `read_console` returns Editor console output. `refresh_unity` forces a recompile. **Chain them and the agent gets a feedback loop.** Write code, refresh, read the errors, fix, repeat — without you copy-pasting a stack trace. An agent that cannot read your console is guessing. One that can is debugging. ### 4\. Run Edit Mode and Play Mode tests `run_tests` drives the Unity Test Runner and hands results back to the agent. The Unity CLI covers this outside the Editor too, with `unity test` writing an NUnit report for CI. **Pair it with rule 3 and you get the full loop:** change code, compile, run tests, read failures, iterate. That is the only setup I would trust for anything beyond prototyping. ### 5\. Manage prefabs, materials, shaders and textures Asset plumbing is where hours quietly disappear. `manage_prefabs`, `manage_material`, `manage_shader`, `manage_texture` and `manage_asset` cover creating, editing and wiring those up. **Bulk operations are the real use case.** "Set every material in Assets/Env to the URP Lit shader and point them at the matching normal map" is a script you now do not have to write. ### 6\. Generate placeholder art, models and audio in-Editor MCP for Unity v10 added `generate_image`, `generate_model` and `generate_audio`, plus `import_model` and `import_model_file`. **Treat this as prototyping, not production.** Generated meshes are for blocking out a level, not shipping one. Still, replacing forty grey capsules with something roughly shaped like the thing you mean is a real speedup during a game jam. ### 7\. Wire physics, animation, VFX and UI The tool surface goes deeper than most people expect. - `manage_physics` — colliders, rigidbodies, layer collision settings - `manage_animation` — clips and controller state - `manage_vfx` — particle and VFX Graph systems - `manage_ui` — canvases and UI hierarchies - `manage_probuilder` — in-Editor geometry authoring - `manage_components` — add, remove and configure any component **These are also the tools most worth disabling when you do not need them.** Both servers support tool groups and per-tool toggles, and every unused tool is context you pay for on every request. Trim your tool list before you blame the model Forty-plus tool schemas is a lot of tokens before your prompt even starts. If tool selection feels sloppy, cut the groups you are not using. Our [MCP token counter guide](/blog/mcp-token-counter-optimize-context-window) shows how to measure the cost. ### 8\. Profile performance and inspect graphics settings `manage_profiler` and `manage_graphics` expose profiler data and render settings to the agent. **The honest framing: this is triage, not optimisation.** An agent reading profiler output can tell you which frame spiked and which system owns it. Deciding what to do about a 4ms culling cost is still your job. ### 9\. Trigger builds and manage packages `manage_build`, `manage_packages` and `manage_editor` handle build targets, Package Manager operations and Editor state. The Unity CLI is stronger here because it works headlessly. `unity build` runs batch-mode builds with CI-friendly flags, and `unity install` manages Editor versions. **That is the reason Unity gave for the deprecation.** The CLI can target runtime and the Editor; the in-Editor bridge could only ever talk to a window you had open. ### 10\. Register your own tools — and use the escape hatches carefully This is the one that changes how you use it long term. Unity's server discovers tools at Editor startup. Decorate a static method and it becomes an MCP tool: ``` [McpTool("spawn_wave", "Spawn an enemy wave preset into the active scene")] public static object SpawnWave(WaveParameters parameters) { return new { success = true, spawned = parameters.Count }; } ``` Unity supports four registration styles: static methods with typed parameters, static methods taking `JObject`, class-based tools implementing `IUnityMcpTool`, and runtime registration via `McpToolRegistry.RegisterTool`. **A tool that encodes your team's conventions beats a generic one every time.** The agent stops guessing at your prefab naming scheme because you handed it the rule. MCP for Unity also ships blunter instruments: `execute_menu_item`, `execute_custom_tool`, `batch_execute` and `execute_code`. About `execute_code` A tool that runs arbitrary C# in your Editor is arbitrary code execution with your user account's permissions. It is useful. It is also the tool I would disable first on any machine holding source control credentials or signing keys. ## How to Set Up Unity MCP ### Option A: Unity CLI (official, Unity 6.0 LTS+) Install the CLI, install the pipeline package, point your agent at it. Three commands. ``` # macOS / Linux brew install --cask unity-cli # Windows winget install Unity.CLI unity pipeline install unity mcp configure claude # or cursor, vscode, windsurf unity mcp configure --list # see every supported client ``` **Use in-Editor AI assistant package 2.13 or later** if you have it installed, otherwise it fights the CLI for the same connection. Check it worked with `unity status`, which prints connected Editors with port, project path and process ID. `unity list` dumps every registered tool with its parameter schema. ### Option B: MCP for Unity (community, 2021.3 LTS+) Add the package by git URL in Package Manager, then let it configure your clients. ``` https://github.com/CoplayDev/unity-mcp.git?path=/MCPForUnity#v10.1.2 # or via OpenUPM openupm add com.coplaydev.unity-mcp ``` Then **Window → MCP for Unity → Configure All Detected Clients**. It needs Python 3.10+ through `uv`. **Pin the version tag.** Tracking `#main` on a tool that edits your source files is a choice you will regret exactly once. Not sure your client config is even valid? Our [guide to MCP config files](/blog/complete-guide-mcp-config-files-claude-desktop-cursor-lovable) covers the JSON shape for every major client, and [the troubleshooting guide](/blog/mcp-server-troubleshooting-common-errors-fix) covers what to do when it silently fails. ### Running more than one Unity project at once By default the relay grabs the first Editor it finds. With two projects open, that is a coin flip. Unity's relay takes `--project-path` or `--instance-id`, or the `UNITY_PROJECT_PATH` and `UNITY_INSTANCE_ID` environment variables. MCP for Unity has `set_active_instance`. ## Unity MCP Security: What Actually Worries Me Every Unity MCP path runs locally over stdio. That sounds safer than a remote server. It is not automatically safer. **A local stdio server runs as you, with your filesystem and your credentials.** There is no sandbox, no scope, no revocable token. We covered how that goes wrong in [the MCP stdio RCE writeup](/blog/mcp-stdio-rce-vulnerability). The short version: a compromised or malicious local server is game over. Unity does build in a real control. Direct connections from external MCP clients **require explicit approval** in Project Settings, under Pending Connections. Approve deliberately. Approved clients are remembered for future sessions, so a careless click persists. There is one more setting worth knowing: **Auto-approve in Batch Mode** approves all incoming connections when Unity runs headless. Convenient for CI, dangerous on a shared build machine. Pairing Unity with a remote MCP server? Unity MCP itself is local, but most real agent setups also connect a remote server for source control, issue tracking or analytics. Those are the ones worth checking before you grant them a token. [Scan your MCP server →](/mcp-security-scanner) [Test any MCP server free →](/mcp-test-server) ## Where Unity MCP Falls Over I would rather you hit these in this article than at 1am before a milestone. - **Domain reloads break everything mid-call.** Recompiling C# tears down the Editor's app domain. A tool call in flight during that dies. - **The Editor must stay open.** No open project means no tools. This is not a headless service. - **Undo coverage is uneven.** Some operations land in the undo stack. Some do not. Commit before you let an agent loose. - **Large scenes flood context.** Asking for a full hierarchy dump on a real production scene will bury your context window. - **Package conflicts are real.** There is an open issue where `com.unity.ai.assistant` on Unity 6.5 livelocks the AssetDatabase so the Editor never opens — and it looks exactly like an MCP failure. **The version control point deserves emphasis.** An agent with `manage_script` and `manage_asset` can touch dozens of files in one turn. Work on a branch. Commit before each session. That is the entire mitigation and it takes ten seconds. ## Should You Use Unity MCP? **Yes, for prototyping, tooling and test loops.** The compile-fix-test cycle alone justifies the setup time. **Not yet as an unsupervised authoring pipeline.** Review what it changes, the same as any pull request. Pick the CLI if you are on Unity 6.0 LTS or later. Pick MCP for Unity if you are on an older LTS or want the wider tool surface today. And if you are building your own MCP server alongside it — a build-farm server, an asset-pipeline server — [test it in the browser first](/mcp-test-server). Catching a broken tool schema before it reaches an agent saves a long debugging session. Our [step-by-step testing guide](/blog/how-to-test-mcp-servers-step-by-step) walks through it. ## Unity MCP FAQ **Is Unity MCP deprecated?** The in-Editor MCP server shipped in the `com.unity.ai.assistant` package is deprecated. Unity MCP as a capability is not. Unity moved the server into the Unity CLI, where you enable it with `unity pipeline install` and `unity mcp configure `. It is built on the same protocol, so migration is a config change rather than a rewrite. **Do I need a Unity AI subscription for Unity MCP?** No. Unity states the CLI is free and separate from Unity AI, and that installing it does not require a Unity AI subscription. The community MCP for Unity server is MIT licensed. You still pay your own model provider for tokens. **Which Unity versions support Unity MCP?** The official path needs Unity 6.0 LTS or later to drive a running Editor through the Unity Pipeline package. The deprecated in-Editor server needed Unity 6 (6000.0) or later. The community MCP for Unity server supports Unity 2021.3 LTS through 6.x, which is why it remains the practical option on older projects. **Can I test a Unity MCP server in the browser?** Not directly. Unity MCP runs over stdio against a local Editor process, and browser tools cannot spawn local processes. Browser testers like MCP Playground are for remote MCP servers reachable over HTTP. If you expose a remote server alongside Unity, or use MCP for Unity remote-hosted mode with auth, you can test that endpoint in the browser. **Which AI clients work with Unity MCP?** Unity documents Claude Code, Cursor, Windsurf and Claude Desktop for the official server, and `unity mcp configure --list` prints the current supported set. MCP for Unity works with any MCP client, including Claude Desktop and Code, Cursor, VS Code, Windsurf, Cline and Gemini CLI. **Why do my Unity MCP tool calls fail after editing a script?** Almost always a domain reload. When Unity recompiles C#, it tears down and rebuilds the scripting app domain, which drops the MCP bridge for a few seconds. A call in flight during that window fails. Wait for compilation to finish and retry. Unity cites better handling of domain reloads as one reason the CLI replaced the in-Editor server. ## The Short Version Unity MCP hands an AI agent real control over a live Editor: scenes, scripts, assets, the console, tests and builds. **The official in-Editor server is deprecated, and the Unity CLI is the replacement.** On older LTS versions, the community MCP for Unity server is still the way in. Wire up the console and test tools first. That feedback loop is what turns a demo into something you actually keep using. Building your own MCP server? Paste a URL and see every tool, schema and response in the browser. No install, no sign-up. [Test any MCP server free →](/mcp-test-server) ## Sources and Further Reading - [Unity — AI client integration with Unity (MCP)](https://docs.unity3d.com/Packages/com.unity.ai.assistant@2.18/manual/integration/unity-mcp-overview.html) - [Unity — Unity CLI as the replacement for the in-Editor MCP server](https://docs.unity.com/en-us/unity-cli/replace-mcp-server-unity-cli) - [Unity — Unity CLI command reference](https://docs.unity.com/en-us/unity-cli/unity-cli-reference) - [Unity — Register custom MCP tools](https://docs.unity3d.com/Packages/com.unity.ai.assistant@2.18/manual/integration/unity-mcp-tool-registration.html) - [CoplayDev/unity-mcp — MCP for Unity (MIT)](https://github.com/CoplayDev/unity-mcp) - [Model Context Protocol — official documentation](https://modelcontextprotocol.io/introduction) ## Frequently asked questions ### Is Unity MCP deprecated? The in-Editor MCP server shipped in the com.unity.ai.assistant package is deprecated. Unity MCP as a capability is not. Unity moved the server into the Unity CLI, where you enable it with "unity pipeline install" and "unity mcp configure ". It is built on the same protocol, so migration is a configuration change rather than a rewrite. ### Do I need a Unity AI subscription for Unity MCP? No. Unity states the CLI is free and separate from Unity AI, and that installing it does not require a Unity AI subscription. The community MCP for Unity server is MIT licensed and also free. You still pay your own model provider for the tokens your agent consumes. ### Which Unity versions support Unity MCP? The official path needs Unity 6.0 LTS or later to drive a running Editor through the Unity Pipeline package. The deprecated in-Editor server required Unity 6 (6000.0) or later. The community MCP for Unity server supports Unity 2021.3 LTS through 6.x, which is why it remains the practical option on older projects. ### Can I test a Unity MCP server in the browser? Not directly. Unity MCP runs over stdio against a local Editor process, and browser-based tools cannot spawn local processes. Browser testers such as MCP Playground are for remote MCP servers reachable over HTTP. If you expose a remote MCP server alongside Unity, or use MCP for Unity in remote-hosted mode with auth, you can test that endpoint in the browser. ### Which AI clients work with Unity MCP? Unity documents Claude Code, Cursor, Windsurf and Claude Desktop for the official server, and "unity mcp configure --list" prints the currently supported set. The community MCP for Unity server works with any MCP client, including Claude Desktop and Claude Code, Cursor, VS Code, Windsurf, Cline and Gemini CLI. ### Why do my Unity MCP tool calls fail after editing a script? Almost always a domain reload. When Unity recompiles C#, it tears down and rebuilds the scripting app domain, which drops the MCP bridge for a few seconds. Any tool call in flight during that window fails. Wait for compilation to finish and retry. Unity cites better handling of domain reloads as one reason the CLI replaced the in-Editor server. --- _Canonical page: https://mcpplaygroundonline.com/blog/unity-mcp-server-guide — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # WebMCP in 2026: The API Moved and Most Guides Are Wrong > WebMCP lets a web page hand its own tools to an AI agent in the browser. The API moved from navigator.modelContext to document.modelContext mid-2026, Chrome is running an origin trial through version 156, and almost every tutorial online still shows the deprecated call. **Source:** https://mcpplaygroundonline.com/blog/what-is-webmcp **Author:** Nikhil Tiwari **Published:** 2026-08-27 **Category:** Development **Reading time:** 11 min read --- TL;DR - **WebMCP lets a web page register tools directly with a browser AI agent.** No server, no API key, no backend. - The API **moved from `navigator.modelContext` to `document.modelContext`**. Chrome 150 deprecated the old spelling. - It is a **W3C Draft Community Group Report** (last published 26 August 2026), not a ratified standard. - Chrome runs a public **origin trial from version 149 through 156**. Edge is behind a flag. Firefox and Safari have not committed. - **[webmcp.dev](https://webmcp.dev) is the old proposal**, and its author says so. It is not W3C compliant. - Your existing MCP server is unaffected. [Test it here](/mcp-test-server) either way. I went looking for the current state of **WebMCP** and found a mess. Half the tutorials show `navigator.modelContext`. Chrome deprecated that in version 150. Another chunk point at [webmcp.dev](https://webmcp.dev) as the reference implementation. Its own author has since disowned it as the standard. So here is what is actually true in August 2026, checked against the spec and Chrome's own docs. **If you are about to add WebMCP tools to a production site, read the browser support and security sections first.** They are the two places where a working demo turns into a bad afternoon. Table of Contents 1. [What Is WebMCP?](#what-is-webmcp) 2. [WebMCP vs MCP: What Is Actually Different](#webmcp-vs-mcp) 3. [The Breaking Change Most Guides Missed](#breaking-change) 4. [The Current WebMCP API](#webmcp-api) 5. [Which Browsers Support WebMCP?](#browser-support) 6. [The WebMCP Security Model](#security) 7. [Is webmcp.dev Still Worth Using?](#webmcp-dev) 8. [Adoption: A Standard Without Users](#adoption) 9. [Should You Ship WebMCP Tools Today?](#should-you-ship) 10. [FAQ](#faq) ## What Is WebMCP? _WebMCP_ is a proposed web API that lets a page **hand its own functions to an AI agent running in the browser**. The technical name is `document.modelContext`. You call `registerTool()` and the agent can now invoke that JavaScript function. **Think of the page itself as an MCP server** whose tools happen to be implemented in client-side script instead of on a backend. That framing matters. There is no HTTP endpoint, no OAuth flow, and no deployment. The tool is a closure with access to your existing frontend state. It is developed in the **W3C Web Machine Learning Community Group**, edited by engineers from Google and Microsoft. The current text is a [Draft Community Group Report published 26 August 2026](https://webmachinelearning.github.io/webmcp/). **Draft Community Group Report is not a W3C Standard.** WebMCP is not on the W3C Recommendation track. It is incubation, and the repository carries over 100 open issues. ## WebMCP vs MCP: What Is Actually Different The names collide badly. **WebMCP is not a new version of MCP**, and it does not replace anything you have built. If you need the base protocol first, start with [what the Model Context Protocol is](/blog/what-is-model-context-protocol). MCP Tools run on a server you host Any MCP client Claude, Cursor, a cron job, CI ▼  JSON-RPC over HTTP your-app.com/mcp ▼ Your database and APIs Reachable any time, by any client, with its own auth. WebMCP Tools run inside the open tab your-app.com document.modelContext search\_products add\_to\_cart AI Browser agent, calling in-page Exists only while that tab is open, using the session already there. MCP exposes tools over the network. WebMCP exposes them from inside the page the user already has open.   MCP WebMCP Where tools run A server you host The page in the user's tab Transport JSON-RPC over stdio or HTTP A browser API, no network hop Auth OAuth, tokens, API keys The user's existing session cookie Who can call it Any MCP client, anywhere Only an agent on that open page Status Shipping, spec at 2026-07-28 Origin trial in one browser **The reach difference is the whole story.** An MCP server works for any client that knows its URL, including scheduled jobs and CI. A WebMCP tool only exists while somebody has your tab open. That is a feature for personal workflows and a hard ceiling for automation. If you are weighing surfaces more broadly, my [MCP vs function calling vs REST API comparison](/blog/mcp-vs-function-calling-vs-api-comparison) covers the trade-offs. ## The Breaking Change Most Guides Missed Here is the part that will waste your time if nobody tells you. The API originally lived on `navigator`. **The July 2026 draft moved it to `document.modelContext`**, on the reasoning that tools belong to a document, not to the browser. **Chrome 150 deprecated `navigator.modelContext`** while the origin trial still ships both. So old code keeps working, quietly, until it does not. An earlier shape is gone entirely. The `provideContext()` and `clearContext()` methods from the first drafts were **removed in March 2026**. If a tutorial shows `provideContext()`, it is at least five months stale. Close the tab. WebMCP API timeline Chrome 146 Feb 2026 Ships in Canary on `navigator.modelContext`. — Mar 2026 `provideContext()` and `clearContext()` removed from the draft. Chrome 149 May 2026 Public origin trial opens. Ship to real users with a token. — Jul 2026 Draft relocates the API to **`document.modelContext`**. Chrome 150 Jul 2026 `navigator.modelContext` deprecated. Both still ship. Chrome 153 Aug 2026 Unregistering a tool no longer kills in-flight executions. Chrome 156 TBD Origin trial ends. Ship it, extend it, or pull it. Two API shapes have already been retired. Anything written before July 2026 targets the wrong object. Feature-detect rather than assume: ``` // Prefer document, fall back to the deprecated location const mc = document.modelContext ?? navigator.modelContext; if (!mc) { // No WebMCP here. Degrade to your normal UI. return; } ``` ## The Current WebMCP API `ModelContext` extends `EventTarget` and exposes three methods plus one event. ### registerTool() **This is the method you will use 95% of the time.** It takes a tool descriptor and returns a promise. ``` await document.modelContext.registerTool({ name: 'search_products', description: 'Search the catalog and return matching products.', inputSchema: { type: 'object', properties: { query: { type: 'string', description: 'Search terms' }, maxResults: { type: 'number' } }, required: ['query'] }, annotations: { readOnlyHint: true, untrustedContentHint: true }, execute: async ({ query, maxResults }, { signal }) => { const results = await searchCatalog(query, maxResults, { signal }); return JSON.stringify(results); } }); ``` The required fields are `name`, `description` and `execute`. Names are 1 to 128 characters, alphanumeric plus `_`, `-` and `.`. **`execute` resolves to a string**, not to an MCP-style content array. It receives an `AbortSignal` so a user can cancel a running tool. The `description` and `inputSchema` are the entire contract the model reads. This is the same trap that sinks server-side tools — I wrote about [why most MCP tool descriptions are broken](/blog/mcp-tool-description-quality) and every point applies here. ### Unregistering with AbortSignal There is no `unregisterTool()`. **You abort a controller instead**, which fits single-page apps that swap tools per route. ``` const controller = new AbortController(); await document.modelContext.registerTool(tool, { signal: controller.signal }); // Route change: the tool disappears from the agent controller.abort(); ``` As of Chrome 153 an unregister no longer kills in-flight executions. Before that, aborting mid-call broke the running tool. ### getTools() and executeTool() `getTools()` lists registered tools, and `executeTool()` invokes one. **These exist for the agent side**, not usually for your page. ``` const tools = await document.modelContext.getTools(); const all = await document.modelContext.getTools({ fromOrigins: ['https://partner.example'] }); ``` A `toolchange` event fires when the set changes, so an agent UI can refresh its list. ### The declarative form API **You can turn an existing HTML form into a tool with attributes alone.** No JavaScript at all. ```
``` The browser derives a JSON Schema from the form fields. Add `toolautosubmit` and the agent can submit without a click. **Be careful here.** The spec text for the declarative API is still a TODO — only an explainer exists — so the attribute names can move. ## Which Browsers Support WebMCP? Short answer: **one, and only behind an origin trial**. Browser Status Versions Notes Chrome Origin trial 149 – 156 Landed in 146 Canary, Feb 2026. Local testing via `chrome://flags/#enable-webmcp-testing`. Edge Behind a flag Experimental Microsoft co-edits the spec, so shipping is the likely outcome. Firefox No commitment — Engaged in spec discussion, no implementation signalled. Safari No commitment — Present in the conversation, absent from the roadmap. WebMCP browser support as of August 2026. One implementation, and it is time-boxed. An origin trial means you can enable it for real users on your own domain, with a token, for a bounded number of releases. **It also means the API can change under you before it ships for good.** The `navigator` to `document` move already proved that. ## The WebMCP Security Model This is where WebMCP gets genuinely uncomfortable, and it deserves more attention than it gets. **Your tools run with the user's live session.** The agent is already logged in as them, because it is their tab. So a prompt-injected agent inherits everything the user can do. A page it visited earlier can carry instructions into the tool call it makes on yours. The spec gives you three real controls: 1. **Origin isolation.** WebMCP only works in origin-isolated documents. Set `Origin-Agent-Cluster: ?0` and the API disappears. 2. **Permissions Policy.** The `tools` feature defaults to `self`. A cross-origin iframe needs an explicit `allow="tools"`. 3. **`exposedTo`.** Pass an array of origins at registration to scope who may see and call a tool. Use `annotations` honestly too. Mark read-only tools `readOnlyHint: true`, and flag anything returning user-generated text as `untrustedContentHint: true`. **Do not register a destructive tool because it demos well.** "Delete account" and "place order" behind a single agent call is a prompt injection away from a support ticket. Keep a human in the loop for anything irreversible. The threat model is the same one that hits server-side tools. My guide on [safeguarding MCP servers from prompt injection](/blog/safeguarding-mcp-servers-from-prompt-injection) transfers almost line for line. And if you already run an MCP server alongside your site, [scan your MCP server](/mcp-security-scanner) against the OWASP MCP Top 10 while you are thinking about this. ## Is webmcp.dev Still Worth Using? Plenty of search results still send you to [webmcp.dev](https://webmcp.dev). It is worth knowing what that project is. It is **Jason McGhee's original WebMCP proposal**: a drop-in script that exposes `registerTool`, `registerPrompt` and `registerResource`, then bridges the page to a desktop MCP client over a localhost WebSocket. On 12 February 2026 the repository added a note calling it **"an early WebMCP proposal / implementation"** and pointing at the W3C group. It states plainly that it is **not compliant with the W3C spec**. So: fine as a proof of concept, and genuinely useful if you want tools in Claude Desktop today without waiting on browsers. **Wrong thing to build a product on.** The address that matters now is [github.com/webmachinelearning/webmcp](https://github.com/webmachinelearning/webmcp). ## Adoption: A Standard Without Users Now the awkward part. **Almost nobody consumes WebMCP tools yet.** A July 2026 ecosystem review put it bluntly: WebMCP is "a standard with everything except users." Named origin-trial participants reportedly include Expedia, Booking.com and Shopify, but measured deployment sits near zero. No mainstream agent reads these tools today. **Not Claude, not ChatGPT, not Gemini, not Perplexity.** Google has said Gemini in Chrome will be the reference consumer when it ships. That is a classic two-sided bootstrap. Sites will not register tools until agents call them, and agents will not call them until sites register them. A telling detail from the same review: **validator and checker extensions currently outnumber real implementations.** The tooling arrived before the use case. Contrast that with plain MCP, where servers are being adopted as a [buying criterion for SaaS](/blog/why-your-saas-needs-an-mcp-server) right now. ## Should You Ship WebMCP Tools Today? My read, split by situation. **Ship it if** your product is a browser-first workflow tool, your users already live in Chrome, and three to five tools would remove real clicking. The cost is an afternoon. **Wait if** you need agent access from anywhere, your users are on Safari or Firefox, or your tools touch money, deletion or personal data. **In every case, build the MCP server first.** It works today, across every client, and the tool definitions carry over almost unchanged. That ordering also protects you. If the WebMCP surface shifts again, your server keeps working. Our [2026-spec build guide](/blog/build-mcp-server-2026-spec) covers the stateless transport end to end. A reasonable hedge: write your tool logic once as plain functions, then register it twice. Once through your MCP server, once through `document.modelContext`. ## How MCP Playground Helps **MCP Playground tests the half of this that actually works in production today: your MCP server.** Connect any remote endpoint in the browser, run it against 70+ models, and watch the exact arguments each one sends to each tool. No install, no API key. That matters for WebMCP too, because the descriptions and schemas you validate on the server are the same ones you will paste into `registerTool()`. [Test any MCP server free](/mcp-test-server) and see whether a model picks the right tool before you expose it to an agent in a browser tab. ## Frequently Asked Questions **Is WebMCP a W3C standard?** No. It is a Draft Community Group Report from the Web Machine Learning Community Group, last published 26 August 2026. It is not on the W3C Recommendation track. **Do I have to change navigator.modelContext in my code?** Yes. Chrome 150 deprecated it in favour of `document.modelContext`. The origin trial still ships both, so feature-detect and prefer `document`. **Does WebMCP replace my MCP server?** No. WebMCP tools only exist while a user has your page open. A server serves any client at any time, including background jobs. **Which browsers support WebMCP?** Chrome, via an origin trial spanning versions 149 to 156. Edge has it behind a flag. Firefox and Safari have made no commitment. **Can Claude or ChatGPT call WebMCP tools?** Not today. No mainstream agent consumes them yet. Gemini in Chrome is expected to be the first. **Is webmcp.dev the official implementation?** No. It is the original proposal and its author states it is not W3C compliant. Use the Web Machine Learning repository instead. ## Conclusion **WebMCP is a good idea in an early, moving state.** The API relocated to `document.modelContext`, one browser implements it behind an origin trial, and no popular agent calls these tools yet. That makes it worth a prototype and a feature detect, not a rewrite. Register a couple of read-only tools, keep destructive actions behind a human, and check back when Gemini in Chrome ships. Meanwhile the tool contract is the thing that carries over either way — so get that right on the server first. [Test any MCP server free](/mcp-test-server), then [scan it](/mcp-security-scanner) before an agent ever touches it. ## Frequently asked questions ### Is WebMCP a W3C standard? Not yet. WebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group, last published on 26 August 2026 and edited by engineers from Google and Microsoft. A Community Group Report is an incubation document, not a W3C Recommendation, and WebMCP is not currently on the W3C Standards Track. The specification repository still carries over 100 open issues covering unresolved questions such as multimodal input and output, streaming, cross-document tool responses, and schema validation. ### Do I have to change navigator.modelContext in my code? Yes. The API moved from navigator.modelContext to document.modelContext in the July 2026 draft, on the reasoning that tools belong to a document rather than to the browser as a whole. Chrome 150 deprecated the navigator location while the origin trial continues to ship both, so existing code keeps working for now. The safe pattern is to feature-detect and prefer document.modelContext, falling back to navigator.modelContext only if it exists. An older shape is gone entirely: the provideContext() and clearContext() methods from the first drafts were removed in March 2026. ### Does WebMCP replace my MCP server? No. They solve different problems. A WebMCP tool is JavaScript registered by a page, so it only exists while a user has that page open in a supporting browser, and it runs with the user session already present in that tab. An MCP server is reachable by any client at any time, including scheduled jobs, CI pipelines, and desktop assistants, and it carries its own authentication. If you want agent access to your product at all, build the MCP server first: the tool names, descriptions, and JSON Schemas carry over to WebMCP almost unchanged. ### Which browsers support WebMCP? Chrome is the only browser with a working implementation. It landed in Chrome 146 Canary in February 2026 and is in a public origin trial spanning Chrome 149 through 156, with local testing available via the chrome://flags/#enable-webmcp-testing flag. Microsoft Edge has experimental support behind a flag, which is expected given Microsoft co-edits the specification. Firefox and Safari are engaged in the spec discussions but have not committed to implementation timelines. ### Can Claude or ChatGPT call WebMCP tools today? No. As of August 2026 no mainstream agent consumes WebMCP tools, including Claude, ChatGPT, Gemini, and Perplexity. Google has said that Gemini in Chrome will be the reference implementation when it ships. This creates a two-sided bootstrapping problem: sites will not register tools until agents call them, and agents will not call them until sites register them. Reported origin trial participants include Expedia, Booking.com, and Shopify, but measured deployment across the web remains near zero. ### What are the main security risks with WebMCP? WebMCP tools execute with the privileges of the user session already open in the tab, so a prompt-injected agent inherits everything the user can do. The specification provides three controls: WebMCP is only available in origin-isolated documents and is disabled if Origin-Agent-Cluster: ?0 is set; access is gated by a tools Permissions Policy feature that defaults to self, so cross-origin iframes need an explicit allow="tools" attribute; and the exposedTo option on registerTool scopes a tool to a specific array of origins. Beyond that, use the readOnlyHint and untrustedContentHint annotations honestly, and keep irreversible actions such as deletions and payments behind explicit human confirmation. ### Is webmcp.dev the official WebMCP implementation? No. webmcp.dev hosts Jason McGhee's original WebMCP proposal, a drop-in script that exposes registerTool, registerPrompt, and registerResource and bridges the page to a desktop MCP client over a localhost WebSocket. On 12 February 2026 the repository added a note describing it as an early WebMCP proposal and stating explicitly that the implementation is not compliant with the W3C spec, pointing readers to the W3C Web Machine Learning Community Group instead. It remains a useful proof of concept for connecting a page to Claude Desktop today, but it is not the standard. --- _Canonical page: https://mcpplaygroundonline.com/blog/what-is-webmcp — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # GLM 5.3 MCP: Tool Calling Tested and One Costly Regression > Z.AI shipped GLM 5.3 with a 1M context window and stronger agentic tool calling. I ran it against a live MCP server with deeply nested schemas — here is what improved, and the one thing that broke. **Source:** https://mcpplaygroundonline.com/blog/glm-5-3-mcp-servers **Author:** Nikhil Tiwari **Published:** 2026-08-26 **Category:** Development **Reading time:** 10 min read --- TL;DR - **GLM 5.3 landed on OpenRouter on 18 August 2026** — 1M-token context, 131K max output, $1.40 / $4.40 per 1M tokens. - Across three runs it produced **24/24 schema-valid tool calls** — ahead of GLM 5.2 (20/24) and Claude Haiku 4.5 (23/24). - **It ignores structured outputs.** GLM 5.2 returned schema-valid JSON 3/3; GLM 5.3 returned 0/3. - It is a reasoning model, so a small `max_tokens` silently truncates tool calls. Give it room. - Test it against your own server in [MCP Agent Studio](/mcp-agent-studio) — pick GLM 5.3, connect a server, watch every call. Z.AI shipped **GLM 5.3** in August 2026, and if you run MCP servers it is worth a look. The pitch is long-horizon agent work. A _1M-token context window_, 131,072 max output tokens, and reasoning baked in. But release notes do not tell you how a model behaves against **your** tool schemas. So I tested it. I pointed GLM 5.3 at a live MCP server with four deeply nested tools. Then I ran the same eight prompts — three times each — through GLM 5.2, GLM 5.1, and Claude Haiku 4.5. The headline: **GLM 5.3 shapes nested arguments better than any GLM before it**. It also quietly broke something GLM 5.2 did well. Skip this and you will either underrate the model or get bitten by the regression in production. In this guide 1. [What is GLM 5.3?](#what-is) 2. [How I tested GLM 5.3 MCP tool calling](#how-i-tested) 3. [GLM 5.3 vs GLM 5.2 vs Haiku 4.5: the results](#results) 4. [The structured outputs regression](#regression) 5. [Why GLM 5.3 needs a bigger token budget](#token-budget) 6. [When to use GLM 5.3 for MCP servers](#when-to-use) 7. [How to test your MCP server with GLM 5.3](#how-to-test) 8. [Frequently asked questions](#faq) ## What Is GLM 5.3? **GLM 5.3 is Z.AI's reasoning model for software engineering and long-horizon agents.** It is the successor to GLM 5.2. Here is the spec sheet, taken from the OpenRouter model API rather than a marketing page: Spec GLM 5.3 GLM 5.2 Context window 1,048,576 1,048,576 Max output 131,072 262,144 Input / 1M $1.40 $1.19 Output / 1M $4.40 $3.74 Cached input / 1M $0.26 $0.22 Structured outputs Not supported Supported Two things stand out. **Max output halved** versus GLM 5.2, and _structured outputs disappeared_ from the supported parameter list. That second one is not a footnote. I come back to it below, because it changes how you build. Pricing is up roughly 18% on GLM 5.2. Still cheap next to a frontier model, and cheaper per token than Claude Haiku 4.5 on output. ## How I Tested GLM 5.3 MCP Tool Calling **Tool selection is the easy part.** Most decent models pick the right tool from a short list. The hard part is _argument shaping_ — filling a nested JSON schema without violating it. So I used the MCP Playground [complex test server](/mcp-test-server). Four tools, all with deep nesting, enums, and numeric bounds. The tools were `create_user_profile`, `process_order`, `analyze_data`, and `configure_workflow`. I wrote eight prompts, two per tool. Each had one obviously correct tool and enough detail to fill a nested payload. I ran the full set **three times per model** — 24 calls each — so one lucky pass could not carry a result. Then I scored three things, in order of how much they matter: 1. **Tool picked** — did it choose the right tool? 2. **Schema-valid** — did the arguments pass Ajv validation against the tool's real `inputSchema`? 3. **Server-accepted** — did the live MCP server actually execute the call without a validation error? That third check is the one people skip. A call can look fine and still be rejected by the server. **Want to run this on your own server?** You do not need a script. [Test any MCP server free](/mcp-test-server) in the browser, then switch models mid-chat to compare. ## GLM 5.3 vs GLM 5.2 vs Haiku 4.5: The Results Eight prompts, three runs, four models — 24 tool calls per model against the live server: Model Tool picked Schema-valid Server-accepted Median latency **GLM 5.3** 24/24 **24/24** **24/24** 13.2s GLM 5.2 24/24 20/24 20/24 5.4s GLM 5.1 24/24 6/24 6/24 9.9s Claude Haiku 4.5 24/24 23/24 23/24 **3.3s** **GLM 5.3 got a clean sweep — 24 for 24.** Every call valid, every call accepted by the server, in all three runs. GLM 5.2 dropped four. Nearly all of them on the same tool, `configure_workflow`, and mostly the same field. It kept passing an _object_ where the schema wanted a string for `nextStep`. It also passed `null` once for an optional string. That second one is a classic. _Optional does not mean nullable_, and plenty of models conflate the two. GLM 5.1 was the real surprise. It picked the right tool all 24 times, then emitted **truncated JSON** on 18 of them. The arguments simply stop mid-object, with a `finish_reason` of `tool_calls`. Six failures per run, every run. If you are still on GLM 5.1 with nested schemas, check your error logs. Haiku 4.5 was not perfect either. It dropped one call on the same `nextStep` field that tripped GLM 5.2. That tells you something useful: **the hardest field in the suite defeated three of four models.** Only GLM 5.3 got it right every time. The honest caveat: **GLM 5.3 is slow.** Median 13.2 seconds against Haiku's 3.3. It burned about 12,000 completion tokens across eight calls. GLM 5.2 used under 4,000 for the same work. That is the reasoning tax. You pay it in latency and output tokens, and you get accuracy back. ## The Structured Outputs Regression Here is the part that will cost you an afternoon if you upgrade blind. **GLM 5.3 does not honour `response_format` with a JSON schema.** GLM 5.2 does. I sent both models the same strict schema, three times each, asking for a city and a population. GLM 5.2 returned clean, schema-valid JSON on all three runs. Every time, exactly the requested shape. GLM 5.3 returned **zero valid responses out of three**. It wrapped output in markdown code fences and invented its own field names. Instead of `city` it returned `location`. Instead of a number for `population`, it returned a nested object. Do not swap GLM 5.2 for 5.3 in a JSON pipeline If any part of your stack relies on `response_format: json_schema`, GLM 5.3 will break it silently. Your parser will start throwing on markdown fences. Tool calling is unaffected — only structured outputs. This tracks with the OpenRouter metadata. GLM 5.2 lists `structured_outputs` as a supported parameter; **GLM 5.3 does not**. The good news for MCP: _this does not affect tool calls_. Tool arguments go through a different path, and that path is solid. So if you need guaranteed JSON shapes, route that step to GLM 5.2 and keep GLM 5.3 for the agent loop. ## Why GLM 5.3 Needs a Bigger Token Budget My first test run made GLM 5.3 look worse than GLM 5.2. That was my fault, and it is worth explaining. I had `max_tokens` set to 4,000 — fine for a normal model, far too tight for a reasoning one. GLM 5.3 spent that budget thinking, then got cut off **mid tool call**. The result was unparseable arguments and one missing call entirely. Raising the ceiling to 16,000 fixed it completely. Same prompts, same server, 8/8. **If GLM 5.3 seems to emit broken tool calls, check your token ceiling first.** It is almost always this. The failure is nasty because `finish_reason` still reads `tool_calls`, not `length`. Nothing tells you it truncated. ## When to Use GLM 5.3 for MCP Servers After the testing, here is where I would actually reach for it. **Use GLM 5.3 when:** - Your tools have **deeply nested schemas** with enums and numeric bounds - A wrong write is expensive and you would rather wait 13 seconds than roll back - You are running long agent chains that need a big context window - You want frontier-ish argument accuracy at roughly a third of frontier pricing **Skip it when:** - You need **structured JSON output** — use GLM 5.2 instead - Latency matters and your tools are simple — Haiku 4.5 was four times faster here - You are doing high-volume smoke tests where GLM 4.7 Flash is good enough For a wider sweep across providers, the [best AI model for MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling) comparison covers the rest of the field. ## How to Test Your MCP Server With GLM 5.3 You do not need the script I wrote. Four steps in the browser: 1. Open [MCP Agent Studio](/mcp-agent-studio) and paste your server URL. 2. Pick **GLM 5.3** from the model picker, under Z.AI. 3. Send a prompt that should trigger your most complex tool. 4. Open the tool-call inspector and read the arguments it actually sent. That fourth step is the whole point. **Read the arguments, not just the answer.** A model can produce a convincing reply off a half-wrong tool call. The inspector is where that shows up. If your tool descriptions are vague, fix those before blaming the model — [tool description quality](/blog/mcp-tool-description-quality) moves accuracy more than model choice does. And before you point any agent at a production server, [scan your MCP server](/mcp-security-scanner) for tool-poisoning and injection risks. ## How MCP Playground Helps **MCP Playground is where I ran every model in this post.** It is browser-based and free to start. Connect any MCP server, pick GLM 5.3 or any of 70+ models, and watch each tool call as it happens. No API key wrangling. The compare view runs two models on the same prompt side by side — which is exactly how I caught the GLM 5.2 null-versus-optional bug. ## Frequently Asked Questions **Is GLM 5.3 better than GLM 5.2 for MCP?** For tool calling, yes — 24/24 versus 20/24 on nested schemas across three runs. For structured JSON output, no. GLM 5.2 still wins there. **Does GLM 5.3 support parallel tool calls?** In practice yes. It returned two tool calls in a single message when a prompt needed both, even though the parameter is not listed as supported. **Why are my GLM 5.3 tool calls truncated?** Your `max_tokens` is too low. It is a reasoning model and spends tokens before emitting the call. Try 16,000. **How much does GLM 5.3 cost?** $1.40 per 1M input tokens and $4.40 per 1M output, with cached input at $0.26. About 18% more than GLM 5.2. ## Conclusion **GLM 5.3 is the most reliable GLM yet at filling nested MCP tool schemas.** It swept my test where 5.2 dropped one and 5.1 fell apart. You pay for it in latency and output tokens, and you give up structured outputs entirely. Plan around both. The only benchmark that matters is your own server. [Test any MCP server free](/mcp-test-server), then switch between GLM 5.3 and 5.2 mid-chat and read the arguments each one sends. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work, why the same server behaves differently per model, and what to measure. Other guides in this series: [GLM family guide](/blog/test-mcp-server-with-glm-models), [DeepSeek V4](/blog/testing-mcp-with-deepseek), [Qwen](/blog/test-mcp-server-with-qwen-models), [Gemini](/blog/test-mcp-server-with-gemini-models), [Grok](/blog/testing-mcp-with-grok-xai), [Kimi K2.6](/blog/test-mcp-server-with-kimi-k2-6), [Fable 5.1 vs GPT-6 Astra](/blog/fable-5-1-vs-gpt-6-astra-mcp). ## Frequently asked questions ### Is GLM 5.3 better than GLM 5.2 for MCP tool calling? For tool calling, yes. Across three runs of an eight-prompt test against a live MCP server with deeply nested schemas, GLM 5.3 produced schema-valid arguments on 24 of 24 calls and the server accepted all 24. GLM 5.2 managed 20 of 24, mostly by passing an object where the schema required a string. For structured JSON output the answer reverses — GLM 5.2 honours response_format with a JSON schema and GLM 5.3 does not. ### Why are my GLM 5.3 tool calls truncated or unparseable? Your max_tokens ceiling is almost certainly too low. GLM 5.3 is a reasoning model and spends output tokens thinking before it emits the tool call. At max_tokens 4000 it was cut off mid-call, producing unparseable arguments while still reporting a finish_reason of tool_calls, so nothing signals the truncation. Raising the ceiling to 16000 resolved every failure. ### Does GLM 5.3 support structured outputs? No. OpenRouter does not list structured_outputs among its supported parameters, and testing confirms it. Given a strict JSON schema three times, GLM 5.3 returned zero schema-valid responses — it wrapped output in markdown code fences and renamed fields. GLM 5.2 returned valid JSON on all three runs. Tool calling is unaffected, since tool arguments follow a different path. ### How much does GLM 5.3 cost compared to GLM 5.2? GLM 5.3 costs $1.40 per 1M input tokens and $4.40 per 1M output tokens, with cached input at $0.26 per 1M. That is roughly 18 percent more than GLM 5.2 at $1.19 and $3.74. Because GLM 5.3 is a reasoning model it also emits far more output tokens for the same work — about 12,000 versus under 4,000 across eight tool calls in testing — so the real cost gap per task is wider than the headline rate. ### Does GLM 5.3 support parallel tool calls? In practice yes. Given a prompt that required two different tools, GLM 5.3 returned both tool calls in a single assistant message, with and without the parallel_tool_calls parameter set. The parameter is not listed among its supported parameters on OpenRouter, so it appears to be ignored rather than honoured, but the underlying behaviour works. ### What context window does GLM 5.3 have? GLM 5.3 has a 1,048,576-token context window, the same as GLM 5.2. Its maximum output is 131,072 tokens, which is half of GLM 5.2 at 262,144. For long agent chains the input window is rarely the constraint; the output ceiling matters more because reasoning tokens count against it. --- _Canonical page: https://mcpplaygroundonline.com/blog/glm-5-3-mcp-servers — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Why Your SaaS Needs an MCP Server: It Is a Buying Criterion Now > Buyers have started screening vendors for an official MCP server before they sign. I pulled the numbers from a 24,011-server registry to see how real the shift is — and why shipping a bad MCP server is worse than shipping none. **Source:** https://mcpplaygroundonline.com/blog/why-your-saas-needs-an-mcp-server **Author:** Nikhil Tiwari **Published:** 2026-08-26 **Category:** Opinion **Reading time:** 9 min read --- TL;DR - **MCP has quietly become a purchase filter.** Buyers are picking the vendor with an official server over the one without. - The registry we sync holds **24,011 MCP servers**, and **7,839 of them (33%)** publish a remote URL you can hit today. - Roughly **4,100** entries carry a publish date in H2 2025 against nearly **20,000** in H1 2026 — about a fivefold jump. - **A broken MCP server is worse than no MCP server.** The common failure is an endpoint that answers `tools/list` to anyone who asks. - Ship one, then [test it](/mcp-test-server) and [scan it](/mcp-security-scanner) before you put it in a sales deck. In August 2026 Zeno Rocha, of the email company Resend, posted something on X that got 114,900 views in a few days. > "something changed in how i buy software. at work, i only pick services with an official MCP (posthog over plausible). at home, same thing. i use strava because i can ask claude about my runs." > > "i used to care about features, now I care about interacting with my data. no MCP means i have to use your UI. that's a dealbreaker now." > > — @zenorocha, 21 August 2026 I have seen that sentiment building for months. This was the first time I saw someone say it as a _procurement rule_. So I went and checked whether the data backs it up. **It does, and the shift is faster than I expected.** If you sell software and you have been treating MCP as a 2027 problem, this post is the argument for moving it up. In this post 1. [What actually changed: features to access](#what-changed) 2. [The numbers behind the trend](#numbers) 3. [The PostHog vs Plausible test](#posthog-test) 4. [What buyers are actually screening for](#screening) 5. [Why a bad MCP server is worse than none](#worse-than-none) 6. [How to ship one that survives scrutiny](#ship-it) 7. [FAQ](#faq) ## What Actually Changed: Features to Access For twenty years, software was sold on features. You compared two dashboards and picked the better one. **That comparison assumed a human would be doing the clicking.** That assumption is now shaky. If I can ask an agent "which of our accounts churned last month and why", I do not care how nice your charts are. I care whether your data can reach the agent. _An MCP server is the answer to that question._ This reframes your UI as a cost rather than a feature. Every task that requires your interface is a task the buyer cannot automate. That is the whole argument in the tweet, and it is why it resonated. **"No MCP means I have to use your UI."** ## The Numbers Behind the Trend Anecdotes are easy. I run a sync against the public MCP registry, so I checked the actual shape of it. As of 25 August 2026 that registry holds **24,011 servers**. Here is the part that matters for buyers: Measure Count Why it matters Servers in the registry **24,011** The catalogue a buyer checks before asking you Publishing a remote URL **7,839 (33%)** Hosted and reachable — no install, so a buyer can try it in minutes Dated entries, H2 2025 ~4,100 The early-adopter wave Dated entries, H1 2026 **~19,900** Roughly 5x the previous half-year A fivefold jump in six months is not a niche protocol finding its footing. **That is a land grab.** One honest caveat on that last row: publish dates in the upstream registry thin out after early May 2026, so treat the half-year comparison as a floor rather than a precise rate. The 33% remote figure is the one I would put in front of a product team. A third of the field is already _hosted_, not a README telling someone to clone a repo. **Want to see where you stand?** Browse the [MCP registry](/mcp-registry) and search your own category. If a competitor is listed and you are not, that gap is already visible to your buyers. ## The PostHog vs Plausible Test The tweet names two analytics vendors. I checked both against the registry, because a claim like that is worth verifying. **PostHog publishes an official server** under its own GitHub organisation. It resolves in the registry as `io.github.PostHog/mcp`. **Plausible returns nothing.** No official entry, no community entry under that name. So the buying decision described in that post was not a vibe. It was a lookup, and the lookup took about four seconds. That is the uncomfortable bit. _Your absence from the registry is a fact a prospect can check without ever contacting you._ The same pattern holds across categories. [Stripe](/mcp-servers/stripe), [Linear](/mcp-servers/linear), [Sentry](/mcp-servers/sentry), [Vercel](/mcp-servers/vercel) and [Figma](/mcp-servers/figma) all ship official servers. Their closest competitors mostly do not. ## What Buyers Are Actually Screening For "Has an MCP server" is the first filter. It is not the only one, and the later filters are where vendors lose. From what I see people check, in order: 1. **Is it official?** A community wrapper signals the vendor is not committed to it. 2. **Is it hosted?** A remote URL beats "clone this repo and set twelve environment variables". 3. **Does auth work properly?** OAuth or a scoped token, not a static key pasted into a config file. 4. **Do the tools cover write operations?** Read-only servers are demos. Buyers want the agent to act. 5. **Are the tool descriptions good?** This decides whether the agent picks the right tool at all. That last one is invisible in a feature list and decides everything in practice. A vague description makes a capable model guess. We wrote a whole piece on it — [tool description quality](/blog/mcp-tool-description-quality) moves agent accuracy more than swapping models does. ## Why a Bad MCP Server Is Worse Than None Here is the part the trend pieces skip, and it is the reason I would not rush this. **An MCP server is a new front door to your product's data.** Ship it carelessly and you have shipped an incident. The single most common finding we see on public endpoints is depressingly simple. _The server answers `tools/list` to anyone who asks._ No credentials, no rejection. A full inventory of your capabilities, handed to an unauthenticated caller. The second most common is worse. Tools that accept a customer ID as a parameter with **no check that the caller owns that customer**. That is classic IDOR, wearing a new protocol. It is easy to introduce, because the tool schema looks perfectly reasonable. A third pattern: CORS configured to reflect any `Origin`. Combine that with cookie auth and any website can call your server as your logged-in user. The order matters Ship the MCP server to win the deal, then discover the auth gap in an audit, and you have converted a sales advantage into a security review that stalls the contract. Scan before you announce, not after. None of this is exotic. It is the same authorization work your REST API already does, applied to a surface most teams built in a hurry. [Scan your MCP server](/mcp-security-scanner) against the OWASP MCP Top 10 before it goes in a launch post. ## How to Ship One That Survives Scrutiny If you are starting from nothing, the order that works: 1. **Pick five tools, not fifty.** The five questions your customers ask support most often. 2. **Write the descriptions like documentation**, because that is exactly what the model reads. 3. **Build against the current spec.** Our [2026-spec build guide](/blog/build-mcp-server-2026-spec) covers the stateless transport. 4. **Host it.** A remote URL is what turns a repo into something a buyer can try. 5. **Test it with a real agent** before you announce it. 6. **Scan it** for auth, IDOR and CORS problems. Step five is where most teams get a surprise. A server that returns valid JSON can still be unusable by an agent. [Test any MCP server free](/mcp-test-server), point a model at it, and read the arguments it actually sends. ## How MCP Playground Helps **MCP Playground is the browser-based place to check your server before your buyers do.** Connect any endpoint, run it against 70+ models, and watch every tool call with its arguments. No install, no API key. Then run the security scanner over the same URL to catch the unauthenticated `tools/list` before someone else finds it. ## Frequently Asked Questions **Is MCP really a buying criterion, or just developer hype?** Both, for now. It is a real filter among technical buyers and teams building agent workflows. It is not yet on a typical enterprise procurement checklist. **How long does it take to ship an MCP server?** A focused five-tool server is a week of work. Making it safe to expose publicly takes longer than building it. **Do we need a hosted server, or is a repo enough?** A repo counts for the registry. A hosted URL is what a buyer can actually try during an evaluation. **What if a community MCP server for our product already exists?** Treat it as a warning. Someone wants your data in their agent badly enough to build it, and you do not control its auth or its accuracy. ## Conclusion **The buying question has moved from "what can your software do" to "can my agent reach my data".** A registry with 24,011 servers says a lot of vendors already worked that out. The move is not to rush a server out. It is to ship a small, well-described, properly authorised one — and to prove it works before you market it. [Test any MCP server free](/mcp-test-server), then [scan it](/mcp-security-scanner) before it reaches a prospect. ## Frequently asked questions ### Is MCP really a buying criterion, or just developer hype? Both, for now. Among technical buyers and teams building agent workflows it is a genuine filter — people are choosing the vendor with an official MCP server over the one without, and the check takes seconds because the registry is public. It is not yet a line item on a typical enterprise procurement checklist. The direction of travel is clear, though: the public registry we sync grew from roughly 4,100 dated entries in the second half of 2025 to nearly 20,000 in the first half of 2026. ### How long does it take to ship an MCP server for a SaaS product? A focused server covering five high-value tools is roughly a week of engineering work if you already have an API. The longer part is making it safe to expose publicly — authentication, per-tool authorization checks, and CORS configuration typically take more time than building the tools themselves. ### Do we need a hosted MCP server, or is a GitHub repo enough? A repository is enough to appear in the registry, but a hosted remote URL is what lets a buyer actually try your server during an evaluation. Of the 24,011 servers in the registry we sync, 7,839 — about a third — publish a remote URL. That is the group a prospect can test in minutes rather than hours. ### What if a community MCP server for our product already exists? Treat it as a signal rather than a solution. It means demand is real enough that someone built it without you. But you do not control its authentication, its error handling, or the accuracy of its tool descriptions, and your customers will attribute any failure to your product rather than to the third-party wrapper. ### What is the most common security problem with a new MCP server? An endpoint that answers tools/list without credentials, handing an unauthenticated caller a full inventory of your capabilities. The second most common is a tool that accepts a resource ID such as a customer ID without verifying the caller is authorised for that specific record — classic IDOR in a new wrapper. A third is CORS configured to reflect any Origin, which combined with cookie authentication lets any website call your server as your logged-in user. --- _Canonical page: https://mcpplaygroundonline.com/blog/why-your-saas-needs-an-mcp-server — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # SEO MCP Servers: 5 Providers Compared and What They Automate > Semrush, Ahrefs, DataForSEO and OpenSEO all ship MCP servers now. I connected each one, priced them out, and worked out which SEO operations are actually worth handing to an agent. **Source:** https://mcpplaygroundonline.com/blog/seo-mcp-servers **Author:** Nikhil Tiwari **Published:** 2026-08-22 **Category:** Comparison **Reading time:** 14 min read --- TL;DR - **Four remote SEO MCP servers are production-ready:** Semrush, Ahrefs, DataForSEO and OpenSEO - **Google Search Console has no official MCP server** — only community builds. Google Analytics does, but it is local-only and experimental - Semrush and Ahrefs bill in **API units**; DataForSEO is pay-as-you-go from $0.002 a SERP query - The real unlock is **chaining two servers** — research in one, verify in another - Ahrefs' old npm package `@ahrefs/mcp` was archived in February 2026. Use the remote endpoint Every major SEO platform shipped an **SEO MCP server** in the last year. Semrush, Ahrefs and DataForSEO all have one. So does OpenSEO. I connected all four. Some are excellent. One bills you 50 API units for a single question. This is the part nobody tells you: **an agent is a terrible judge of what a query costs**. It will happily burn 5,000 units exploring a hunch. So this guide covers two things. Which providers actually have working servers, and which SEO operations are worth automating once you are connected. I have skipped the vendor marketing. Every endpoint below is from official documentation, and I have flagged the ones that do not exist. ## What Is an SEO MCP Server? An _SEO MCP server_ exposes a platform's SEO data as tools an AI model can call directly. No CSV exports, no dashboard pivoting. If you are new to the protocol itself, start with [what the Model Context Protocol is](/blog/what-is-model-context-protocol). The short version: **MCP is a standard way for a model to discover and call external tools**. The practical difference is chaining. A keyword tool answers one question per export. Through MCP, a model can discover keywords, check which ones you rank for, pull the live SERP for the promising ones, and cross-reference Search Console — **in a single request**. ## The 5 SEO MCP Servers Worth Knowing in 2026 Here is the honest comparison. **Endpoints are quoted from each vendor's own documentation**, not from a directory listing. Provider Endpoint Auth Cost model **Semrush** `mcp.semrush.com/v2/mcp` OAuth or Apikey header API units, subscription **Ahrefs** `api.ahrefs.com/mcp/mcp` OAuth API units, Lite plan+ **DataForSEO** `mcp.dataforseo.com/mcp` Basic auth Pay-as-you-go **OpenSEO** `app.openseo.so/mcp` OAuth or Bearer key Account plan **Google Analytics** Local only (stdio) Google credentials Free, experimental ### 1\. Semrush MCP Server Semrush has the **broadest tool surface of any SEO MCP server**. The endpoint is `https://mcp.semrush.com/v2/mcp` over streamable HTTP. OAuth is the default. No headers needed — the agent registers itself and redirects you to Semrush login. For headless clients, use an API key: `Authorization: Apikey YOUR_API_KEY`. Note the format is _Apikey_, not _Bearer_. That trips people up. **Tools it exposes:** `domain_overview`, `organic_research`, `keyword_research`, `competitors_research`, `backlinks_research`, `audience_research`, `traffic_overview`, `paid_search_research`, `shopping_research`, `position_tracking`, `site_audit` and `projects`. Two of those matter more than the rest. `get_report_schema` and `execute_report` let the model **discover a report shape before calling it**. That is unusually well designed. Most SEO servers make the model guess parameters. The catch is the plan requirement. You need Semrush One Starter, Pro+, or SEO Classic Pro/Guru, which includes 50,000 units. ### 2\. Ahrefs MCP Server Ahrefs runs a remote server at `https://api.ahrefs.com/mcp/mcp` over streamable HTTP, with OAuth. Add it to Claude Code in one line: ``` claude mcp add ahrefs --transport http https://api.ahrefs.com/mcp/mcp ``` **Skip the npm package.** The `@ahrefs/mcp` repo was archived on 24 February 2026. Its own README says it does not work with MCP keys and is outdated. I wasted twenty minutes on that before reading the archive notice. Use the remote endpoint. Ahrefs is the one to watch on cost. **One API call costs a minimum of 50 units**, more for complex requests. Monthly allowances: Lite gets 100,000 units, Standard 400,000, Advanced 1,000,000, Enterprise 2,000,000. Do the arithmetic. On Lite, that is **2,000 calls a month at absolute best**. An agent exploring a competitor set can spend fifty calls answering one question. ### 3\. DataForSEO MCP Server DataForSEO is the one I reach for when I want raw data without a platform subscription. The endpoint is `https://mcp.dataforseo.com/mcp`, with an SSE variant at `/http`. Auth is HTTP Basic — your API login and password, base64-encoded. Less elegant than OAuth, but trivial in a headless environment. **Seven APIs are exposed as tools:** SERP, Keywords Data, Labs, Backlinks, On-Page, Business Data and Domain Analytics. The pricing is the differentiator. **The server itself is free and open source**; you pay only for data. Roughly $0.024 for 100 related keywords, and from $0.002 per live SERP query. There is a $1 trial credit, then a $50 minimum top-up. Per-query pricing suits agents far better than unit allowances. You can watch spend accumulate in real terms instead of guessing what a unit is worth. Prefer running it locally? The config is standard: ``` { "mcpServers": { "dataforseo": { "command": "npx", "args": ["-y", "dataforseo-mcp-server"], "env": { "DATAFORSEO_USERNAME": "your_api_login", "DATAFORSEO_PASSWORD": "your_api_password" } } } } ``` ### 4\. OpenSEO MCP Server OpenSEO runs at `https://app.openseo.so/mcp` over streamable HTTP. OAuth by default, or `Authorization: Bearer oseo_YOUR_KEY` for headless clients. It covers the usual organic set — keyword metrics, live SERPs, competitor comparison, backlinks and Search Console performance. Two things make it worth a look. **The local SEO coverage is unusually deep** for a general platform. Google Business Profile audits, Maps rank grids around a location, review collection, and business category lookups. Most competitors treat local as an afterthought. The second is _project context_. Your business, goals and competitor set persist across calls, so the model stops re-asking who you are. You can see the full tool list on our [OpenSEO MCP server page](/mcp-servers/openseo), or start from the [OpenSEO research agent template](/templates/openseo-research-agent) — it comes pre-wired with a system prompt that constrains queries before they run. ### 5\. Google Analytics MCP Server Google publishes an official GA4 server at `github.com/googleanalytics/google-analytics-mcp`. Set expectations low. It is labelled **experimental, runs locally only, and is read-only**. There is no hosted endpoint. Three tools: `get_account_summaries`, `run_report` and `run_realtime_report`. That covers reporting and nothing else. It cannot edit your GA configuration. For read-only analysis that is fine, and honestly correct. ## Why Google Search Console Has No Official MCP Server This surprises people, so I will be blunt. **As of August 2026, Google does not publish an official Search Console MCP server.** Google has shipped more than 50 MCP servers — BigQuery, Cloud Run, Firestore, Maps, Drive, Gmail, Calendar. Search Console is not among them. Google Analytics having one is why people assume GSC does too. Only GA4 got the official treatment. You have three options: - **A community server.** Several wrap the official Search Console API. Read the source before handing over OAuth credentials to your entire search data - **Build your own** on the Search Console API. It is a small API and a reasonable weekend project - **Use a platform that already integrates GSC.** OpenSEO and Semrush both pull Search Console data through their own connectors The third option is what I do. It avoids a second OAuth grant against a Google property. If you do run a community server, [scan it before you connect it](/mcp-security-scanner). A server holding your Search Console OAuth token deserves scrutiny. ## SEO Operations You Can Actually Automate This is the part that matters. **Not every SEO task is worth handing to an agent.** The ones that pay off share a shape: multi-step, tedious, and requiring data from more than one place. ### Keyword Research to Content Brief The classic chain. Discover keywords, filter by difficulty, check which ones you already rank for, pull the SERP for survivors. Doing that by hand is four exports and a spreadsheet. **As one prompt, it is about ninety seconds.** A prompt that works: ``` Find 20 keywords related to "mcp server testing" with volume above 100 and difficulty under 30. For each, check whether my domain already ranks. For the five best gaps, pull the live SERP and summarise what the top 3 results cover. ``` Constrain it. Without the numeric filters, the model explores and your unit balance evaporates. ### SERP Competitor Teardown Ask which competitors appear across a keyword set, and what they have in common. Semrush's `competitors_research` handles this directly. The useful output is not the list. It is **the pattern across the list** — shared subtopics, content format, page depth. ### Rank Tracking and Regression Alerts Position tracking is available in Semrush (`position_tracking`) and OpenSEO. The automation is not the tracking, it is the triage. Ask for positions that dropped more than three places this week, then have the model pull the current SERP for each and guess why. **That second step is where an agent earns its cost.** A dashboard shows you the drop; the model tells you a new competitor entered. ### Backlink Monitoring Backlink data is available from Semrush (`backlinks_research`), Ahrefs, DataForSEO and OpenSEO. Ahrefs remains the deepest index. Worth automating: new and lost referring domains week over week, with the model classifying whether losses matter. Not worth automating: bulk link auditing. **The unit cost will exceed the value.** ### Technical Audit Triage DataForSEO's On-Page API and Semrush's `site_audit` both surface technical issues. Agents are good at the sorting, not the finding. Feed it the audit and ask which issues actually affect indexation, ordered by how many pages each touches. ### Local SEO and Google Business Profile OpenSEO and DataForSEO's Business Data API both cover this. The automatable operation is the _rank grid_. Check Maps position across a geographic grid, then ask where coverage is weakest and which competitor owns those cells. ### Chaining Two Servers — The Real Unlock Here is what I did not expect. **The interesting workflows use two servers at once.** Research in DataForSEO because queries are cheap. Verify the shortlist in Ahrefs because the index is better. Or pull rankings from an SEO platform and page data from your own database, and ask which ranking pages have stale content. MCP clients merge tools from multiple servers into one list. The model picks across all of them without knowing they are separate. You can test a multi-server setup free in the browser. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) ## How to Pick an SEO MCP Server Four questions, in order: 1. **Do you already pay for one of these?** Then use it. The MCP server is included, not an upsell 2. **Do you need per-query cost visibility?** DataForSEO. Unit allowances hide spend until the balance is gone 3. **Is backlink depth the priority?** Ahrefs, and budget for the 50-unit floor 4. **Is local SEO a real part of the job?** OpenSEO or DataForSEO's Business Data API If you are starting cold with no subscription, **DataForSEO's $1 trial credit is the cheapest way to find out whether any of this fits your workflow**. ## The Credit Problem Nobody Warns You About Every guide skips this, so here it is plainly. **Agents are bad at cost discipline.** A human runs one keyword export and works with it. A model runs four, decides the fourth was wrong, and runs three more. On Ahrefs Lite, that exploration pattern can spend 350 units answering a question worth 50. Three things that help: - **Put numeric limits in the prompt.** "Top 20", "under difficulty 30", "last 28 days" — every constraint is a call the model does not make - **Use a cheaper model for simple fetches.** A single metric lookup does not need a frontier model. Compare the same prompt across models before committing - **Watch the tool calls.** Most clients hide them. If you cannot see which tool ran and what it returned, you cannot tell why a run cost triple That last point is why I test SEO servers in a client that shows raw JSON before wiring them into anything scheduled. ## How MCP Playground Can Help Before you connect an SEO MCP server to a paid workflow, it is worth seeing exactly what it does. [MCP Agent Studio](/mcp-agent-studio) connects any of these endpoints in the browser and shows every tool call with its full JSON input and output — so you can see which tool the model reached for, what arguments it built, and how many calls a question actually costs. You can run the same prompt across 70+ models side by side to find the cheapest one that still picks the right tool, which matters more here than in most MCP use cases, because every wrong tool call has a price attached. ## Frequently Asked Questions **Which SEO platforms have an official MCP server?+** Semrush, Ahrefs, DataForSEO and OpenSEO all run official remote MCP servers. Google Analytics has an official local-only server. Google Search Console does not have an official MCP server as of August 2026 — only community-built options. **Is there an official Google Search Console MCP server?+** No. Google has published more than 50 MCP servers, including BigQuery, Cloud Run, Maps and Google Analytics, but Search Console is not among them. Your options are a community server, building your own on the Search Console API, or using a platform like Semrush or OpenSEO that already integrates GSC data through its own connector. **How much does an SEO MCP server cost to run?+** It depends on the billing model. Semrush and Ahrefs consume API units from your subscription — Ahrefs charges a minimum of 50 units per call, with 100,000 units a month on the Lite plan. DataForSEO is pay-as-you-go, roughly $0.024 for 100 related keywords and from $0.002 per live SERP query, with a $1 trial credit. Agents explore more than humans do, so constrain prompts with explicit numeric limits. **Can I use two SEO MCP servers at the same time?+** Yes, and it is the most useful pattern. MCP clients merge tools from every connected server into a single list, so a model can research in a cheap provider like DataForSEO and verify the shortlist in a deeper index like Ahrefs, without knowing they are separate services. Watch for tool-name collisions when two servers expose similarly named tools. **Why does the Ahrefs npm package not work?+** The @ahrefs/mcp package was archived on 24 February 2026. Its own README states that it does not work with MCP keys, is not maintained, and is outdated. Use the remote endpoint at api.ahrefs.com/mcp/mcp with OAuth instead. **What SEO tasks are not worth automating with MCP?+** Bulk operations where unit cost scales with volume and the output needs no judgement — large-scale link audits are the clearest example. Anything requiring a single metric lookup is also usually faster in the dashboard. Automation pays off on multi-step work that pulls from more than one source and needs interpretation, like triaging a rank drop or turning an audit into a prioritised list. ## Conclusion Four SEO platforms now ship working remote MCP servers, and the endpoints above are all from official docs. Search Console is the notable gap, and Google Analytics is local-only. Pick based on what you already pay for, then constrain your prompts hard — the difference between a useful agent and an expensive one is almost entirely in how specific you are. Before you wire any of these into a scheduled workflow, connect it in a browser and watch the tool calls. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) ## Frequently asked questions ### Which SEO platforms have an official MCP server? Semrush, Ahrefs, DataForSEO and OpenSEO all run official remote MCP servers. Google Analytics has an official local-only server. Google Search Console does not have an official MCP server as of August 2026 — only community-built options. ### Is there an official Google Search Console MCP server? No. Google has published more than 50 MCP servers, including BigQuery, Cloud Run, Maps and Google Analytics, but Search Console is not among them. Your options are a community server, building your own on the Search Console API, or using a platform like Semrush or OpenSEO that already integrates GSC data through its own connector. ### How much does an SEO MCP server cost to run? It depends on the billing model. Semrush and Ahrefs consume API units from your subscription — Ahrefs charges a minimum of 50 units per call, with 100,000 units a month on the Lite plan. DataForSEO is pay-as-you-go, roughly $0.024 for 100 related keywords and from $0.002 per live SERP query, with a $1 trial credit. Agents explore more than humans do, so constrain prompts with explicit numeric limits. ### Can I use two SEO MCP servers at the same time? Yes, and it is the most useful pattern. MCP clients merge tools from every connected server into a single list, so a model can research in a cheap provider like DataForSEO and verify the shortlist in a deeper index like Ahrefs, without knowing they are separate services. Watch for tool-name collisions when two servers expose similarly named tools. ### Why does the Ahrefs npm package not work? The @ahrefs/mcp package was archived on 24 February 2026. Its own README states that it does not work with MCP keys, is not maintained, and is outdated. Use the remote endpoint at api.ahrefs.com/mcp/mcp with OAuth instead. ### What SEO tasks are not worth automating with MCP? Bulk operations where unit cost scales with volume and the output needs no judgement — large-scale link audits are the clearest example. Anything requiring a single metric lookup is also usually faster in the dashboard. Automation pays off on multi-step work that pulls from more than one source and needs interpretation, like triaging a rank drop or turning an audit into a prioritised list. --- _Canonical page: https://mcpplaygroundonline.com/blog/seo-mcp-servers — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # I Built a Deterministic MCP Eval Engine, Then Deleted Half of It > Scripted MCP evals looked obviously correct: no model near the verdict, every check machine-decidable. Then I ran them against servers I had not seen, and almost every failure turned out to be my own planner guessing arguments. Here is what broke, what replaced it, and the structured-output landmines I hit on the way. **Source:** https://mcpplaygroundonline.com/blog/mcp-eval-engine-design **Author:** Nikhil Tiwari **Published:** 2026-08-15 **Updated:** 2026-08-15 **Category:** Development **Reading time:** 14 min read --- TL;DR - **I built scripted MCP evals with nine deterministic check types and no model in the verdict.** It was the right design for servers I already understood. - **It did not generalise.** A planner guessing arguments produces a -32602 indistinguishable from a real server defect. - **Harvesting real values first is what makes a failure mean something** — and it created the failed-vs-untestable rule. - **Agentic evals replaced it**, because an agent picks arguments with the real schema in front of it and adapts when a call fails. - **The model still never decides an outcome.** Code derives pass/fail from the transcript; a judge only grades answer correctness, and fails open. - **Three structured-output landmines cost me days**: Anthropic rejecting numeric bounds, OpenAI requiring every key in `required`, and open records silently producing empty arguments. Table of contents - [The design that looked obviously right](#v1) - [Where it broke](#broke) - [The harvest pass, and the rule it bought](#harvest) - [What replaced it](#agentic) - [Keeping the model out of the verdict](#code) - [The judge fails open](#judge) - [Fail-closed tool safety](#safety) - [Three structured-output landmines](#landmines) - [What I would tell you to copy](#lessons) I spent a few weeks building an **MCP eval framework** where no model touched the pass/fail decision. Then I deleted the part I was proudest of. This is the writeup of why. It is mostly about a mistake, because the mistake is the useful part. If you are building anything that evaluates MCP servers you did not write, you will hit the same wall. It is not obvious until you are past it. ## The design that looked obviously right The premise was sound and I would still defend it in isolation: **a model fumbling an argument produces an error indistinguishable from a server defect.** So keep models away from the verdict. That instinct is not unusual. Most eval frameworks built on the [Model Context Protocol](https://modelcontextprotocol.io/) start here, and the research benchmarks like [MCP-Bench](https://openreview.net/forum?id=fe8mzHwMxN) pair deterministic rule checks with judging for the same reason. The architecture followed directly. A writer model emits _data_ — concrete calls plus the checks to run against them. Code does the calling and the deciding. ``` { "kind": "direct", "tool": "list_issues", "args": [{ "name": "status", "json": "\"open\"", "source": "literal" }], "checks": [ { "type": "succeeds" }, { "type": "output_schema" }, { "type": "max_items", "limit": 50 } ] } ``` Nine check types, every one machine-decidable: `succeeds` no error, no isError `output_schema` validates against declared schema `error_code` expected JSON-RPC code `pagination_terminates` cursor loop ends, no dupes `idempotent` same call, same result `no_mutation` witness tool proves nothing changed Plus `is_error`, `max_items` and `latency_under`. Schema validation ran through [Ajv](https://ajv.js.org/) in non-strict mode, because MCP servers ship hand-written schemas full of harmless non-standard keywords. A check could also come back **skipped**. Asserting output-schema conformance against a tool that declares no `outputSchema` proves nothing, so that is neither a pass nor a failure. On servers I knew, this worked beautifully. Every failure was a real finding, with the request and response sitting right there as evidence. ## Where it broke Then I pointed it at servers I had never seen. The planner has your tool list, your descriptions and your schemas. What it does not have is **any idea what data actually exists inside your system.** So it has to guess arguments. And every defect I hit lived in that guessing. ### Cross-entity ID matches The planner sees `list_teams` returns objects with an `id`, and `get_project` takes a `projectId`. It is a plausible leap. It is also wrong, and the resulting 404 looks exactly like a broken lookup. ### Calls that failed for unrelated reasons A planner invents `{ "region": "us-west-3" }`. Your server supports four regions and that is not one of them. You get a clean -32602. **Is that your bug or mine?** From the outside, the two are identical. That question has no answer from the response alone, and a report full of unanswerable questions is worthless. ### The empty-arguments disaster This one was my fault and I will come back to it in the landmines section. An entire suite of calls went out with `{}` as arguments, and every single one "failed". The realisation I had built something that measured **my planner's ability to guess arguments** and reported the result as a verdict on someone else's server. The determinism was real. It was just deterministically measuring the wrong thing. ## The harvest pass, and the rule it bought The first fix was to stop guessing. Before planning anything, **collect real values from the server.** The harvest pass calls read-only tools in a deliberate order — list and search shapes first, fewest required parameters first — and only when every required parameter can already be satisfied. Nothing is invented at this stage. It walks the responses for ID-shaped fields and keeps where each came from: ``` { "key": "issueId", "value": "PROJ-4821", "from": "list_issues({ status: 'open' })", "path": "items[0].id" } ``` That provenance is the whole point. It gives you a rule that makes failures mean something: **If `get_issue("PROJ-4821")` 404s on an ID that `list_issues` returned a second earlier, that is a confirmed defect** — the ID demonstrably exists and both calls are the evidence. If the ID was invented, a 404 proves nothing. So anything built from synthesized values is reported **untestable**, never **failed**. Every argument carries a source: `harvested`, `synthesized` or `literal`. The report reads completely differently once that distinction exists. **Untestable is not a softer failure.** It is an admission that the eval could not establish anything, which is far more honest than a red row a developer will correctly ignore. ## What replaced it Harvesting helped. It did not fix the underlying problem: **the planner was still choosing arguments for a system whose semantics it cannot see.** So I stopped having it choose. The plan became agentic-only. Instead of scripting `get_issue("PROJ-4821")` and checking the result, the planner writes a task: ``` Task: "Which open issue in the billing project has been waiting longest, and who is it assigned to?" Budget: 4 tool calls Expectation: names a specific issue and an assignee ``` A driver model gets your real tools and works it out. **It picks arguments with your actual schema in front of it, and adapts when a call fails** — exactly like a real client. The agent loop runs on the [Vercel AI SDK](https://ai-sdk.dev/), with plan schemas defined in [Zod](https://zod.dev/) and tools loaded straight from the server's own `tools/list` response. That generalises to servers nobody anticipated, which scripted calls never did. The tradeoffs are real and I will not pretend otherwise. Results are non-deterministic, so you reproduce before acting. And coverage is whatever the agent exercises, not a guaranteed sweep of every tool. I took that deal because **a narrow honest signal beats a broad meaningless one.** See what this produces A finished eval run, replayed step by step — tools classified, tasks written, transcripts and verdicts. No sign-up. [Walk through MCP Evals →](https://mcpplaygroundonline.com/mcp-evals) ## Keeping the model out of the verdict Going agentic did not mean giving up on determinism where it still applies. **The outcome is derived in code, from the transcript.** ``` no final answer -> failed_answer answered, over the budget -> too_many_calls answered, within budget -> pass (subject to the judge) harness or transport error -> untestable ``` Only the last step consults a model, and only about whether the _answer_ is right. Never about whether a call succeeded. One detail I got wrong first time: **the agent loop has to be allowed to exceed its budget.** My first version capped the loop at exactly the budget. Every over-budget run then looked like a failure to answer — a different and much less useful finding. Now the ceiling sits above the budget, so going over is _observable_ rather than truncated. You learn the agent needed seven calls, which is the signal you actually wanted. The budget is also fixed at generation time, not per run. **If the budget moved between models, a cross-model comparison would not be a fair test.** ## The judge fails open The judge answers exactly one question: given the task, the expectation and the answer, is the answer correct? It never sees whether a call succeeded. It cannot turn a pass into a failure on any ground other than wrong content. The rule that matters most is what happens when it breaks: ``` // A missing verdict must not silently become a failure — an // unjudged answer is treated as correct, since the deterministic // layer already passed it. ``` **If the judge errors out, every item stays passing.** Losing your grader should never invent defects in someone's server. This feels wrong the first time you write it. Surely an unjudged item is unknown, not passing? But consider the alternative: a rate limit on your judge provider turns into a page of red rows and someone spends an afternoon chasing bugs that do not exist. Judging is also batched — one call per slice rather than per case. Per-case judging tripled the recurring cost of every run for no extra signal. ## Fail-closed tool safety This constraint shapes more of the engine than anything else, and it is worth stating plainly. **A functional eval calls tools with arguments designed to succeed.** That is the entire point of it. Which means pointing one at an unannotated `delete_record` would really delete a record. Not a mock. Not a dry run. Someone's actual data. So classification is fail-closed. An unannotated tool is treated as destructive and excluded from a default run. But **unknown and destructive must not read the same in the UI**, even though both get excluded: Classification What it means **destructive** The server told us it mutates. Opting in is a real risk. **unknown** The server told us nothing. It may well be read-only; we just cannot prove it. Since most MCP servers in the wild declare no annotations at all, collapsing these two would leave the common case with an empty selection and no explanation of what to do about it. One more rule I had to enforce against myself: **a tool's name has no authority over whether it mutates.** Name patterns like `list_` or `search_` only rank which read-only tools to harvest from first. They never upgrade a tool's safety classification. ## Three structured-output landmines These cost me real days and I have not seen them written down anywhere, so here they are. ### 1\. Anthropic rejects numeric range keywords on integers Write `z.number().int().positive()` in a schema for structured output and the request fails outright, before the model ever runs. The validator rejects `exclusiveMinimum`, then `minimum`, and by extension `maximum`. **The fix is better design anyway:** enforce bounds after generation, in code. A schema constraint makes the provider reject the whole response. Code can clamp one bad field and keep an otherwise good plan you already paid a frontier model to write. ### 2\. OpenAI requires every property in `required` This one only surfaced when I changed the writer model, which made it maddening to track down. ``` 'required' is required to be supplied and to be an array including every key in properties. Missing 'uncovered'. ``` A Zod `.default()` makes a field optional, and OpenAI and Azure structured outputs reject any object whose `required` array does not list every property. Anthropic accepted it happily. **No `.default()` and no `.optional()` anywhere in a structured-output schema.** Handle the empty case in code. ### 3\. Open records silently produce empty objects This is the one that produced that whole suite of empty-argument calls. `z.record(z.unknown())` compiles to an object schema with **no declared properties**. Structured output cannot invent keys for such a schema. The model has no way to express `{"query": "Workers KV"}`, so it returns `{}`. No error. No warning. Just empty arguments across every case. The fix is a list of explicit entries instead of an open map: ``` args: [ { name: "query", json: "\"Workers KV\"", source: "literal" } ] ``` **The `json` field carries the JSON encoding of the value**, so strings, numbers, booleans, objects and arrays all travel through one string field unambiguously. Fully expressible, no guessing. If you are building anything with structured outputs, that pattern is worth stealing on its own. ## What I would tell you to copy Five things generalise beyond MCP. **1\. Provenance decides meaning.** The same 404 is a confirmed defect or proof of nothing, depending entirely on where the input came from. Track it. **2\. "Untestable" is a real outcome.** Any evaluator that only has pass and fail will report noise, and developers will learn to ignore the whole report. **3\. Let models produce data, not decisions.** Even in the agentic design, outcome derivation stayed in code. The one genuinely subjective question is scoped to a judge that can only affect that question. **4\. Fail open on graders, fail closed on side effects.** A broken judge must not invent bugs. An unannotated tool must not get called. **5\. Make the thing you are measuring observable.** Capping the loop at the budget hid the exact signal I was trying to capture. And the meta-lesson: **a design can be internally correct and still measure the wrong thing.** Deterministic scripted evals were rigorous. They were rigorously grading my planner's guesses. The check evaluators are still in the codebase. They work, they are well tested, and nothing calls them any more. That felt bad for about a day. ## Frequently asked questions **Why not keep both scripted and agentic evals?+** Scripted evals work well when you wrote the server and know what data exists — that is a genuinely good use for them. They stop working when the planner has to guess arguments for a system it cannot see into, which is every server a hosted tool encounters. Keeping both would have meant shipping a mode that produces unanswerable failures. **Does the driver model see the eval expectation?+** No. The driver gets the task and the tools, nothing else. The expectation exists only for the judge to score against afterwards. Showing it to the driver would leak the answer and turn the eval into a formatting exercise. **Why run each eval case on its own connection?+** A legacy stateful server may serialise or misbehave on concurrent calls over a single session, and that would look like a defect in the server rather than in the scheduling. A handshake per case is a cheap price for isolation, and one dead connection then kills one case instead of the whole batch. **How much tool description do you give the planner?+** Up to 4,000 characters, deliberately generous. A good description is the richest source of test material available — Cloudflare's docs tool lists every product it covers, and its search tool ships literal usage examples. Those are exactly the realistic arguments you want, so truncating to a couple of hundred characters throws away the best input you have. ## Where it landed The engine that shipped is smaller than the one I designed and it tells you fewer things. Every one of those things is true, which the original could not claim. If you are building an evaluator for systems you did not write: **track provenance, give yourself an untestable outcome, keep models away from verdicts, and be suspicious of any design where you cannot tell your bugs from theirs.** Point it at your own server Connect any MCP server in the browser and see how a real model handles your tools. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [See MCP Evals →](https://mcpplaygroundonline.com/mcp-evals) Related: [what an MCP eval is](/blog/what-is-an-mcp-eval) · [why 97% of tool descriptions are broken](/blog/mcp-tool-description-quality) · [what the Model Context Protocol is](/blog/what-is-model-context-protocol) · [building on the 2026-07-28 spec](/blog/build-mcp-server-2026-spec) · [every error code change in the 2026 spec](/blog/mcp-error-32602) ## Frequently asked questions ### Why did you replace deterministic scripted MCP evals with agentic ones? Scripting concrete calls meant the planner had to guess arguments for a server whose semantics it cannot see. A guessed argument produces a JSON-RPC -32602 that is indistinguishable from a real server defect, so failures became unanswerable. An agent picks its own arguments with the real schema in front of it and adapts when a call fails, which generalises to servers nobody anticipated. ### What is a harvest pass in an MCP eval engine? It collects real argument values from the server by calling read-only tools before any parameterised call is planned, recording which call produced each value and where it sat in the response. That provenance is what lets a failure on a harvested value be reported as a confirmed defect, while the same failure on an invented value is reported as untestable. ### Should an LLM judge fail open or fail closed? Fail open. If the judge errors or returns no verdict for an item, that item should stay passing, because the deterministic layer already passed it. Failing closed means a rate limit on your judge provider turns into a page of red rows and someone chases bugs that do not exist. ### Why does Anthropic reject Zod numeric constraints in structured output? The structured-output validator rejects numeric range keywords on integers — exclusiveMinimum, then minimum, and by extension maximum. Using .positive(), .min() or .max() makes the request fail before the model runs. Enforce bounds in code after generation instead, which also lets you clamp one bad field rather than losing the whole response. ### Why does z.record() produce empty arguments with structured outputs? An open record compiles to an object schema with no declared properties, and structured output cannot invent keys for such a schema. The model has no way to express a key-value pair, so it silently returns an empty object. Use a list of explicit {name, json, source} entries instead, where json carries the JSON encoding of the value. ### Why must an eval agent be allowed to exceed its call budget? Capping the loop at exactly the budget makes every over-budget run look like a failure to answer, which is a different and much less useful finding. Setting the hard ceiling above the budget makes going over observable, so you learn the agent needed seven calls instead of four. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-eval-engine-design — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # What Is an MCP Eval? Why Your Server Passes Every Test and Still Fails > An MCP test tells you the protocol works. An MCP eval tells you the server is usable. The difference shows up in the failure nobody catches: every tool call succeeds and the answer is still wrong. Here is what an eval is, what the four outcomes mean, and why the results are not deterministic. **Source:** https://mcpplaygroundonline.com/blog/what-is-an-mcp-eval **Author:** Nikhil Tiwari **Published:** 2026-08-14 **Updated:** 2026-08-14 **Category:** Testing **Reading time:** 11 min read --- TL;DR - **An MCP eval is a realistic task a model must complete using only your server's tools** — not an assertion about one call. - **A test asks "did the call work?". An eval asks "could an agent get the right answer?"** - **The signature failure is an answer that is wrong even though every call returned 200.** No inspector catches it. - **There are four useful outcomes**: pass, wrong answer, too many calls, and untestable. The last one is not a failure. - **Evals are not deterministic**, and pretending otherwise is how you get a number you cannot trust. - **Call count degrades before pass rate does**, which makes it the earlier warning signal. Table of contents - [What an MCP eval actually is](#what) - [MCP eval vs testing vs inspecting](#vs) - [The failure that has no red log line](#failure) - [The four outcomes and what each one means](#outcomes) - [Why "untestable" deserves its own outcome](#untestable) - [Evals are not deterministic — and that is fine](#determinism) - [When you need evals, and when you do not](#when) - [How to run your first one](#start) You built an MCP server. The handshake works, every tool returns valid JSON, your integration tests are green. Then someone connects it to Claude and it is useless. That gap has a name now. **An MCP eval is what closes it.** The distinction is simple once you see it. Your test suite proves the protocol works. It says nothing about whether a model can use what you built. Those are genuinely different questions, and only one of them is the reason your server exists. The [MCP specification](https://modelcontextprotocol.io/) has nothing to say about the second one, and it should not — conformance is not usability. The [2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28/) tightened the protocol considerably and did not change this at all. I have spent the last few months building an eval engine for arbitrary MCP servers. This post covers what an eval is, the four outcomes worth distinguishing, why the results are non-deterministic, and when you should bother. ## What an MCP eval actually is **An MCP eval is a task, phrased the way a user would ask it, that a model has to complete using only your server's tools.** Not an assertion. Not a mocked conversation. A question, and a score for whether the model got there. A test looks like this: ``` assert(callTool("list_issues", { status: "open" }).length > 0) ``` An eval looks like this: ``` Task: "Which open issue in the billing project has been waiting longest, and who is it assigned to?" Budget: 4 tool calls Expectation: names a specific issue and an assignee ``` Nothing in the eval names a tool. **Choosing the tool is the thing being tested.** The model gets your tool list, your descriptions and your schemas, and has to work out the rest. That is exactly what happens in production. ## MCP eval vs testing vs inspecting These three get used interchangeably and they measure different things. Answers Misses **Inspecting** Does the handshake succeed? Do tools list? Everything about usability **Testing** Does this call, with these args, return what I expect? Whether a model would ever make that call **Evaluating** Can an agent reach the right answer from my descriptions? Determinism, exhaustive coverage The key structural point: **when you write a test, you have already made the choice the model has to make.** You picked the tool. You picked the arguments. You skipped the only step that can fail in the way that matters. All three are worth having. [Testing catches protocol and correctness bugs](/blog/how-to-test-mcp-servers-step-by-step), and it is faster and cheaper than an eval. Evals catch a class of defect testing structurally cannot reach. ## The failure that has no red log line Here is the scenario that made me build this. A docs server exposes `search` and `get_page`. A user asks which regions a product supports. The agent calls `search("regions")`. It gets back five ranked results. It calls `get_page` on the first one. That page mentions two regions in an example snippet. The agent answers: "It supports us-east and eu-west." **Every call succeeded.** Valid JSON, no errors, no timeouts. Your logs are clean and your dashboard is green. The real answer was eleven regions, listed on a page the search ranked fourth. This is the defect evals exist to find A wrong answer produced entirely from successful calls. There is no error to catch, no exception to log, no status code to alert on. **The only way to detect it is to check the answer.** Nothing in your stack is lying. The protocol worked perfectly. The server was just hard to use, and the model did what it could. ## The four outcomes and what each one means A binary pass/fail throws away most of the signal. Four outcomes are worth distinguishing. ### Pass The agent answered, stayed within its call budget, and the answer was correct. **This is the only outcome that requires judging content**, which means it is the only one a model decides. ### Wrong answer The agent produced an answer and it was not right. Either it could not find the information, or your tools gave it something misleading. This is the outcome from the scenario above, and it is the most valuable one an eval produces. ### Too many calls The agent got there, but it took eight calls when the budget was four. **This is the tool-description signal**, and it is the one to watch over time. The agent was guessing. It tried a tool, got something unhelpful, tried another. Every one of those calls cost you latency, tokens and — if your API is metered — money. Call count degrades before pass rate does. A task that passed in two calls last month and passes in six today is a regression, even though the number in the pass column did not move. I covered the root cause of this in [why 97% of MCP tool descriptions are broken](/blog/mcp-tool-description-quality). ### Untestable Something outside your server broke. The connection dropped, the driver model rate-limited, the harness fell over. **This is not a failure and it must never be counted as one.** It gets its own bucket for a reason I will come to. See a finished eval run Tools detected, tasks written against them, a model made to complete each one, and a report showing where it went wrong. No sign-up. [Walk through MCP Evals →](https://mcpplaygroundonline.com/mcp-evals) ## Why "untestable" deserves its own outcome This is the design decision I would defend hardest, and it took me a while to get right. **A failure only means something if you know the input was valid.** Say an eval calls `get_issue("PROJ-4821")` and gets a 404. Is that a defect in your server? It depends entirely on where that ID came from. - **If `list_issues` returned it a second earlier**, the ID demonstrably exists and your server cannot fetch it. That is a confirmed defect, with both calls as evidence. - **If a model invented it**, a 404 proves nothing. The issue probably just does not exist. Same error code, opposite meaning. **The only thing that separates them is provenance.** This is why a serious eval engine harvests real values from your server before planning anything that needs them. Failures on harvested values are defects. Failures on invented values are untestable. Collapsing those two into "fail" gives you a report full of noise that developers correctly learn to ignore. ## Evals are not deterministic — and that is fine Models write the tasks. A model drives the tools. A model grades the answer. **Run the same suite twice and you can get different numbers.** People find this disqualifying. I think that reaction comes from expecting an eval to be a test, which it is not. The research benchmarks live with the same constraint. [MCP-Atlas](https://arxiv.org/abs/2602.00933) grades 1,000 tasks across 36 real servers using a rubric-driven judge, and [MCP-Bench](https://openreview.net/forum?id=fe8mzHwMxN) pairs rule-based checks with LLM scoring for exactly this reason. **Nobody has found a way to make this deterministic**, because the thing being measured is not. An eval is _evidence about how an agent behaves against your server_. It is not a pass/fail certificate, and any tool that presents it as one is overselling. Two rules make non-determinism workable: **Reproduce before you act.** A single failure is a lead, not a finding. Run it again. A defect that reproduces is real; one that does not is variance. **Read the transcript, not the score.** The number tells you where to look. The transcript — which tools were called, with what arguments, what came back — tells you whether the verdict was fair. There is a third rule I only arrived at by getting it wrong: **the grader must fail open.** If the judge model errors out or returns nothing for an item, that item stays passing. A missing verdict is not evidence of a defect. Failing closed would let an unrelated API hiccup invent bugs in your server. ## When you need evals, and when you do not Evals cost model calls. They are slower and pricier than tests. Some servers do not need them. Worth it - More than about 8 tools - Two or more tools that do similar things - You are about to rewrite descriptions - You ship to users you cannot observe - You support multiple client models Probably not yet - Two or three unambiguous tools - Internal server, one known caller - Still fixing protocol-level bugs - No tool annotations declared yet That last one matters more than it looks. **Fix your annotations before you run evals**, or safe tooling will skip most of your tools. The [spec repository](https://github.com/modelcontextprotocol/modelcontextprotocol) documents all three hints, and they take minutes to add. An eval calls tools with arguments designed to succeed. An unannotated `delete_record` would really delete a record, so anything responsible has to treat unannotated tools as destructive. ## How to run your first one Start smaller than you think. **Pick your three most-used tools.** Write three tasks a real user would ask, in their words, with no tool names in them. Connect a model to your server and give it each task. [Any of the models available in the browser](/blog/testing-mcp-servers-with-real-ai-models) will do for a first pass — you do not need a harness to learn something. Watch three things: did it answer, was the answer right, and how many calls did it take. You will almost always find one of two things. A tool the model never reaches for, or a pair it keeps confusing. Both are description problems, and both are fixable in an afternoon. Once that loop is useful, make it repeatable so a description change gets checked instead of hoped about. ## Frequently asked questions **What is an MCP eval?+** An MCP eval is a task a model has to complete using only your MCP server's tools. Rather than checking that a tool returns HTTP 200, it checks whether an agent can work out which tool to call from your names and descriptions, and whether the answer it produces is correct. **How is this different from testing with an MCP client?+** A client tells you the protocol works — the handshake succeeds, the schema validates, the call returns. An eval tells you the server is usable: that a model given your tools can reach the right answer without burning calls guessing. The most common failure it finds is an answer that is wrong even though every call succeeded. **Are MCP eval results deterministic?+** No. Models write, drive and grade the evals, so the same suite can come out differently on a second run. Results are evidence about how an agent behaves against your server, not a fixed pass/fail certificate. Reproduce a failure before acting on it, and read the transcript rather than the score. **Do evals replace my MCP test suite?+** No. Tests are faster, cheaper and deterministic, and they catch protocol and correctness bugs an eval would waste money rediscovering. Evals catch a different class of defect that tests structurally cannot reach. Run both. ## The short version A test proves your server responds. **An eval proves it can be used.** The gap between those is where the expensive failures live — wrong answers assembled from successful calls, and agents burning four extra calls because two of your tools read alike. Start with three tasks and three tools. Watch the call count as closely as the pass rate. Reproduce before you act. Try it on a real server Connect any MCP server in the browser and give a real model a task. No install, no config file. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [See MCP Evals →](https://mcpplaygroundonline.com/mcp-evals) Related: [what the Model Context Protocol is](/blog/what-is-model-context-protocol) · [how MCP agents drive tools](/blog/what-is-mcp-agent-tool-calling) · [which model is best at MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling) · [testing an AI agent without burning tokens](/blog/how-to-test-ai-agent-with-mcp) ## Frequently asked questions ### What is an MCP eval? An MCP eval is a task a model has to complete using only your MCP server's tools. Rather than checking that a tool returns HTTP 200, it checks whether an agent can work out which tool to call from your names and descriptions, and whether the answer it produces is correct. ### How is an MCP eval different from testing with an MCP client? A client tells you the protocol works — the handshake succeeds, the schema validates, the call returns. An eval tells you the server is usable: that a model given your tools can reach the right answer without burning calls guessing. The most common failure it finds is an answer that is wrong even though every call succeeded. ### Are MCP eval results deterministic? No. Models write, drive and grade the evals, so the same suite can come out differently on a second run. Results are evidence about how an agent behaves against your server, not a fixed pass/fail certificate. Reproduce a failure before acting on it, and read the transcript rather than the score. ### Do MCP evals replace my test suite? No. Tests are faster, cheaper and deterministic, and they catch protocol and correctness bugs an eval would waste money rediscovering. Evals catch a different class of defect that tests structurally cannot reach. Run both. ### What does an untestable eval outcome mean? It means something outside your server broke — the connection dropped, the driver model rate-limited, or the harness failed. It is not a failure and must not be counted as one. Separating untestable from failed is what keeps an eval report free of noise developers learn to ignore. ### Which eval outcome should I watch most closely over time? Call count. A task that passed in two calls last month and passes in six today is a regression even though the pass column did not move. Call count degrades before pass rate does, which makes it the earliest signal that tool descriptions have drifted. --- _Canonical page: https://mcpplaygroundonline.com/blog/what-is-an-mcp-eval — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # 97% of MCP Tool Descriptions Are Broken — How to Test Yours > A peer-reviewed study of 856 tools across 103 MCP servers found that 97.1% of tool descriptions carry at least one defect. Here is what the research actually says, why the obvious fix backfires 1 time in 6, and how to find out whether an agent can use your server. **Source:** https://mcpplaygroundonline.com/blog/mcp-tool-description-quality **Author:** Nikhil Tiwari **Published:** 2026-08-13 **Updated:** 2026-08-13 **Category:** Development **Reading time:** 12 min read --- TL;DR - **97.1% of MCP tool descriptions carry at least one defect**, across 856 tools on 103 servers (arXiv 2602.14878). - **56% never clearly state what the tool does.** The description is the only thing the model reads before choosing. - **Rewriting descriptions helps — by a median of 5.85 percentage points** on task success, not the transformation the headline implies. - **It also costs you.** The same study measured a 67.46% increase in execution steps and a regression in 16.67% of cases. - **You cannot catch a bad description with a normal MCP test.** Every call returns 200 whether the model chose well or not. - **The only way to measure it is to make a model choose** between your tools and score whether it got there. Table of contents - [What the research actually found](#research) - [The six ways an MCP tool description fails](#smells) - [The uncomfortable part: fixing descriptions has a cost](#cost) - [Three real descriptions, rewritten](#rewrites) - [Why your test suite cannot see this](#invisible) - [The annotations problem nobody talks about](#annotations) - [How to actually measure description quality](#measure) - [The checklist](#checklist) Your MCP server works. Every tool returns valid JSON, the schemas validate, the handshake succeeds. And the agent still picks the wrong tool. When that happens, the instinct is to blame the model. **The model is rarely the problem.** The problem is usually the one artefact you wrote by hand and never tested: the _tool description_. A model does not see your code. It sees a name, a description, and a JSON Schema. That is the entire basis on which it decides whether to call your tool. The [MCP specification](https://modelcontextprotocol.io/) is deliberately quiet on description quality — it defines the wire format, not the prose. That leaves the highest-impact field in your server completely unguarded. In February 2026 a team from Queen's University and Huawei published an empirical study of **MCP tool description quality** across the public ecosystem. The numbers are worse than most people assume, and the fix is more complicated than the headline suggests. This post covers what the study found, the six defect classes it identified, why naively expanding your descriptions can make things worse, and how to get a real measurement instead of a guess. ## What the research actually found The paper is [Model Context Protocol (MCP) Tool Descriptions Are Smelly!](https://arxiv.org/abs/2602.14878) by Mohammed Mehedi Hasan, Hao Li, Gopi Krishnan Rajbahadur, Bram Adams and Ahmed E. Hassan. First submitted 16 February 2026, revised 31 May. **They examined 856 tools spread across 103 MCP servers** and assessed each description against a defect taxonomy borrowed from code-smell research. The headline result: Finding Figure Descriptions with at least one smell **97.1%** Fail to clearly state their purpose **56%** Task success gain from augmented descriptions +5.85pp (median) Partial goal completion gain +15.12% Increase in execution steps **+67.46%** Cases where performance regressed **16.67%** Read the bottom three rows again. **That is the part almost every summary of this paper leaves out**, and it changes what you should do about it. ## The six ways an MCP tool description fails Glama built a [Tool Definition Quality Score](https://glama.ai/blog/2026-04-03-tool-definition-quality-score-tdqs) on top of this research, scoring each tool 1–5 across six dimensions. They map cleanly onto the defect classes. ### 1\. Purpose clarity The description does not say what the tool does. **This is the 56% case** — the single most common defect in the ecosystem. A description like `Panel runner` is a noun phrase. It names a component in your architecture, not an action a user wants. ### 2\. Usage guidelines **89% of descriptions never say when you should or should not use the tool.** This is what causes tool confusion on servers with overlapping capabilities. If you ship `search_docs` and `get_page`, and neither says which to reach for first, the model guesses. Sometimes it guesses wrong. ### 3\. Behavioural transparency Does the tool mutate anything? Is it idempotent? Does it hit a rate limit? **A model that does not know a call is destructive will treat it like a read.** ### 4\. Parameter semantics The tool description is fine, but the parameter descriptions are empty. So the model knows to call `get_issue` and has no idea what format `issueId` takes. This is the defect that produces [JSON-RPC -32602 invalid params errors](/blog/mcp-error-32602) at runtime. ### 5\. Conciseness **Longer is not better.** Every character of every description sits in the context window on every single turn, for every tool you expose. A 60-tool server with 400-word descriptions burns real budget before the user has typed anything. I wrote about this in [how MCP tools silently eat your context window](/blog/mcp-token-counter-optimize-context-window). ### 6\. Contextual completeness The description assumes knowledge the model does not have. Internal entity names, project-specific jargon, an ID scheme documented only in your wiki. ## The uncomfortable part: fixing descriptions has a cost Here is where most write-ups of this study go wrong. They quote 97%, quote the success gain, and conclude: write longer descriptions. The paper does not support that conclusion. **Augmenting descriptions raised execution steps by 67.46%** — the agent did more work to get to the answer. And in **16.67% of cases the augmented description made performance worse.** One time in six, the rewrite was a regression. The real finding Description quality genuinely matters, and you cannot fix it by writing more. The study's own ablations found that **compact variants preserved the reliability gain while cutting the token overhead**. Specific beats long. So the actionable version is not "expand everything". It is: **say the right things, cut the rest, and measure whether it worked.** That last clause is the one people skip. A 1-in-6 regression rate means you cannot assume your rewrite helped. ## Three real descriptions, rewritten These patterns come from tools I have pointed evals at. The names are changed; the shapes are exactly what shows up in the wild. ### Scenario 1: the noun phrase Before ``` { "name": "panel_runner", "description": "Panel runner." } ``` **What goes wrong:** the model has no verb to match against the user's request. Asked to "survey our target customers", it never connects that to `panel_runner`. After ``` { "name": "run_research_panel", "description": "Run a customer research panel against a target audience and return per-question response breakdowns. Use for new survey questions. To re-read a panel that already ran, use get_panel_results instead." } ``` **Lead with the verb the user would use.** Then name the sibling tool it gets confused with. ### Scenario 2: the overlapping pair A docs server ships `search` and `fetch_page`. Both descriptions are accurate. Neither mentions the other. The observable symptom: the agent calls `search`, gets a list of URLs, calls `fetch_page` on the first one, does not find the answer, and calls `search` again with a slightly different query. **It gets there eventually.** It burns four calls doing what should take two. On a metered API, that is your bill. The fix is one clause in each description: _"Returns ranked page URLs and snippets — call fetch\_page on a result to read the full page."_ ### Scenario 3: the undocumented ID format Before ``` { "name": "get_issue", "description": "Get an issue.", "inputSchema": { "type": "object", "properties": { "issueId": { "type": "string" } }, "required": ["issueId"] } } ``` The model has to invent an ID format. It tries `"1234"`. Your server wants `"PROJ-1234"`. You get a -32602 or an empty result. **Add one line to the parameter and the failure disappears:** `"issueId": { "type": "string", "description": "Issue key in PROJ-123 form, as returned by list_issues." }` That final clause — _as returned by list\_issues_ — tells the model where to get a valid value. It is the highest-leverage sentence you can write. See how a model reads your tools Connect any MCP server and watch a real model choose between your tools — no install, no sign-up. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) ## Why your test suite cannot see this This is the core of the problem. **A description defect is invisible to every form of testing that calls tools directly.** Run your server through an inspector and every tool returns 200. Run your integration tests and they pass. Validate against the [2026-07-28 spec](/blog/build-mcp-server-2026-spec) and you are conformant. None of that touches the question that matters: _given these descriptions, does a model pick the right tool?_ The reason is structural. **When you call a tool yourself, you have already made the choice the model has to make.** You skipped the only step that can fail. The failure mode this produces is the nastiest one in MCP: **every call succeeds and the final answer is still wrong.** Nothing in your logs is red. ## The annotations problem nobody talks about The [MCP spec](https://modelcontextprotocol.io/) lets a server declare `readOnlyHint`, `idempotentHint` and `destructiveHint` on each tool. These are part of how a model reasons about safety, and the [2026-07-28 spec release](https://blog.modelcontextprotocol.io/posts/2026-07-28/) leaned further into annotations as a risk vocabulary. **Most servers in the wild declare none of them.** That is a description defect with real consequences, and it is one you can fix in an afternoon. It matters more than it looks. When I built the eval engine behind [MCP Evals](/mcp-evals), missing annotations forced a hard design decision. A functional eval calls tools with arguments _designed to succeed_. That is the whole point of it. So pointing one at an unannotated `delete_record` would really delete a record. **The only safe posture is fail-closed:** an unannotated tool gets treated as destructive and excluded from a default run. What this costs you If your server ships no annotations, every automated tool that respects safety has to skip your tools — and so does any cautious agent framework. **Three booleans per tool buys you back that coverage.** Note that "unknown" and "destructive" are not the same situation, even though both get excluded. An unannotated tool may well be read-only. You just cannot prove it, and guessing is not good enough when the call is designed to work. ## How to actually measure description quality Given a 1-in-6 regression rate, you need a measurement, not an opinion. There are three practical levels. ### Level 1: read them against the six dimensions Cheap and genuinely useful. Score each tool 1–5 on purpose clarity, usage guidelines, behavioural transparency, parameter semantics, conciseness and contextual completeness. **Anything scoring 1 or 2 on purpose clarity is a certain problem.** Fix those first. ### Level 2: make a model choose, once Connect your server to a real model, ask a question a user would actually ask, and watch which tool it reaches for. This is the fastest way to find a confused pair. You can do this in a browser with [any of the models on MCP Playground](/blog/testing-mcp-servers-with-real-ai-models) without writing a harness. ### Level 3: run it as an eval suite The difference between level 2 and level 3 is repeatability. **An eval is a task plus a scored outcome, run the same way every time your descriptions change.** This is what the academic benchmarks measure at ecosystem scale. [MCP-Atlas](https://arxiv.org/abs/2602.00933) runs 1,000 human-authored tasks across 36 real servers and 220 tools, with a [public leaderboard](https://labs.scale.com/leaderboard/mcp_atlas). [MCP-Bench](https://openreview.net/forum?id=fe8mzHwMxN) exposes 250 tools across 28 servers to test cross-server orchestration. Those tell you how good a _model_ is. You want the same method pointed at your _server_. The signal to watch is not just pass or fail. It is _how many calls the model needed_. A task that passes in two calls and later passes in five did not stay the same. **Call count is your description-quality metric**, and it moves before pass rate does. That is why the eval engine I built fixes the call budget at generation time. If the budget moved per run, the comparison would be meaningless. ## The checklist - **Lead with a verb** the user would use, not a noun from your architecture. - **Say when not to use it** and name the sibling tool instead. This is the 89% gap. - **Describe every parameter**, and say which tool produces valid values for it. - **Declare your annotations.** All three booleans, on every tool. - **Cut anything the model does not need.** Compact variants performed as well as long ones. - **Re-measure after every rewrite.** One in six makes things worse. - **Track call count, not just pass rate.** It degrades first. ## Frequently asked questions **Does the 97% figure mean my server is probably broken?+** It means your descriptions almost certainly carry at least one defect from the taxonomy, which is not the same as being broken. Many defects are harmless in servers with few tools and no overlap. The risk rises sharply with tool count and with tools that do similar things. **Should I just make every description longer?+** No. The same study that found the 97% figure also measured a 67.46% increase in execution steps and a regression in 16.67% of cases after augmentation. Its ablations found compact variants held the reliability gain at lower token cost. Be specific rather than long. **Can an MCP inspector detect a bad tool description?+** Not really. An inspector calls tools directly, which means you have already made the choice the model would have to make. It can tell you a description field is empty, but it cannot tell you whether the wording leads a model to the right tool. **What is the single highest-leverage fix?+** Adding a clause to each ID-shaped parameter saying which tool returns valid values, for example "as returned by list\_issues". It removes the guessing that produces most -32602 errors, and it costs one sentence. ## Where this leaves you The 97% number is real, peer-reviewed and worth taking seriously. **The naive response to it is not.** Description quality is a measurable property of your server, it degrades quietly, and the only instrument that reads it is a model being made to choose. Call count tells you before pass rate does. Score your tools against the six dimensions, declare your annotations, add the "as returned by" clause, then check that the rewrite actually helped. Find out if an agent can use your server Walk through a finished MCP eval run — tools detected, tasks written, a model made to complete each one. [See MCP Evals →](https://mcpplaygroundonline.com/mcp-evals) [Test a server free →](https://mcpplaygroundonline.com/mcp-test-server) New to the protocol? Start with [what the Model Context Protocol actually is](/blog/what-is-model-context-protocol), then [how to test an MCP server step by step](/blog/how-to-test-mcp-servers-step-by-step). ## Frequently asked questions ### Does the 97% figure mean my MCP server is probably broken? It means your descriptions almost certainly carry at least one defect from the taxonomy, which is not the same as being broken. Many defects are harmless on servers with few tools and no overlap. The risk rises sharply with tool count and with tools that do similar things. ### Should I just make every MCP tool description longer? No. The same study that produced the 97% figure also measured a 67.46% increase in execution steps and a regression in 16.67% of cases after augmentation. Its own ablations found that compact variants preserved the reliability gain at far lower token cost. Be specific rather than long. ### Can an MCP inspector detect a bad tool description? Not really. An inspector calls tools directly, which means you have already made the choice the model would have to make. It can tell you a description field is empty, but it cannot tell you whether the wording leads a model to the right tool. ### What is the single highest-leverage tool description fix? Adding a clause to each ID-shaped parameter saying which tool returns valid values, for example "as returned by list_issues". It removes the guessing that produces most JSON-RPC -32602 invalid params errors, and it costs one sentence. ### Why do missing tool annotations matter for MCP evals? A functional eval calls tools with arguments designed to succeed, so an unannotated destructive tool would really run. Safe tooling has to treat an unannotated tool as destructive and skip it. Declaring readOnlyHint, idempotentHint and destructiveHint buys back that test coverage. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-tool-description-quality — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Meta Muse Spark 1.2 and Muse Glimmer 30B for MCP: Strengths, Benchmarks and Trade-offs > Meta shipped a teacher and its student: Muse Spark, which tops Scale AI's MCP-Atlas leaderboard at 88.1% with a 1M-token context, and Muse Glimmer 30B, an Apache 2.0 open model distilled from it that runs on one consumer GPU. Here is what each is genuinely good at, and where the published record runs out. **Source:** https://mcpplaygroundonline.com/blog/test-mcp-server-with-meta-muse-models **Author:** Nikhil Tiwari **Published:** 2026-08-11 **Updated:** 2026-08-11 **Category:** Comparison **Reading time:** 11 min read --- TL;DR - **Muse Spark 1.1 ranks first on Scale AI's independent MCP-Atlas leaderboard** at 88.1%, ahead of Claude Opus 5 at 85.8% and Claude Fable 5 at 83.3%. - **Meta reports 75.5 on MCP-Atlas for Muse Glimmer 30B** against 62.5 for Qwen3.6-27B and 54.2 for Gemma4-31B — a vendor figure; Glimmer is not on the public leaderboard yet. - **Glimmer is Apache 2.0 and runs locally.** Roughly 20GB at 4-bit, so it fits a 24GB or 32GB machine. - **Spark 1.2 is closed-weights with a 1,048,576-token context** and parallel function calling — a different product, not a bigger Glimmer. - **Glimmer is distilled from Spark**, which is why the smaller model punches above its size on agentic work. - **Meta has not published the tool-calling wire format** for either model. Through OpenRouter both behave as OpenAI-shaped function callers. Meta released two models within a week of each other in August 2026, and the interesting thing is the relationship between them. Muse Spark 1.2 is a closed, API-only reasoning model with a million-token context window. Muse Glimmer 30B is an Apache 2.0 open-weights model distilled from Spark that runs on a single consumer GPU. One is the teacher, the other is the student, and for anyone building on MCP the student is arguably the more interesting release. This guide covers what each model actually is, what the published benchmarks say about tool calling, and — just as importantly — which questions the public record does not answer yet. ## The benchmark that matters for MCP Most model launches give you MMLU and a coding score, neither of which tells you whether the model will drive your MCP server competently. Both Muse models are unusual in carrying a number on **MCP-Atlas** — a benchmark built by **Scale AI** specifically to measure Model Context Protocol tool use. It is worth knowing what that benchmark actually tests, because it is not simple function calling. MCP-Atlas runs **1,000 tasks across 36 real MCP servers and 220 tools**, at three to six tool calls per task. Models have to discover the right tool from a limited set, call it with correct parameters, handle errors, coordinate across servers, and synthesise the results into an answer. That is a far closer proxy for production agent work than a single-shot function call, and it is the reason these scores are worth more than the usual launch-day table. ### Muse Spark tops the public leaderboard On Scale AI's published leaderboard, **Muse Spark 1.1 ranks first at 88.1%**. The company it keeps is the striking part: Model MCP-Atlas pass rate **Muse Spark 1.1** **88.1%** Claude Opus 5 (xhigh) 85.8% Gemini 3.5 Flash (high) 83.6% Claude Fable 5 83.3% Kimi K3 (max) 82.3% Claude Opus 4.8 (max) 82.2% Two caveats matter, and they are not small. The leaderboard was last updated in **April 2026**, so the ranked entry is **Spark 1.1, not the 1.2 release** this guide covers — and Glimmer, which launched in August, is not on it at all. Read the ranking as strong evidence that the Muse line is genuinely good at MCP work, not as a verified score for the exact build you are calling today. ### What Meta reports for Glimmer Glimmer's numbers come from Meta's own launch materials rather than the independent leaderboard, so treat them as a vendor comparison. The comparison set is at least the honest one: the two open models most people would otherwise run locally. Note the conditions Meta publishes alongside them — **Glimmer at High Reasoning, Gemma4-31B and Qwen3.6-27B in Thinking Mode**. These are all best-effort configurations, not defaults, which is a point we will come back to. Benchmark Muse Glimmer 30B Qwen3.6-27B Gemma4-31B **MCP-Atlas** **75.5** 62.5 54.2 **DeepSearch QA** **74.6** 71.1 61.7 **SWE-Bench Pro** **51.2** 50.2 36.9 **SWE-Bench Verified** 76.0 **77.2** 66.6 **τ²-Banking** **23.5** 16.7 15.1 **GAIA2** **43.3** 40.0 36.4 **TerminalBench 2.1** 51.7 **60.7** 43.4 **OSWorld-Verified** 65.9 **75.6** 58.5 The pattern in that table is the honest part of the picture, and it is sharper than "Glimmer wins." Glimmer's advantage is specifically _protocol-shaped agentic work_: discovering tools, invoking schemas correctly across a long workflow, and recovering when a call fails. On MCP-Atlas the gap over Qwen is 13 points, and on τ²-Banking it is a relative rout. But Qwen3.6-27B beats it on SWE-Bench Verified (77.2 to 76.0), on TerminalBench 2.1 (60.7 to 51.7) and on OSWorld-Verified (75.6 to 65.9) — and those last two are not close. The reading that fits all of it: **Glimmer is tuned for calling tools through a protocol, not for driving a terminal or a desktop**. If your agent's job is "use my MCP server correctly," that is the axis it wins on. If your agent's job is "operate a computer," Qwen is the stronger open model at this size. If your workload is "call my tools in the right order and do not mangle the arguments," that is the tension worth knowing about. For rough calibration: if Meta's 75.5 were directly comparable to Scale's scale, it would land Glimmer around the GLM 5.1 and Claude Opus 4.6 band (75.6% and 76.8%) — remarkable for a 30B model you can run at home. The two measurements may not be strictly comparable, so treat that as a sense of scale rather than a ranking. ## Muse Glimmer 30B, in detail Glimmer is a **dense causal transformer** — not a mixture of experts — at roughly 29.6B parameters, and that total includes a 1.8B ViT-G/14 perception encoder for vision. The published shape is 52 layers, a hidden dimension of 6,656, and SwiGLU feed-forward blocks at 19,968 intermediate width. Two architectural choices stand out for anyone running it: - **Grouped-query attention at a 16:1 ratio** — 32 query heads against 2 key/value heads. That is an aggressive ratio, and it is what keeps the KV cache small enough for long agentic sessions on consumer memory. - **A repeating \[Local, Local, Local, Global\] attention pattern** with a 2,048-token sliding window. Three cheap local layers for every global one, which is again a memory-shaped decision rather than a quality-shaped one. Context is **131,072 tokens by default, extendable to 262,144**. It accepts interleaved text and images through the perception encoder, so screenshots, charts and documents are all in scope. The license is **Apache 2.0**, which is genuinely permissive — this is not a bespoke community license with a user-count clause attached. ### How it was trained, and the one claim worth testing Meta describes three phases: **logit distillation** from Muse Spark during pre-training on comparable data distributions; a mid-training phase on extended-context, agent-focused data with enriched reasoning traces; and post-training that blends supervised fine-tuning with on-policy distillation and reinforcement learning across general, reasoning, coding and agentic domains. Buried in that is the most concrete and most checkable claim Meta makes about tool use: _"when a tool call fails or returns an unexpected result, the model is trained to diagnose the error and retry rather than halt."_ That is unusually falsifiable for launch-day copy, and it is the behaviour that separates a model you can leave running from one that needs a human every time an endpoint hiccups. It is also trivial to test — point the model at a server that deliberately returns errors and watch whether it diagnoses and retries, or gives up and apologises. Do that before you trust it with a long workflow. ### It actually runs on your machine At full precision Glimmer needs more than 55GB. Quantized to about 4-bit it drops under 20GB, which leaves headroom for the KV cache, the perception encoder and speculative decoding inside a 24GB or 32GB budget. Meta reports "minimal to no degradation on agentic tasks" from that compression — worth verifying on your own tools, but a meaningful claim given how much of the appeal rests on it. Meta also ships **DFlash speculative decoding**: a lightweight drafter proposes blocks of tokens and the main model verifies them in parallel, accepting what is right and correcting what is not. Output quality is identical by construction; the measured speedup is 3.1x on an RTX 5090, 1.8x on an M5 Max and 1.5x on an M4 Max. Runtime support at launch covers Ollama, LM Studio, llama.cpp, MLX, ExecuTorch, vLLM and SGLang. For MCP specifically this matters more than it looks: an MCP server plus a local model means tool calls that never leave the machine, which is a real answer for teams whose tools touch data that cannot go to a cloud endpoint. ### The number nobody puts in a headline Meta also publishes safety results, and one row deserves attention from anyone exposing tools to a model. On **Siren AgentDojo**, a prompt-injection benchmark, Glimmer records a **28.4% attack success rate** at 94.2 utility. Gemma4-31B is better at 25.6% (utility 90.8); Qwen3.6-27B is worse at 40.3%. Lower is better, and none of these are comfortable. Roughly one in four injection attempts lands against the best of the three. If your MCP server returns any content that originated outside your control — search results, file contents, third-party API responses — that content reaches the model, and these numbers are the empirical odds that it can steer it. Model choice mitigates the risk; it does not remove it. The controls that matter still live on your side of the boundary. ## Muse Spark 1.2, in detail Spark is a different animal. It is **closed-weights and API-only**, and its headline is a **1,048,576-token context window** with roughly 131,072 tokens of output. It accepts text, images, video, audio and PDF, and returns text. For agent builders the relevant capabilities are **structured output**, **parallel function calling** and **configurable reasoning effort**. Meta describes it as designed for multi-agent workflows in either role — a primary agent that plans and delegates, or a subagent executing in parallel — and it leans on planning, goal conditioning and context compaction to hold direction through long tasks. The workloads it is pitched at are multi-file refactors, extended debugging sessions and whole-repository generation. That is a coding-agent profile, and Meta shipped a coding agent called Muse Code alongside it. ### The cost shape is unusual Spark 1.2 is priced at **$1.25 per million input tokens and $4.25 per million output**. Ordinary chat-sized requests are inexpensive. But a million-token context window is an invitation to send enormous inputs, and a 200,000-token prompt costs $0.25 in input alone before the model writes a word. This is worth internalising if you are budgeting agent runs: with most models, cost tracks roughly with how much work the model does. With a 1M-context model, cost tracks with how much context you _chose to send_, and that is a decision you control at design time. Compaction is a feature for a reason. ## What the public record does not tell you Here is the gap, stated plainly, because a lot of coverage papers over it. **Meta has not published the tool-calling wire format for either model.** The developer pages and the model card both assert reliable tool use and precise schema invocation, but neither specifies the serialization — whether tool calls are emitted as JSON blocks, whether there is a bespoke delimiter scheme, how parallel calls are framed. The vLLM and SGLang examples simply use an OpenAI-compatible API surface. Practically, that means: - Routed through a provider like OpenRouter, both models present as **OpenAI-shaped function callers**, which is the same translation path used by every non-Anthropic model in a typical MCP client. - Claims you may read about how these models handle deeply nested arguments, or how their translation layer differs from other vendors', are **not currently supported by published documentation**. Treat them as untested until you have run your own schemas. This is exactly the sort of thing worth measuring against your own server rather than taking on faith, which is the entire premise of pointing a live client at your endpoint and watching what comes back. ## Documented quirks and gotchas These are from Meta's own materials and the community runtimes, not speculation: - **Reasoning effort is not cosmetic, and the benchmarks prove it.** Glimmer exposes low, medium, high and xhigh, and every number in Meta's comparison table was produced at _High Reasoning_ (with the rival models in Thinking Mode). Meta recommends high or xhigh for agentic and coding work. Evaluate at low effort and you are simply not testing the model those numbers describe. - **Sampling defaults are specific:** temperature 1.0, top\_p 0.95, top\_k 64. Carrying over a temperature 0.2 habit from another model is a real source of "it did worse for me" reports. - **No audio on Glimmer.** Spark takes audio; Glimmer does not. If your pipeline assumes parity between the two, that assumption breaks. - **Video is processed as individual frames** on Glimmer, which is not explicitly optimized for video. - **NVFP4 quantization is not working** — flagged as a work in progress in the community runtime docs at launch. Use a supported quant. - **Quantized inference shows minor quality differences in edge cases**, per the model card. For agentic tool selection, edge cases are the interesting part. - **Language coverage is broad but uneven** — trained across 100+ languages, with degradation outside the strongly-supported set. ## Which one should you point at your MCP server? The choice is unusually clean, because these models are not competing with each other: - **Choose Glimmer** when you want a model you can self-host, when tool calls must stay on your own hardware, or when you are benchmarking whether an open 30B is good enough to replace a frontier model on your specific tools. The MCP-Atlas number says it deserves the audition. - **Choose Spark 1.2** when the task genuinely needs the context — whole-repository work, long debugging sessions, multi-agent orchestration where a planner holds a large working set — or when you want parallel function calling across many tools at once. The distillation relationship is the useful mental model. Glimmer inherits Spark's agentic behaviour in a package you can run locally; Spark keeps the scale, the context and the modalities that will not fit on a laptop. ## Testing this against your own server Benchmarks are aggregate. Your server has specific tool names, specific descriptions and specific argument shapes, and those are what determine whether a model selects the right tool and fills it in correctly. The fastest honest test is to connect the model to your real endpoint and watch the tool calls: which tool it picks, what arguments it constructs, and what it does when a call returns an error. A model that scores well on an agentic benchmark and still fumbles your particular nested schema is a result you want before you ship, not after. You can run both Muse models against your own MCP server in the browser on the [test your MCP server with Meta Muse](/test-mcp-with/meta) page — no local install required, and no Meta account. ## FAQ **Is Muse Glimmer really open source?** The weights are released under Apache 2.0 and hosted on Hugging Face, which is a genuinely permissive license — commercial use, modification and redistribution are all allowed without a user-count threshold or a bespoke acceptable-use addendum. **Can Muse Glimmer run an MCP server locally with no network access?** Yes. Quantized to roughly 4-bit it fits under 20GB and runs through Ollama, LM Studio, llama.cpp, MLX, vLLM and others. Paired with a locally-running MCP server, the entire loop — prompt, tool call, tool result — stays on your hardware. **Is Muse Spark 1.2 open-weights like Glimmer?** No. Spark is closed and available through the API only. Glimmer is the open model, and it is distilled from Spark rather than being a smaller checkpoint of it. **Which Muse model is better at MCP tool calling?** Spark, on the evidence available. Muse Spark 1.1 ranks first on Scale AI's independent MCP-Atlas leaderboard at 88.1%, ahead of Claude Opus 5. Glimmer's 75.5 is Meta's own reported figure and is not on that leaderboard, so the two numbers are not strictly comparable — but nothing in the published record suggests the distilled 30B beats its teacher. Glimmer's case is that it gets close enough to matter while running on your own hardware. **How does Muse Glimmer compare to Qwen3.6-27B and Gemma4-31B?** Glimmer leads clearly on agentic and MCP benchmarks (75.5 vs 62.5 and 54.2 on MCP-Atlas) and modestly on SWE-Bench Pro, but Qwen3.6-27B edges it on SWE-Bench Verified at 77.2 to 76.0. The pattern is that Glimmer is tuned for tool use and long tasks rather than raw single-shot code editing. ## Frequently asked questions ### Is Muse Glimmer really open source? The weights are released under Apache 2.0 and hosted on Hugging Face, which is a genuinely permissive license — commercial use, modification and redistribution are all allowed without a user-count threshold or a bespoke acceptable-use addendum. ### Can Muse Glimmer run an MCP server locally with no network access? Yes. Quantized to roughly 4-bit it fits under 20GB and runs through Ollama, LM Studio, llama.cpp, MLX, vLLM and others. Paired with a locally-running MCP server, the entire loop — prompt, tool call, tool result — stays on your hardware. ### Is Muse Spark 1.2 open-weights like Glimmer? No. Spark is closed and available through the API only. Glimmer is the open model, and it is distilled from Spark rather than being a smaller checkpoint of it. ### Which Muse model is better at MCP tool calling? Spark, on the evidence available. Muse Spark 1.1 ranks first on Scale AI's independent MCP-Atlas leaderboard at 88.1%, ahead of Claude Opus 5. Glimmer's 75.5 is Meta's own reported figure and is not on that leaderboard, so the two numbers are not strictly comparable — but nothing in the published record suggests the distilled 30B beats its teacher. Glimmer's case is that it gets close enough to matter while running on your own hardware. ### How does Muse Glimmer compare to Qwen3.6-27B and Gemma4-31B? Glimmer leads clearly on agentic and MCP benchmarks (75.5 vs 62.5 and 54.2 on MCP-Atlas) and modestly on SWE-Bench Pro, but Qwen3.6-27B edges it on SWE-Bench Verified at 77.2 to 76.0. The pattern is that Glimmer is tuned for tool use and long tasks rather than raw single-shot code editing. --- _Canonical page: https://mcpplaygroundonline.com/blog/test-mcp-server-with-meta-muse-models — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # MCP Error -32602: Every Error Code Change in the 2026-07-28 Spec > Resource not found moved from -32002 to -32602, and the whole JSON-RPC server-error range got repartitioned. If your server uses a custom code in the -32020 to -32099 band, you are now squatting on reserved space. Here is every change, and the fix for client and server authors. **Source:** https://mcpplaygroundonline.com/blog/mcp-error-32602 **Author:** Nikhil Tiwari **Published:** 2026-08-06 **Updated:** 2026-08-06 **Category:** Development **Reading time:** 12 min read --- TL;DR - **Resource not found is now `-32602`**, not `-32002`. Landed in the 2026-07-28 spec via SEP-2164. - **The server-error range was repartitioned.** `-32000`–`-32019` stays implementation-defined; `-32020`–`-32099` is now reserved for the spec. - **Three codes were renumbered:** HeaderMismatch, MissingRequiredClientCapability, and UnsupportedProtocolVersion all moved. - **Clients should accept both `-32602` and `-32002`** during the transition — but gate on the method name. - **Never return an empty `contents` array** for a missing resource. The spec forbids it. I lost most of a Tuesday to **MCP error -32602**. My client worked against a TypeScript server. The same code, pointed at a Go server, silently stopped detecting missing resources. Nothing crashed. No stack trace. **The error just stopped matching my handler.** The cause turned out to be embarrassing. The two servers returned different error codes for an identical condition. That was not a bug in either one. Until the 2026-07-28 spec, the SDKs genuinely disagreed. That revision fixed it — and quietly repartitioned the entire JSON-RPC server-error range while it was in there. **Most migration guides skipped the second part.** If your server defines a custom error code, there is a real chance it is now sitting in reserved space. ## What MCP Error -32602 Actually Means `-32602` is not an MCP invention. **It comes from the JSON-RPC 2.0 specification, where it means "Invalid params."** The method you called exists. The arguments you passed do not satisfy it. In MCP that now covers three distinct situations. - **A tool call whose arguments fail the tool's JSON schema.** Wrong type, missing required field, bad enum value. - **Structured output that does not match the declared output schema.** - **A `resources/read` for a URI that does not exist.** This is the new one. That third case is what trips people up. **A missing resource is now framed as an invalid parameter** — you passed a URI pointing at nothing. It reads oddly at first. It is the correct JSON-RPC framing, and it avoids inventing a custom code. **Retrying a -32602 will always fail.** The parameters are invalid and will still be invalid on attempt two. I have watched a client burn its entire backoff budget re-sending a request that was never going to succeed. ## Why -32002 and -32602 Both Mean "Resource Not Found" Here is the history, because it explains every confusing thing about this error. **The original spec recommended `-32002` for resource-not-found.** That looked reasonable. It was also wrong, for a specific reason. JSON-RPC reserves the `-32000` to `-32099` band for _implementation-defined_ server errors. That range belongs to your application. **It was never meant for protocol-level semantics.** A condition every MCP server can hit is protocol-level by definition. SEP-2164 moved it to `-32602`, and the change shipped in the 2026-07-28 revision. The changelog entry is blunt: _"Change resource not found error code from -32002 to -32602 (Invalid Params) to align with JSON-RPC specification."_ ### Four Codes, One Condition This is the part that cost me a day. **The official SDKs never agreed with each other.** For the exact same condition — reading a resource that does not exist — here is what each SDK sent before the standardization: SDK Error code returned TypeScript `-32602` (InvalidParams) Python `0` (generic) C# `-32002` (custom) Rust `-32002` Java `-32002` Go `-32002` PHP `-32002` Kotlin `-32603` (INTERNAL\_ERROR) Ruby left to the implementor Swift no built-in handler **Four different codes across the eight SDKs that handled it at all.** Five sent `-32002`. One sent `-32602`. One sent `-32603`. One sent `0`. That is why my client "broke" when I switched servers. It never broke. **It was written against one SDK's dialect.** If you have ever thought _"my MCP client works with some servers and not others"_ — this table is very likely your answer. Which dialect does your server speak? Paste a URL, call a resource that doesn't exist, read the raw JSON-RPC error frame. [Test any MCP server free →](/mcp-test-server) ## The Error Code Range Was Repartitioned Too This is the change almost nobody covered, and it is the one most likely to bite a server author. **The 2026-07-28 spec split the JSON-RPC server-error range in two.** - **`-32000` to `-32019`** — still implementation-defined. Existing SDK usage is explicitly grandfathered. - **`-32020` to `-32099`** — now reserved for the MCP specification. If you invented a custom error code anywhere in that upper band, **you are now squatting on space the spec has claimed.** Nothing breaks today. It will collide eventually. Three spec codes were renumbered to fit the new policy: Error Was Now HeaderMismatch `-32001` `-32020` MissingRequiredClientCapability `-32003` `-32021` UnsupportedProtocolVersion `-32004` `-32022` These were introduced during the 2026-07-28 draft cycle, so **you only hit them if you built against a release candidate.** If you did, grep for the old literals. ## How to Fix -32602 as a Client Author The migration guidance is explicit: **treat both `-32602` and `-32002` as resource-not-found during the transition.** Do not pick one. Accept both. ``` const RESOURCE_NOT_FOUND = new Set([ -32602, // canonical, per SEP-2164 -32002, // legacy: C#, Rust, Java, Go, PHP ]); function isResourceNotFound(err, method) { if (method !== 'resources/read') return false; return RESOURCE_NOT_FOUND.has(err.code); } ``` **Notice the method guard. It matters more than the code check.** `-32602` is heavily overloaded — it also means "your tool arguments failed validation." Without gating on `resources/read`, **you will classify schema failures as missing resources.** That is a worse bug than the one you set out to fix. For the two stragglers you need a fallback. - **Kotlin servers sent `-32603`**, which genuinely means internal error. Mapping that to not-found would swallow real crashes. - **Python servers sent `0`**, which means nothing at all. For both, match on the `message` string as best-effort. **Log when you hit that path** so you can delete it once the SDKs catch up. **The silent failure to watch for:** if your client hardcodes `if (err.code === -32002)`, that branch is now dead against any updated server. No exception, no warning — it just stops being taken. ## How to Fix -32602 as a Server Author Your obligation is short. **Return `-32602` when the requested resource does not exist.** The spec language is MUST. ``` { "jsonrpc": "2.0", "id": 2, "error": { "code": -32602, "message": "Resource not found", "data": { "uri": "file:///nonexistent.txt" } } } ``` **Put the missing URI in `data`.** The spec marks this SHOULD, and skipping it is a false economy. A client that gets the URI back can log exactly what failed. One that does not gets "something wasn't found" and no way to act. If you maintain a server on C#, Rust, Java, Go, or PHP, **you were emitting `-32002`** unless you overrode it. Check your SDK version — the fix may arrive on your next bump. ### The Empty Contents Array Trap This one is subtle, and the spec calls it out directly. **Servers MUST NOT return an empty `contents` array for a resource that does not exist.** It looks harmless. Return `{ "contents": [] }` and let the client work it out. The problem is that **the response is ambiguous.** An empty array can mean two different things. - The resource exists and genuinely has no content. - The resource does not exist at all. The client cannot tell them apart. **A "success" response for a missing resource is worse than an error** — it fails silently, and silent failures surface three layers downstream. ## What Else Changed in 2026-07-28 The error codes were a minor entry in a revision that rewrote the transport. If you are debugging after an upgrade, **you probably picked up several of these at once.** - **Sessions are gone.** The `Mcp-Session-Id` header was removed entirely. - **The handshake is gone.** No more `initialize` / `notifications/initialized`. Every request carries its protocol version and capabilities in `_meta`. - **`server/discover` is mandatory.** Servers MUST implement it to advertise supported versions, capabilities, and identity. - **`subscriptions/listen` replaces** the HTTP GET endpoint and `resources/subscribe`. - **`ping`, `logging/setLevel`, and `notifications/roots/list_changed` were removed.** - **All results now require a `resultType` field** — `"complete"` or `"input_required"`. - **MRTR replaces server-initiated requests** like `sampling/createMessage` and `elicitation/create`. - **SSE resumability is gone.** No `Last-Event-ID`; a broken stream means re-issuing the request with a new ID. - **Roots, Sampling, and Logging are deprecated**, as is HTTP+SSE and OAuth Dynamic Client Registration. The stated goal is that _any request can now land on any server instance behind a plain round-robin load balancer._ **Debug these one at a time.** Bump your SDK, verify, then change transport behaviour. Doing both at once is how a one-hour fix becomes a lost Tuesday. Not migrated yet? Start with the [2026-07-28 migration guide](/blog/migrate-mcp-server-2026-07-28-stateless), or read [what changed across the whole 2026 roadmap](/blog/mcp-2026-roadmap-whats-changing-for-developers). Building fresh? Use the [2026 spec server guide](/blog/build-mcp-server-2026-spec). ## MCP Error Code Reference Code Name Meaning in MCP `-32700` Parse error Malformed JSON. Usually a serialization bug. `-32600` Invalid request Valid JSON, invalid JSON-RPC envelope. `-32601` Method not found Method doesn't exist. Check for version drift. **`-32602`** **Invalid params** **Bad arguments — or a resource that doesn't exist.** `-32603` Internal error Server-side crash. Kotlin also sent this for not-found. `-32000`–`-32019` Implementation-defined Yours to use. `-32000` is commonly "connection closed." `-32020`–`-32099` Reserved for MCP Do not use for custom errors. For connection-level failures — `-32000`, timeouts, spawn errors, 406s — I wrote a [separate troubleshooting guide](/blog/mcp-server-troubleshooting-common-errors-fix). Auth failures have [their own guide](/blog/mcp-server-oauth-authentication-guide). New to the protocol? Start with [what the Model Context Protocol actually is](/blog/what-is-model-context-protocol), or see [how MCP differs from a REST API](/blog/mcp-vs-rest-api-whats-different). ## How MCP Playground Helps Reproducing this locally means wiring a client, pointing it at a server, and reading logs. **I built MCP Playground to skip that.** Paste a server URL in the browser, call `resources/read` against a URI you know doesn't exist, and read the raw JSON-RPC error frame — code, message, and `data` payload. That tells you in seconds which dialect a server speaks, **before you write a line of client code against it.** See the real error frame in your browser No install. No signup for the basic test. [Test any MCP server free →](/mcp-test-server) [Scan your MCP server →](/mcp-security-scanner) ## Frequently Asked Questions **What does MCP error -32602 mean?+** It is the JSON-RPC "invalid params" code. The method exists but your arguments are wrong. Since the 2026-07-28 spec it is also the canonical code for a resource that does not exist. **Should I retry on -32602?+** No. The parameters are invalid and will still be invalid on retry. Fix the arguments instead. **Is -32002 deprecated?+** As a recommendation, yes — the 2026-07-28 spec replaced it with -32602. In the wild it is still common, since five official SDKs emitted it. **Should my client handle both -32002 and -32602?+** Yes. Accept both during the transition, and gate on the method name so you do not misclassify tool schema errors as missing resources. **Can I still use custom error codes?+** Only in -32000 to -32019. The -32020 to -32099 band is now reserved for the MCP specification. Existing usage below -32020 is grandfathered. **Can I return an empty contents array instead of an error?+** No. The spec forbids it. An empty array cannot be distinguished from a resource that exists but has no content. ## Wrapping Up **\-32602 is the canonical MCP code for resource-not-found**, and -32002 is the legacy code five official SDKs still emit. Accept both on the client, gated on the method name. Send -32602 with the missing URI in `data` on the server, and never an empty `contents` array. Then check your custom error codes. **If any sit between -32020 and -32099, move them down.** [Test any MCP server free →](/mcp-test-server) — paste a URL, call a missing resource, and see exactly which code comes back. 🧪 Reproduce -32602 on demand The [hosted error mock server](/mock-mcp-servers) returns validation, not\_found, rate\_limit, timeout and five other error types on request, so you can prove your client surfaces each one correctly instead of waiting for production to produce them. Public URL, no auth, no sign-up. ## Frequently asked questions ### What does MCP error -32602 mean? It is the JSON-RPC "invalid params" code, meaning the method exists but the arguments are wrong. Since the 2026-07-28 specification it is also the canonical error code for a resource that does not exist, replacing -32002. ### Should I retry a request that failed with -32602? No. The parameters are invalid and will still be invalid on a retry. Fix the arguments or the resource URI instead of retrying. ### Is the MCP error code -32002 deprecated? Yes, as a recommendation. The 2026-07-28 specification changed resource not found from -32002 to -32602 to align with JSON-RPC. Five of the official SDKs emitted -32002, so it is still common in the wild. ### Should my MCP client handle both -32002 and -32602? Yes. Accept both codes as resource-not-found during the transition period. Gate the check on the resources/read method name, because -32602 also signals tool argument schema failures and you would otherwise misclassify them. ### Can I still define custom MCP error codes? Only in the -32000 to -32019 range. The 2026-07-28 specification reserved -32020 to -32099 for the MCP specification itself. Existing implementation-defined usage below -32020 is grandfathered. ### Can an MCP server return an empty contents array for a missing resource? No. The specification forbids it. An empty array is ambiguous because it cannot be distinguished from a resource that exists but has no content. Return the -32602 error instead. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-error-32602 — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Build an MCP Server on the 2026-07-28 Spec: The Stateless Guide > The 2026-07-28 spec shipped final and MCP is stateless now. If you build a new MCP server on the old handshake, you are starting on a deprecated foundation. Here is the from-scratch build, with real code. **Source:** https://mcpplaygroundonline.com/blog/build-mcp-server-2026-spec **Author:** Nikhil Tiwari **Published:** 2026-07-29 **Category:** Development **Reading time:** 13 min read --- 📖 TL;DR - The **2026-07-28 MCP spec** shipped final on July 28, 2026. New servers should start here, not on 2025-11-25. - **No `initialize` handshake, no `Mcp-Session-Id`.** Every request is self-contained, so your server runs behind a plain load balancer. - Build on the new **`@modelcontextprotocol/server` v2** package. The old `@modelcontextprotocol/sdk` v1 line stays alive alongside it. - `server/discover` is a **MUST**. The SDK answers it for you, and stamps `resultType`, `ttlMs`, and `cacheScope`. - One handler can serve **both spec revisions**, so old clients keep working while you ship on the new one. - Point a real model at it in [MCP Playground](/mcp-test-server) before you deploy. If you **build an MCP server** this week, you have a decision to make on line one. The 2026-07-28 spec shipped final yesterday. It is the biggest revision since [_Model Context Protocol_](/blog/what-is-model-context-protocol) launched. Start on the old 2025-11-25 handshake and you are writing a migration ticket for yourself before your first deploy. Start on the new spec and a lot of the hard parts disappear. **No session store. No sticky routing. No handshake round trip.** I have spent the last week porting our own mock servers onto the v2 SDK. Some of it is genuinely simpler. Some of it has sharp edges nobody has written about yet. This is the from-scratch build guide — real code from a real server, not a hello-world snippet. If you already run a 2025-era server, read my [2026-07-28 migration checklist](/blog/migrate-mcp-server-2026-07-28-stateless) instead. 📑 Table of Contents 1. [What is different in the 2026-07-28 spec](#whats-different) 2. [Pick the right SDK package](#choose-sdk) 3. [Build the server, step by step](#build-server) 4. [Serve both revisions from one endpoint](#dual-era) 5. [Multi Round-Trip Requests](#mrtr) 6. [The new security hole: requestState](#security) 7. [Test before you ship](#testing) 8. [FAQ](#faq) ## What is different when you build an MCP server on the 2026-07-28 spec The old protocol was stateful. A client opened with an `initialize` handshake, got an `Mcp-Session-Id`, then carried it on every later request. That one design choice leaked into your whole deployment. **Sticky routing, a shared session store, and a gateway that had to read request bodies to route them.** The 2026-07-28 revision deletes it. Each request carries the protocol version and client info in `_meta` fields instead. The practical result: **any instance can serve any request.** Round-robin works. Serverless works. Cold starts stop being a session problem. Here is what actually changes on the server you are about to write. The [official changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog) has the exhaustive list. 2025-11-25 (old) 2026-07-28 (new) `initialize` handshake None — version rides in `_meta` Capabilities from the handshake `server/discover` (a MUST) Sampling, Roots, Logging Deprecated — use MRTR and stderr No cache signalling `ttlMs` + `cacheScope` on lists HTTP GET stream `subscriptions/listen` Missing resource is `-32002` Missing resource is `-32602` One more that matters for tool design: **tool schemas now support full [JSON Schema 2020-12](https://json-schema.org/draft/2020-12/release-notes).** You get `oneOf`, `anyOf`, `allOf`, and `$ref`. If you were flattening a complex input into a bag of optional strings to fit the old limits, stop doing that. ## Pick the right SDK package before you write code This trips people up on day one, so get it right first. The v2 SDK did **not** ship as a major bump of the old package. It shipped as **new packages** that live alongside it. - `@modelcontextprotocol/server` v2 — build a 2026-07-28 server. - `@modelcontextprotocol/client` v2 — build a client that speaks both eras. - `@modelcontextprotocol/sdk` v1 — the 2025-era line, still maintained. All three live in the [official TypeScript SDK repo](https://github.com/modelcontextprotocol/typescript-sdk). Python, Go, and C# shipped 2026-07-28 support on launch day too. They coexist in one `package.json`. No fork, no vendoring, no pinning games. That is what makes an incremental rollout possible. **The gotcha nobody warns you about:** the v2 SDK takes Standard Schema validators that expose a `jsonSchema` property. Only [zod 4](https://zod.dev) does. If your repo is still on zod 3, install zod 4 under an alias rather than upgrading everything at once — that is exactly what I did. Install what you need: ``` npm install @modelcontextprotocol/server zod@^4 ``` ## Build the MCP server, step by step I will build a small server with two tools, then wire it to HTTP. Every snippet below is the shape I run in production. ### Step 1: Define the server and its cache hints The server object takes identity in the first argument and capabilities in the second. **Cache hints are new and worth setting.** Without them the SDK emits `ttlMs: 0` and `cacheScope: 'private'` — compliant, but it tells clients nothing. server.ts ``` import { McpServer } from '@modelcontextprotocol/server'; import { z } from 'zod'; export function createServer() { const server = new McpServer( { name: 'my-mcp-server', version: '1.0.0', title: 'My MCP Server', }, { capabilities: { tools: {} }, cacheHints: { 'tools/list': { ttlMs: 60_000, cacheScope: 'public' }, 'server/discover': { ttlMs: 300_000, cacheScope: 'public' }, }, } ); return server; } ``` Pick `cacheScope` carefully. **Use `'public'` only when the response is identical for every caller.** A tool list that varies by tenant must stay `'private'`. Get that wrong and a shared intermediary can serve one customer's tool list to another. I come back to this in the security section. ### Step 2: Register tools with real schemas Tools are registered with a name, a description, an input schema, and a handler. **The description is not documentation — it is the prompt.** It is what the model reads when deciding whether to call your tool. The [official tools concept doc](https://modelcontextprotocol.io/docs/concepts/tools) is worth a skim here. server.ts (continued) ``` server.registerTool( 'echo', { description: 'Echoes back the input message', inputSchema: z.object({ message: z.string().describe('The message to echo back'), }), }, async ({ message }) => ({ content: [{ type: 'text', text: message }], }) ); server.registerTool( 'calculator', { description: 'Performs basic arithmetic operations', inputSchema: z.object({ operation: z .enum(['add', 'subtract', 'multiply', 'divide']) .describe('The arithmetic operation to perform'), a: z.number().describe('First number'), b: z.number().describe('Second number'), }), }, async ({ operation, a, b }) => { if (operation === 'divide' && b === 0) { throw new Error('Division by zero'); } const result = { add: a + b, subtract: a - b, multiply: a * b, divide: a / b }[operation]; return { content: [{ type: 'text', text: 'Result: ' + result }] }; } ); ``` Two habits that pay off later: - **Put `.describe()` on every field.** It lands in the JSON Schema the model sees, and it is the difference between a right argument and a guessed one. - **Keep tool order deterministic.** The spec says SHOULD, and it is what makes client-side caching of `tools/list` actually work. If you want the deeper version of this, I wrote up how models actually choose tools in [MCP agent tool calling](/blog/what-is-mcp-agent-tool-calling). ### Step 3: Serve it over HTTP This is where the stateless design earns its keep. **No transport object to keep alive, no session map.** `createMcpHandler` takes a factory. It builds a fresh server instance per request and hands you the era it classified the request into. route.ts — Next.js App Router ``` import { createMcpHandler } from '@modelcontextprotocol/server'; import { createServer } from './server'; const handler = createMcpHandler(({ era }) => createServer(era), { legacy: 'stateless', onerror: (error) => console.error('[mcp] handler error:', error), }); export async function POST(req: Request) { return handler.fetch(req); } ``` That is the whole server. **It runs on Vercel, Cloudflare Workers, Lambda, or a plain Node box** with no shared state between instances. Notice what you did not write. No `initialize` handler. No `server/discover` handler either — **the SDK answers that from your registered tools.** It also stamps `resultType` on every result and applies your cache hints. Those are MUSTs in the new spec, and you get them free. Deploying somewhere specific? My [MCP server deployment guide](/blog/deploy-mcp-server-vercel-railway-render-heroku-flyio) covers the platform differences, and there is a dedicated [Cloudflare Workers walkthrough](/blog/build-mcp-server-cloudflare-workers-guide). Server running locally? Paste the URL and watch a real AI model call your tools — in the browser, no install. [Test any MCP server free →](/mcp-test-server) ## Serve both spec revisions from one endpoint Here is the reality of shipping in July 2026. **Most clients in the wild still speak 2025-11-25.** You do not have to choose. That `legacy: 'stateless'` option in the handler is doing real work. With it, one endpoint classifies each request and answers correctly. An `initialize` body routes to the legacy leg. A `_meta` version envelope routes to the stateless leg. **One server definition, both eras.** They cannot drift apart because they come from the same factory — that is the pattern the v2 SDK explicitly recommends. You can also pin the behaviour when you want to test rejection paths: - `legacy: 'stateless'` — serve both. The sane default. - `legacy: 'reject'` — 2026-07-28 only. Old handshakes get `-32022 UnsupportedProtocolVersion`. Pinning to reject is useful in CI. It proves your server is genuinely compliant rather than quietly leaning on the fallback. ## Multi Round-Trip Requests: what replaced sampling and elicitation The old spec let your server call back into the client. Sampling asked the client to run the model. Elicitation asked the user a question. Roots asked for the workspace. **All of that is deprecated**, because a stateless server has no open channel to call back on. The replacement is _Multi Round-Trip Requests_, or MRTR. It inverts the flow, and it is simpler than it sounds. Your handler returns an `inputRequired` result instead of a normal one. The client gathers answers, then **re-issues the original request** with the answers attached. A confirm-before-acting tool ``` import { inputRequired, acceptedContent } from '@modelcontextprotocol/server'; server.registerTool( 'deploy', { description: 'Deploys the app. Asks for confirmation first.', inputSchema: z.object({ target: z.string() }), }, async ({ target }, ctx) => { const answer = acceptedContent(ctx.mcpReq.inputResponses, 'confirm'); if (!answer) { return inputRequired({ inputRequests: { confirm: { message: 'Deploy to ' + target + '?', schema: z.object({ confirm: z.boolean() }), }, }, }); } return { content: [{ type: 'text', text: 'Deployed to ' + target }] }; } ); ``` The same handler works on both eras. **On a 2025-era connection the SDK's legacy shim turns it into a real server-to-client request**, so you write it once. This is the pattern to reach for on any **write-heavy tool** — deploys, deletes, payments. Confirmation belongs in the protocol, not in a description string begging the model to ask first. ## The new security hole: unsigned requestState MRTR introduces a genuinely new attack surface, and almost nobody is handling it yet. When your handler returns `inputRequired`, it can attach a `requestState` blob to remember what it was doing. That blob **round-trips through the client**. Think about what that means. It comes back as **attacker-controlled input**. If it carries a user ID, a target environment, or an authorization decision, it is tamperable. The SDK does not sign it for you. You have to opt in. Seal requestState with an HMAC ``` import { createRequestStateCodec } from '@modelcontextprotocol/server'; const stateCodec = createRequestStateCodec({ key: process.env.MCP_REQUEST_STATE_KEY, ttlSeconds: 300, }); ``` **Use a shared secret from the environment, not a per-process random key.** A random key only works while one instance serves every round of a flow — which defeats the point of going stateless. Two more checks worth running before launch: - **`cacheScope: 'public'` on tenant-scoped data.** This leaks one user's data to another through shared caches. Audit every hint you set. - **Missing `iss` validation in auth.** [RFC 9207](https://datatracker.ietf.org/doc/html/rfc9207) validation is now required, not optional. See my [MCP OAuth guide](/blog/mcp-server-oauth-authentication-guide). **Do not ship an MCP server without scanning it.** Tool poisoning, prompt injection through tool descriptions, and unsigned `requestState` are all invisible in a normal test run. [Scan your MCP server →](/mcp-security-scanner) The full threat model is in my [MCP server security guide](/blog/mcp-server-security-complete-guide-2026). ## Test your MCP server before you ship it A server that returns valid JSON is not a server that works. The failure I see most often is not a protocol error. It is **a model that reads your tool description and picks the wrong tool** — or the right tool with the wrong arguments. That bug is invisible to curl. It only shows up when a real model is driving. My pre-ship checklist: 1. Confirm `server/discover` answers and lists every tool you registered. 2. Check `resultType`, `ttlMs`, and `cacheScope` appear on list results. 3. Pin a client to `2026-07-28` and confirm nothing depends on the fallback. 4. Pin to the legacy era and confirm old clients still work. 5. Run a plain-English prompt through a real model and watch which tool it picks. 6. Break something on purpose — bad arguments, a thrown error — and check the model recovers. Step five is the one people skip, and it is the one that catches the expensive bugs. There is a longer walkthrough in [how to test MCP servers step by step](/blog/how-to-test-mcp-servers-step-by-step). ## How MCP Playground can help [MCP Playground](/mcp-test-server) connects your server to a live AI model in the browser, with no local install. It speaks both spec revisions, shows you the negotiated one, and lets you force either. You see every tool list, every call with its arguments, and every error — so you find the wrong-tool bug before your users do. ## Frequently Asked Questions **Should I build a new MCP server on the 2026-07-28 spec?** Yes. It shipped final on July 28, 2026, and one handler serves old clients too, so there is no compatibility reason to start on the old revision. **Which package do I install?** `@modelcontextprotocol/server` v2. The v1 `@modelcontextprotocol/sdk` package is a separate line and can sit in the same project. **Do I have to implement `server/discover` myself?** No. It is a MUST in the spec, but the v2 SDK answers it from your registered tools, prompts, and resources. **What replaced sampling and elicitation?** Multi Round-Trip Requests. Your handler returns `inputRequired`, the client collects the answers, and it re-issues the original request. ## Conclusion **Building on the 2026-07-28 spec is less work than building on the old one.** No session store, no sticky routing, and `server/discover`, `resultType`, and cache hints come from the SDK. The two things you own are cache scope and a signed `requestState`. Get those right and the rest is tool design. Then prove it works against a real model. [Test any MCP server free](/mcp-test-server) before you deploy. 🧪 A reference implementation you can call right now Before you write your own, poke a working one: [the hosted stateless mock server](/mock-mcp-servers) implements Multi Round-Trip Requests and signed `requestState` against the 2026-07-28 revision at a public URL, alongside five other mocks for echo, auth, errors, complex schemas, and MCP Apps. ## Frequently asked questions ### Should I build a new MCP server on the 2026-07-28 spec? Yes. The 2026-07-28 specification shipped final on July 28, 2026, and it is the current revision. A single handler can serve both the stateless 2026-07-28 era and the older 2025-11-25 handshake, so there is no backward-compatibility reason to start a new server on the old revision. ### Which SDK package do I use to build a 2026-07-28 MCP server? Install @modelcontextprotocol/server version 2. The v2 SDK shipped as new packages rather than a major bump, so the older @modelcontextprotocol/sdk v1 line is still maintained and both can coexist in one package.json. Note that the v2 SDK requires a Standard Schema validator exposing a jsonSchema property, which currently means zod 4. ### Do I need to implement server/discover myself? No. Implementing server/discover is a MUST in the 2026-07-28 spec, but the v2 SDK answers it automatically from your registered tools, prompts, and resources. The SDK also stamps resultType on every result and applies any ttlMs and cacheScope cache hints you configure. ### What replaced sampling, elicitation, and roots in the 2026-07-28 spec? Multi Round-Trip Requests, or MRTR. Instead of the server calling back into the client, your handler returns an inputRequired result. The client gathers the answers and re-issues the original request with those answers plus the echoed requestState. The same handler works on 2025-era connections through the SDK legacy shim. ### What is the requestState security risk in MCP? The requestState blob attached to an inputRequired result round-trips through the client, so it comes back as attacker-controlled input. If it influences authorization or business logic and is not integrity-protected, an attacker can tamper with it. Sign it with an HMAC using createRequestStateCodec and a shared secret from the environment, not a per-process random key. ### Can one MCP server support both the 2025 and 2026 spec revisions? Yes. Pass legacy: stateless to createMcpHandler and one endpoint classifies each request by its shape: an initialize body routes to the legacy leg, and a _meta protocol-version envelope routes to the stateless leg. Both are built from the same server factory, so they cannot drift apart. --- _Canonical page: https://mcpplaygroundonline.com/blog/build-mcp-server-2026-spec — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Claude Opus 5 + MCP Servers: Strengths, Benchmarks & When to Use It > Claude Opus 5 is built for complex agentic and coding work — the model to reach for on hard MCP tool chains. Its specs, real strengths on tool calls, how it compares with Sonnet 5, Opus 4.8 and Fable 5, and when it is worth the credits. **Source:** https://mcpplaygroundonline.com/blog/claude-opus-5-mcp-servers **Author:** Nikhil Tiwari **Published:** 2026-07-25 **Category:** Development **Reading time:** 10 min read --- 📖 TL;DR - **Claude Opus 5** is Anthropic's model for complex agentic and coding work — a step change over Opus 4.8 on long, tricky MCP tool chains, at the same price. - Its edge shows up in **tool-selection accuracy** and **long-context planning**, not raw chat speed. 1M-token context, 128K max output, extended thinking on by default. - Connect any MCP server in [MCP Playground Agent Studio](/mcp-agent-studio), pick _Claude Opus 5_, and watch every call. - Use **Sonnet 5** for everyday runs; reach for **Opus 5** when the plan spans many tools with write access. **Fable 5** remains the highest-capability tier above it. _Model Context Protocol_ hands a model dozens of tools. The hard part is picking the right one, in the right order, every time. That is a **reasoning problem, not a plumbing problem** — and reasoning is exactly where Claude Opus 5 is built to win. I have spent the past week running **Claude Opus 5 against MCP servers** — GitHub, Postgres, Linear, and messy multi-server setups. This post is the honest version I would give a teammate: its real strengths, how it benchmarks for agents, and when it is worth the credits. You will also see **when Opus 5 is overkill**. Pick wrong and you either burn budget or ship an agent that fumbles a tool call. ## What Is Claude Opus 5? **Claude Opus 5 is Anthropic's model for complex agentic coding and enterprise work.** It is the one you reach for when the thinking cannot slip. Where _Sonnet 5_ is the fast everyday workhorse, Opus 5 is tuned for the **slow, careful planning** that hard agents need. Above it sits _Claude Fable 5_, the highest-capability tier — Opus 5 runs at roughly half its cost. The published specs matter for MCP work, because tool schemas and tool output eat context fast: - **1M-token context window** — the default and the maximum. Room for large tool sets plus long tool output. - **128K max output tokens** — enough headroom for long multi-step runs. - **Extended thinking is on by default** — unlike Opus 4.8, where you had to ask for it. - **$5 / $25 per million input/output tokens** on Anthropic's API — the same price as Opus 4.8, which makes it a drop-in upgrade. In [MCP Playground](/mcp-agent-studio), Opus 5 sits in the **Elite tier** — the same cost bucket as Opus 4.6, 4.7 and 4.8, at 15 credits per run. That pricing sets the intent. You **spend Opus 5 where a wrong tool call costs more than the model does**. New to the protocol itself? Start with [what is Model Context Protocol](/blog/what-is-model-context-protocol), then come back. ## Claude Opus 5 Strengths That Matter for MCP Benchmarks are nice. But for agents, **a few specific strengths decide whether your run ships or stalls.** Here is what stood out in my Opus 5 testing: - **Tool-selection accuracy.** It reads a schema and picks `complete_task` over `delete_task` — the mistakes smaller models make. - **Long-context planning.** It holds a 10-step plan across many tool outputs without losing the thread. - **Deep code reasoning.** On GitHub MCP work — diffs, review, chained commits — it plans before it acts. - **Argument discipline.** Required fields get filled correctly, so fewer calls bounce with a 400. The theme is consistency. **Opus 5 is not flashier; it is steadier.** That is what you want on write actions. Want to see this live before you trust it? [Test any MCP server free](/mcp-test-server) and watch each Opus 5 call in the browser. ## Claude Opus 5 Performance Benchmarks for Agents Standard leaderboards measure chat and code. **For MCP, I care about a different scoreboard: how well a model drives tools.** So I benchmark on the metrics that actually predict agent reliability: What I measure Why it matters Opus 5 vs smaller models **Tool-selection accuracy** Wrong tool = wrong action Clear lead on ambiguous schemas **Multi-step chain success** Agents rarely need one call Holds 5+ step plans reliably **Argument correctness** Bad args bounce as 400s Fewer required-field misses **Recovery after a tool error** Real servers return 401/410 Re-plans instead of looping My takeaway: **Opus 5's benchmark story is reliability, not speed.** It trades a few seconds of latency for calls that land. Do not take my numbers on faith. **Run the same prompt on two models side by side** — the studio's compare view makes it a 30-second test. For the wider framing of tools vs plain calls, read [MCP vs function calling vs API](/blog/mcp-vs-function-calling-vs-api-comparison). ## Why Pair Claude Opus 5 With MCP Servers? Here is the problem every agent builder hits. **MCP gives a model dozens of tools — and dozens of ways to pick the wrong one.** A weak model forgets a required argument, or loops, or grabs the first plausible tool. **The tools work; the reasoning wobbles.** Your demo passes, then production drifts. That gap is the frustration. **Opus 5 closes the reasoning half.** It reads the schema, plans the sequence, then fills arguments with fewer misses. I saw it clearly on a **multi-server agent** — GitHub plus Postgres plus Slack, one prompt. It paused, checked schemas, and chained three calls in the right order. That difference matters most on _write_ actions. Creating an issue, running SQL, sending a message — **you do not get a second try**. ## How to Use Claude Opus 5 With MCP Servers (Step by Step) You do not need a local setup. The whole loop runs in the browser. Here is the flow I use in [MCP Playground Agent Studio](/mcp-agent-studio). ### Connect a Remote or Hosted MCP Server **Paste your MCP server URL** into the connection field. Any streamable-HTTP or SSE endpoint works. No server yet? Deploy one in a click from the [hosted MCP catalog](/mcp-hosted) — GitHub, Todoist, Airtable, and more. Each hosted server gives you a **live URL you drop straight into the studio**. Then add your access token. ### Switch the Model to Claude Opus 5 Open the **model selector** and choose _Claude Opus 5_. The agent now reasons with Opus 5. Send a prompt like _"list my open GitHub PRs and flag the stale ones."_ Watch the tool calls stream in the panel. **Every call shows its input and output.** So you can confirm Opus 5 picked the right tool with the right arguments. Three steps, start to finish: 1. **Connect** the MCP server URL (plus token) 2. **Select** Claude Opus 5 in the model dropdown 3. **Chat** and inspect each tool call New to Agent Studio? The [Claude MCP apps guide](/blog/claude-mcp-apps-full-guide) walks through the wider workflow. ## Claude Opus 5 vs Sonnet 5 vs Opus 4.8 for MCP Agents **Opus 5 is not always the right call.** The full Claude lineup is in the studio, and each model has a lane. Here is how I split them for MCP work: Model Best for When I skip it **Claude Fable 5** The highest-capability tier; the hardest long-horizon agents Anything Opus 5 already handles — Fable costs far more per run **Claude Opus 5** Hard multi-step agents; deep code reasoning; write actions Simple single-tool reads **Claude Opus 4.8** Long-context code work; same credit tier as Opus 5 When Opus 5 is available for the same cost **Claude Sonnet 5** Everyday agents; most templates Plans that span 5+ tool calls **Claude Haiku 4.5** Fast, cheap lookups; listing tools Anything needing real planning My rule of thumb: **start on Sonnet 5, escalate to Opus 5 when the agent misses steps.** Only go up to Fable 5 if Opus 5 still stalls — it is a much bigger jump in cost per run than in results on most MCP work. Since Opus 5 and Opus 4.8 share the **same 15-credit Elite tier**, I default to Opus 5 when I want the strongest reasoning at that price. See the [Fable 5 + MCP guide](/blog/claude-fable-5-mcp-servers) for the tier above. ## Best MCP Servers to Run With Claude Opus 5 Opus 5 earns its cost on **servers with many tools and real consequences**. Here are the ones I reach for. - **GitHub MCP** — reviewing PRs and chaining commits needs planning. See [10 things you can do with the GitHub MCP server](/blog/10-things-you-can-do-with-github-mcp-server). - **Postgres MCP** — natural-language SQL where a bad query is expensive. Recipe: [Postgres MCP analytics agent](/blog/postgres-mcp-claude-analytics-agent-recipe). - **Multi-server combos** — GitHub + Linear + Slack in one conversation. This is where **Opus 5 pulls ahead hardest**. The pattern is simple. **More tools plus write access equals more reason to run Opus 5.** For single-tool reads — a weather lookup, a doc fetch — a Haiku or Sonnet run is plenty. **Match the model to the blast radius.** Browsing for ideas? The [awesome MCP servers list](/blog/awesome-mcp-servers) has 70+ tested options to point Opus 5 at. ## Getting Reliable Tool Calls From Claude Opus 5 Even the strongest model needs a clean setup. **Most "the agent broke" moments are really schema or prompt problems.** Here is what keeps Opus 5 reliable in my runs: - **Write tight tool descriptions.** Opus 5 reads them literally — vague descriptions cause vague calls. - **Mark required arguments clearly.** Ambiguous schemas are where even strong models slip. - **Confirm before write actions.** Ask the agent to state the exact change first. - **Watch the tool panel.** If an input looks wrong, fix the prompt, not the model. A subtle one: **the server, not the model, returns most errors you will see.** A 410 or 401 in a tool output is the API talking, not Opus 5. When calls fail, this [MCP server troubleshooting guide](/blog/mcp-server-troubleshooting-common-errors-fix) maps the common ones fast. And before you point any agent at a production server, **scan it**. [Scan your MCP server](/mcp-security-scanner) for tool-poisoning and injection risks first. ## How MCP Playground Helps **MCP Playground is where I test all of this without installing anything.** It runs in the browser — no API keys, no local setup. Connect any MCP server, pick _Claude Opus 5_ or any of 70+ models, and watch every tool call in real time. Server testing is free; agent runs spend credits by model tier, and you get free credits on sign-up. The **compare view** lets me A/B Opus 5 against Sonnet 5 on the same prompt. So I only spend the Elite tier where it earns its keep. And the [hosted MCP catalog](/mcp-hosted) gives me a live server URL in one click — no infra to babysit. ## Frequently Asked Questions **Is Claude Opus 5 good for MCP agents?** Yes — it is built for complex agentic and coding work, tuned for accurate tool selection and long multi-step plans. It shines on multi-server agents where a wrong tool call is costly. **How do I use Claude Opus 5 with an MCP server?** Open MCP Playground Agent Studio, paste your MCP server URL and token, choose _Claude Opus 5_ in the model list, and chat. Every tool call is shown live. **Opus 5 or Opus 4.8 for MCP?** They share the same 15-credit Elite tier — and the same $5/$25 per-MTok API pricing — so I default to Opus 5 for the stronger reasoning at that price. Opus 4.8 remains a solid long-context option. **Opus 5 or Fable 5 for MCP?** Fable 5 is the highest-capability tier and costs roughly twice as much per token; Opus 5 covers the large majority of MCP agent work. Start on Opus 5 and only escalate if it genuinely stalls. ## Conclusion **Claude Opus 5 is the model you save for the hard MCP agents** — multi-step, multi-server, write-heavy work where reasoning cannot wobble. For everyday runs, Sonnet 5 does the job cheaper. The fastest way to feel the difference is to try both on your own MCP server. [Test any MCP server free](/mcp-test-server) and switch models mid-chat to see which one holds the plan. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work, why the same server behaves differently per model, and what to measure. Other guides in this series: [DeepSeek V4](/blog/testing-mcp-with-deepseek), [Qwen](/blog/test-mcp-server-with-qwen-models), [Gemini](/blog/test-mcp-server-with-gemini-models), [GLM](/blog/test-mcp-server-with-glm-models), [GLM 5.3](/blog/glm-5-3-mcp-servers), [Grok](/blog/testing-mcp-with-grok-xai), [Kimi K2.6](/blog/test-mcp-server-with-kimi-k2-6), [Fable 5.1 vs GPT-6 Astra](/blog/fable-5-1-vs-gpt-6-astra-mcp). ## Frequently asked questions ### Is Claude Opus 5 good for MCP agents? Yes. Claude Opus 5 is built for complex agentic coding and enterprise work, tuned for accurate tool selection and long multi-step planning, with a 1M-token context window and extended thinking on by default. It shines on multi-step, multi-server MCP agents where a wrong tool call is costly. For simple single-tool reads, a cheaper model like Sonnet 5 or Haiku 4.5 is usually enough. ### How do I use Claude Opus 5 with an MCP server? Open MCP Playground Agent Studio, paste your MCP server URL and access token, choose Claude Opus 5 in the model selector, and send a prompt. Every tool call is shown live with its input and output, so you can confirm the model picked the right tool with the right arguments — all in the browser, no local setup. ### What are Claude Opus 5 strengths for MCP? For MCP work, Opus 5 stands out on tool-selection accuracy, long-context planning across many tool outputs, argument correctness on required fields, and recovery after a tool returns an error. The theme is reliability on multi-step and write-heavy agent runs rather than raw chat speed. ### Should I use Claude Opus 5 or Opus 4.8? In MCP Playground both sit in the same 15-credit Elite tier, and both cost $5/$25 per million input/output tokens on Anthropic API pricing, so cost is not the deciding factor. I default to Opus 5 for the stronger reasoning at that price, and treat Opus 4.8 as a solid long-context alternative. The compare view lets you run the same prompt on both and pick the winner. ### Should I use Claude Opus 5 or Claude Fable 5 for MCP? Claude Fable 5 is the highest-capability tier and costs roughly twice as much per token, so Opus 5 is the sensible default for MCP agent work. Start on Opus 5 and escalate to Fable 5 only when Opus 5 genuinely stalls on a long-horizon, multi-server run. In MCP Playground both are in the model list, so you can run the same prompt on each and compare. ### How many credits does Claude Opus 5 cost per run? Claude Opus 5 costs 15 credits per agent run in MCP Playground, placing it in the Elite tier alongside Opus 4.6, 4.7, and 4.8. Use it where a wrong tool call costs more than the model does, and drop to Sonnet 5 or Haiku 4.5 for simple reads. --- _Canonical page: https://mcpplaygroundonline.com/blog/claude-opus-5-mcp-servers — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # MCP Tasks Extension: Long-Running Jobs Without Blocking Your Agent (2026) > The MCP Tasks extension lets agents kick off a 20-minute job, get a task ID back, and poll for the result later. Here is how the call-now, fetch-later pattern works. **Source:** https://mcpplaygroundonline.com/blog/mcp-tasks-extension-long-running-operations **Author:** Nikhil Tiwari **Published:** 2026-07-22 **Category:** Development **Reading time:** 9 min read --- 📖 TL;DR - The **MCP Tasks extension** gives long-running work first-class support — no more tool calls that hang for 20 minutes. - It uses a **call-now, fetch-later** pattern: submit a job, get a task ID, then poll `tasks/get` while the conversation keeps moving. - Tasks moved **out of the core protocol** into an official extension in the 2026 redesign, rebuilt around the new stateless core. - Test how your server handles long jobs in [MCP Playground](/mcp-test-server) — free, in the browser. Some tools finish in 50 milliseconds. Others kick off a data pipeline that runs for 20 minutes. Until 2026, MCP treated both the same way — one blocking request, one response. That falls apart the moment work outlives the request. The **MCP Tasks extension** fixes this. It lets an agent start a long job, get a handle back, and check on it later — without freezing the chat. If you build agents that run ETL jobs, multi-repo evals, or overnight batch work, this is the piece of the 2026 spec you actually need. Here is how it works. ## What is the MCP Tasks extension? The _Tasks extension_ is an official MCP extension for long-running operations. It lets a server accept a request, return a task handle immediately, and do the real work in the background. The client then polls or subscribes for the result. The model is free to answer other questions in the meantime. Each task is a **durable state machine**. It carries the execution state of a request — running, done, failed — behind a single ID the receiver generates. The reference lives at [modelcontextprotocol/ext-tasks](https://github.com/modelcontextprotocol/ext-tasks) on GitHub, versioned independently from the core spec. ## Why blocking tool calls break real agents **The problem:** a plain tool call is synchronous. The client sends a request and waits for one response. That is fine for a database read. It is a disaster for a job that takes minutes. **It gets worse.** A long request holds a connection open. On the new stateless infrastructure, that means timeouts, dropped load-balancer connections, and gateways that give up mid-job. Your agent looks frozen. The user assumes it crashed. The pipeline is still running, but nobody can see it. **The fix** is to stop waiting. Return a receipt now, deliver the result later. That is exactly what Tasks does. ## The call-now, fetch-later pattern The Tasks flow has three moves. Think of it like ordering food with a buzzer. 1. **Call now.** The client invokes a task-capable tool. The server returns a task ID instead of a final result. 2. **Do other work.** The agent keeps talking to the user. The conversation is never blocked. 3. **Fetch later.** The client polls `tasks/get` with the ID until the task reaches a terminal state, then reads the result. This decouples the length of the work from the length of the request. A 20-minute job and a 200-millisecond job use the same clean handshake. ## The task lifecycle: five states Every task moves through a small set of states. That gives the agent and the user real visibility instead of a spinner. State What it means `working` The job is running. Keep polling. `input_required` The task paused and needs more data from the client. `completed` Done. The result is ready to fetch. `failed` The job errored out. Read the error payload. `cancelled` The client called `tasks/cancel` and the work stopped. `working` and `input_required` are non-terminal. The other three are terminal — once you hit them, stop polling. ## The three methods: get, update, cancel The 2026 redesign trimmed the API down to what agents actually use. - **`tasks/get`** — poll a task by ID to read its current state and, once terminal, its result. - **`tasks/update`** — send data back into a task that is sitting in `input_required`. - **`tasks/cancel`** — stop a task you no longer need so the server can free resources. Notice what is missing: the old blocking `tasks/result` call. It is gone. Instead of one method that hangs until the job finishes, you poll `tasks/get`. That plays nicely with stateless servers and plain HTTP load balancers. **Tip:** back off your polling interval. Start at a second or two, then widen the gap for jobs you know run for minutes. Hammering `tasks/get` every 100ms just burns tokens and rate limits. ## What changed from the 2025-11-25 version Tasks is not brand new. It first shipped as an **experimental core feature** in the 2025-11-25 spec. Production use exposed two problems. The blocking result call did not fit long jobs, and baking tasks into the core made the protocol heavier for servers that never needed them. So the 2026 redesign made two calls: - **Moved out of core** into an official, independently versioned extension. Servers opt in. - **Rebuilt around statelessness** — polling via `tasks/get` replaced the blocking `tasks/result` method. If you built against the experimental API, you must migrate. The lifecycle-based extension is the supported path going forward. ## When should you reach for Tasks? Not every tool needs this. Use Tasks when the work can plausibly outlive a single request. - Kicking off a **20-minute data pipeline** or ETL job - Running a **multi-repo evaluation** across a large codebase - An **overnight document classification** batch - Large **file conversions** or media processing - Multi-step **infrastructure provisioning** For a fast lookup or a single API read, skip it. A plain tool call is simpler and cheaper. ## How MCP Playground can help Before you ship a task-capable server, you want to see the whole lifecycle actually work — states, polling, and the final payload. [MCP Agent Studio](/mcp-agent-studio) connects a real AI model to your server and shows every call live. You watch the task fire, transition through `working`, and land on `completed` — no local setup. Testing a long-running MCP server? Connect it, fire a task, and watch every state change in your browser. [Test any MCP server free →](/mcp-test-server) ## Frequently Asked Questions **What is the MCP Tasks extension?** It is an official MCP extension that adds first-class support for long-running operations, letting a server return a task ID immediately and deliver the result later while the conversation keeps moving. **How do MCP tasks work?** A client calls a task-capable tool, gets a receiver-generated task ID, and polls `tasks/get` until the task reaches a terminal state — completed, failed, or cancelled. **Is Tasks part of the MCP core protocol?** No. It started as an experimental core feature in 2025-11-25 but was moved into an official, independently versioned extension in the 2026 redesign. ## Conclusion **The Tasks extension is how MCP finally handles work that takes minutes, not milliseconds.** Call now, fetch later, poll `tasks/get`, and never freeze the chat again. The best way to trust it is to watch it run. [Test any MCP server free](/mcp-test-server) and see the full task lifecycle end to end. ## Frequently asked questions ### What is the MCP Tasks extension? The MCP Tasks extension is an official Model Context Protocol extension that adds first-class support for long-running operations. Instead of a blocking tool call, a task-capable server returns a task ID immediately and does the real work in the background, so the agent can deliver the result later without freezing the conversation. ### How does the call-now, fetch-later pattern work? The client invokes a task-capable tool and gets back a receiver-generated task ID instead of a final result. The agent keeps doing other work while the client polls tasks/get with that ID until the task reaches a terminal state (completed, failed, or cancelled), then reads the result. ### What are the MCP task lifecycle states? A task moves through five states: working (running), input_required (paused, needs more data), completed (done, result ready), failed (errored), and cancelled (stopped by the client). Working and input_required are non-terminal; the other three are terminal. ### What methods does the Tasks extension use? Three: tasks/get to poll a task by ID, tasks/update to send data back into a task waiting in input_required, and tasks/cancel to stop a task you no longer need. The old blocking tasks/result method was removed in favor of polling. ### Do I need to migrate from the experimental Tasks API? Yes. Tasks first shipped as an experimental core feature in the 2025-11-25 spec, but the 2026 redesign moved it into an official extension and replaced the blocking tasks/result call with polling via tasks/get. Code built against the experimental API must be updated to the extension-based lifecycle. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-tasks-extension-long-running-operations — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Migrate Your MCP Server to the 2026-07-28 Spec: What Breaks & How to Fix It > The 2026-07-28 MCP spec is the biggest revision since launch. Sessions are gone, three features are deprecated, and error codes changed. Here is the migration checklist. **Source:** https://mcpplaygroundonline.com/blog/migrate-mcp-server-2026-07-28-stateless **Author:** Nikhil Tiwari **Published:** 2026-07-22 **Category:** Development **Reading time:** 11 min read --- 📖 TL;DR - The **2026-07-28 MCP spec** is the largest revision since launch — the final spec ships July 28, 2026. - **Sessions are gone.** No `initialize` handshake, no `Mcp-Session-Id` header. Servers are stateless now. - **Three features deprecated:** Roots, Sampling, and Logging, each with a 12-month removal window. - **One error code changed** and JSON Schema 2020-12 is now fully supported. - Test your migrated server against a real model in [MCP Playground](/mcp-test-server) before you ship. The **2026-07-28 MCP spec** is not a routine update. The maintainers call it the biggest revision since the protocol launched. If you run a server built on the 2025-11-25 spec, some of it will break. Not maybe — will. The good news: the changes are concrete and finite. This is a migration checklist, not a rewrite. I will walk through every breaking change and exactly what to do about it. Starting a brand-new server instead? Skip the checklist and read [how to build an MCP server on the 2026-07-28 spec](/blog/build-mcp-server-2026-spec) — it builds straight onto the stateless design. Let me start with the one that touches every remote server. ## The headline change: your server is stateless now The old protocol was stateful. A client opened a connection with an `initialize` handshake, got an `Mcp-Session-Id`, and every later request carried that session ID back. That forced **sticky routing**. Requests had to hit the same server instance, backed by a shared session store, with deep packet inspection at the gateway. The 2026-07-28 spec deletes all of it. **There is no `initialize` handshake and no `Mcp-Session-Id`.** Instead, each request carries the protocol version and client info in `_meta` fields. Any instance in a load-balanced cluster can handle any request. The payoff: a remote server that needed sticky sessions and a shared store can now sit behind a **plain round-robin load balancer**. I covered the concept in depth in [MCP Goes Stateless](/blog/mcp-stateless-2026-release-candidate) — this post is about the migration itself. ## What breaks: the migration checklist Here is the full list of breaking changes, most impactful first. Change What to do Session handshake removed Drop `initialize` and `Mcp-Session-Id`; read version/client from `_meta`. Roots deprecated Move to tool parameters, resource URIs, or config. Sampling deprecated Call the LLM API directly from your server. Logging deprecated Emit to stderr or OpenTelemetry instead. Error code changed Missing resource is now `-32602`, not `-32002`. Tasks API redesigned Migrate from experimental core to the [Tasks extension](/blog/mcp-tasks-extension-long-running-operations). ## Three features are deprecated: Roots, Sampling, Logging The spec added a formal deprecation lifecycle: **Active → Deprecated → Removed**, with a minimum 12-month window before anything disappears. Three core features enter that pipeline now. They still work, but you should plan to move off them. - **Roots →** replace with tool parameters, resource URIs, or plain config. Pass the scope explicitly instead of relying on the roots capability. - **Sampling →** if your server asked the client to "sample" the model, call the LLM API directly instead. Cleaner and fewer round trips. - **Logging →** stop using the protocol log channel. Write to `stderr` or ship structured logs to OpenTelemetry. **Do not wait 12 months.** The window protects you from a hard break, but new clients will optimize for the replacements. Migrating early means fewer compatibility surprises later. ## The error code change that will bite you This one is small and easy to miss. A missing resource used to return error code `-32002`. In the 2026-07-28 spec it returns **`-32602`** — the standard JSON-RPC "invalid params" code. If your client has a hardcoded check for `-32002`, it will silently stop matching. Grep your codebase for that literal and update it. ## New capabilities you get for free Migration is not all removal. The spec adds infrastructure wins you can adopt. ### Routable, Cacheable, Traceable headers - **Routable:** `Mcp-Method` and `Mcp-Name` headers let a gateway route without inspecting the body. - **Cacheable:** list responses carry `ttlMs` and `cacheScope`, so clients cache tool lists like HTTP `Cache-Control`. - **Traceable:** W3C Trace Context propagation is standardized across every SDK. ### Full JSON Schema 2020-12 Tool input schemas now support the full JSON Schema 2020-12 draft. That means `oneOf`, `anyOf`, and `allOf` in your tool definitions. If you were flattening complex inputs to work around the old limits, you can stop. ## Authorization tightened up Six auth proposals bring MCP closer to standard OAuth 2.0 and OpenID Connect. - Mandatory validation of the `iss` parameter, per RFC 9207. - OIDC `application_type` declared during client registration. - Clarified scope accumulation and refresh-token handling. If you built auth against my [OAuth 2.1 guide](/blog/mcp-server-oauth-authentication-guide), review the `iss` validation rule — it is now required, not optional. ## The timeline and how to test The dates matter. The release candidate locked on **May 21, 2026**. The final spec publishes **July 28, 2026**. Tier 1 SDK support is expected within the 10-week window around the final release. Check your SDK version before you assume a feature landed. My migration order: 1. Update to a spec-compliant SDK build. 2. Strip session handling and read `_meta` instead. 3. Swap the deprecated features for their replacements. 4. Fix the `-32002` → `-32602` checks. 5. Run the server against a real model and confirm every tool still resolves. Migrated to the 2026-07-28 spec? Point a real AI model at your server and confirm every tool still works — no local setup. [Test any MCP server free →](/mcp-test-server) ## How MCP Playground can help The riskiest part of a migration is the stuff you did not know broke. A tool that stopped resolving. An auth flow that fails silently. [MCP Playground](/mcp-test-server) connects your server to a live model in the browser. You see every tool list, every call, and every error — so a regression shows up before your users hit it. ## Frequently Asked Questions **When does the 2026-07-28 MCP spec ship?** The final specification publishes on July 28, 2026. The release candidate locked on May 21, 2026. **Do I have to migrate right away?** The stateless change affects new clients immediately, but deprecated features get a 12-month minimum window. Migrate early to avoid compatibility surprises. **What is the biggest breaking change?** The removal of the session handshake and `Mcp-Session-Id`. Servers are stateless, so session-dependent code must be reworked. ## Conclusion **The 2026-07-28 spec makes MCP stateless, deprecates Roots, Sampling, and Logging, and tightens auth.** Update your SDK, strip sessions, swap the deprecated features, and fix the error code. Then prove it works. [Test any MCP server free](/mcp-test-server) against a real model before the final spec lands. 🧪 Verify the migration against something that actually speaks 2026-07-28 Once your server is migrated, paste its URL into the [MCP Checker](/mcp-checker) and force the 2026-07-28 revision — it reports the revision you asked for next to the one that answered, plus the raw JSON-RPC. If you also maintain a client, point it at the [hosted mock MCP servers](/mock-mcp-servers), which serve both revisions and let you pin either one to test rejection paths deliberately. ## Frequently asked questions ### When does the 2026-07-28 MCP specification ship? The final 2026-07-28 specification publishes on July 28, 2026. The release candidate locked on May 21, 2026, and Tier 1 SDK support is expected within roughly a 10-week window around the final release. ### What breaks when I migrate to the 2026-07-28 MCP spec? The session handshake (initialize and Mcp-Session-Id) is removed, so servers become stateless. Roots, Sampling, and Logging are deprecated. The missing-resource error code changes from -32002 to -32602, and the Tasks API moved from experimental core to an official extension. ### Why did MCP remove sessions? Sessions forced sticky routing to a single server instance, a shared session store, and deep packet inspection at the gateway. Removing them lets each request carry protocol version and client info in _meta fields, so a stateless server can run behind a plain round-robin load balancer. ### What replaces Roots, Sampling, and Logging? Roots move to tool parameters, resource URIs, or config. Sampling is replaced by calling the LLM API directly from your server. Logging moves to stderr or OpenTelemetry. Each deprecated feature has a minimum 12-month removal window under the new Active to Deprecated to Removed lifecycle. ### Do I need to change my error handling? Yes if you check for specific codes. A missing resource now returns the standard JSON-RPC -32602 (invalid params) instead of -32002. Any hardcoded -32002 check will silently stop matching, so search your codebase and update it. --- _Canonical page: https://mcpplaygroundonline.com/blog/migrate-mcp-server-2026-07-28-stateless — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # MCP Enterprise-Managed Authorization: Centralized Access Control Goes Stable (2026) > MCP Enterprise-Managed Authorization is now stable, letting organizations control MCP server access through their own identity provider. Anthropic, Microsoft, and Okta already adopted it. **Source:** https://mcpplaygroundonline.com/blog/mcp-enterprise-managed-authorization **Author:** Nikhil Tiwari **Published:** 2026-07-21 **Category:** Security **Reading time:** 9 min read --- 📖 TL;DR - **Enterprise-Managed Authorization (EMA)** is now a stable MCP extension. - It lets organizations control MCP server access through their own **identity provider** — one place, not per-server. - Already adopted by **Anthropic, Microsoft, and Okta**, with more MCP servers following. - It aligns MCP auth with standard **OAuth 2.0 and OpenID Connect** deployments IT teams already run. Enterprise security teams had a real problem with MCP. Every server did its own thing for access control. That does not fly when you have hundreds of employees and a compliance team asking who can reach what. **Enterprise-Managed Authorization**, or EMA, fixes that. It moves access control out of individual servers and into your identity provider. As of July 2026, it is a stable extension — not a proposal. If you run MCP inside a company, this is the piece that makes it auditable. Here is how it works and why it matters. ## What is Enterprise-Managed Authorization? _Enterprise-Managed Authorization_ is an official MCP extension that gives organizations a centralized way to govern MCP server access through their identity provider (IdP). Instead of each server owning its own auth logic, access decisions run through the IdP your company already uses — the same one behind your email, your VPN, and your SaaS apps. The extension was promoted to **stable status** in July 2026. Stable means the contract is locked and safe to build production systems on. ## The problem EMA solves: auth sprawl **The problem:** MCP servers each handled authorization differently. One used bearer tokens, another its own OAuth flow, a third had almost nothing. **It gets worse at scale.** When an employee leaves, someone has to revoke access on every server by hand. Miss one, and a former employee still has a live path to your data. Auditors hate this. There is no single answer to "who can access which MCP servers?" **EMA solves it** by making the IdP the single source of truth. Grant and revoke in one place. Access to every connected server follows automatically. ## How EMA works EMA puts your identity provider in the middle of every access decision. The flow looks like this. 1. A user or agent tries to reach an MCP server. 2. The server defers the access decision to the organization's IdP. 3. The IdP checks group membership, policy, and scopes it already manages. 4. Access is granted or denied centrally, and the event is logged where security already looks. Because it is built on standard **OAuth 2.0 and OpenID Connect**, it plugs into infrastructure IT teams already run. No custom identity stack per server. **The win for security teams:** deprovisioning becomes one action. Remove a user from the IdP group and every MCP server that trusts EMA drops their access at once. ## Who is already using it? Adoption is the reason "stable" means something here. This is not a spec sitting on a shelf. - **Anthropic** — the maintainer behind MCP, running EMA on its own servers. - **Microsoft** — bringing it into its enterprise identity stack. - **Okta** — the identity vendor whose whole business is exactly this problem. A growing list of individual MCP servers has adopted it too. When your IdP vendor and the protocol maintainer both back the same extension, integration friction drops fast. ## EMA vs standard MCP OAuth MCP already supports OAuth 2.1 for auth. So what does EMA add? Standard MCP OAuth is **server-centric**. Each server runs its own flow and manages its own clients. EMA is **organization-centric**. The company's IdP is the authority, and servers defer to it. Standard MCP OAuth Enterprise-Managed Auth **Authority** Each server Company IdP **Revocation** Per server, manual Central, one action **Audit** Scattered logs One IdP trail **Best for** Individual servers Enterprises at scale They are not rivals. EMA builds on the OAuth foundation I covered in the [MCP OAuth guide](/blog/mcp-server-oauth-authentication-guide) and adds the enterprise governance layer on top. ## What it means if you build MCP servers If you want your server to land in enterprises, supporting EMA is becoming table stakes. A security team evaluating your server will ask one question: can we govern this from our IdP? If the answer is no, procurement stalls. Supporting EMA means you inherit the customer's identity policies instead of asking them to trust yours. That is a much easier sell. ## How MCP Playground can help Before you roll a server into an enterprise, you want to confirm the auth flow behaves — that a valid token connects and an invalid one is refused. [MCP Playground](/mcp-test-server) lets you connect a remote MCP server with your credentials and watch the handshake in the browser. You see exactly what the server accepts before you hand it to security review. Rolling MCP out across your org? Test the auth flow on any remote MCP server before it hits production. [Test any MCP server free →](/mcp-test-server) ## Frequently Asked Questions **What is MCP Enterprise-Managed Authorization?** It is a stable MCP extension that lets organizations control MCP server access through their own identity provider, instead of each server managing auth on its own. **Who has adopted EMA?** Anthropic, Microsoft, and Okta, along with a growing number of individual MCP servers. **Is EMA different from MCP OAuth?** Yes. OAuth in MCP is server-centric; EMA is organization-centric, making the company IdP the authority and letting servers defer access decisions to it. ## Conclusion **Enterprise-Managed Authorization is what makes MCP governable at company scale.** One identity provider, central revocation, one audit trail — now stable and backed by Anthropic, Microsoft, and Okta. Before you deploy, prove the auth flow works. [Test any MCP server free](/mcp-test-server) and watch the handshake live. ## Frequently asked questions ### What is MCP Enterprise-Managed Authorization? Enterprise-Managed Authorization (EMA) is a stable Model Context Protocol extension that gives organizations a centralized way to control MCP server access through their own identity provider, rather than each server managing authorization independently. ### Is Enterprise-Managed Authorization stable? Yes. EMA was promoted to stable status in July 2026, meaning the contract is locked and safe to build production systems on. It has been adopted by Anthropic, Microsoft, Okta, and a growing number of MCP servers. ### How is EMA different from standard MCP OAuth? Standard MCP OAuth is server-centric — each server runs its own flow and manages its own clients. EMA is organization-centric: the company identity provider is the authority, and servers defer access decisions to it. That centralizes revocation and audit. ### What problem does EMA solve for enterprises? It ends auth sprawl. Instead of granting and revoking access on every MCP server by hand, security teams manage access in one identity provider. Removing a user from an IdP group drops their access across every server that trusts EMA. ### Should my MCP server support EMA? If you want enterprise adoption, yes. Security teams evaluating a server will ask whether they can govern it from their identity provider. Supporting EMA lets you inherit the customer identity policies instead of asking them to trust your own auth stack. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-enterprise-managed-authorization — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # The MCP stdio RCE Vulnerability: What OX Security Found & How to Protect Your Servers > OX Security disclosed a systemic RCE in the MCP SDK stdio transport affecting 150M+ downloads and 7,000+ servers. Anthropic says it is by design. Here is how to protect yours. **Source:** https://mcpplaygroundonline.com/blog/mcp-stdio-rce-vulnerability **Author:** Nikhil Tiwari **Published:** 2026-07-20 **Category:** Security **Reading time:** 10 min read --- ⚠️ TL;DR - OX Security disclosed a **systemic RCE** in the MCP SDK's stdio transport on April 15, 2026. - It affects **every language SDK** — Python, TypeScript, Java, Rust — an estimated **150M+ downloads** and **7,000+ public servers**. - The root cause: the stdio transport launches a `command` field as a subprocess with **no validation or allowlist**. - Anthropic says the behavior is **by design** — sanitization is the developer's job. So you have to defend yourself. - [Scan your MCP server](/mcp-security-scanner) to find exposure before an attacker does. On April 15, 2026, OX Security published an advisory that rattled the MCP ecosystem. It described a **design-level remote code execution flaw** in the MCP SDK's stdio transport — one that reaches across every supported language. The scary part is not the bug itself. It is Anthropic's response: this is working as intended, and it will not be patched. That shifts the entire burden onto you. If you run MCP servers, you need to understand this flaw and defend against it yourself. Let me break it down. ## What OX Security disclosed OX Security's advisory covered _command injection_ in the MCP SDK's stdio transport that leads to **remote code execution**. The researchers called it systemic because it is not one buggy library. It is a pattern baked into how the stdio transport is designed across languages. The blast radius they estimated: - **150M+ downloads** of affected SDK packages - **7,000+ publicly exposed servers** - **Python, TypeScript, Java, and Rust** — every major SDK - **12+ CVEs**, including 10+ rated Critical or High The headline entry, **CVE-2026-30623**, covers authenticated RCE via the MCP stdio transport. ## How the stdio RCE actually works The flaw lives in how a stdio MCP server is configured. When you set one up, the SDK takes a `command` field naming the executable to launch, plus an `args` array. In the Python SDK, `StdioServerParameters` accepts that command string and args, then launches them as a local subprocess with `subprocess.Popen()`. Here is the problem in one line: **it runs no validation and no allowlist before executing.** Whatever lands in `command` gets executed on the host. If any part of that value comes from untrusted input — a config file, a registry entry, a remote payload — an attacker can run arbitrary code. The unsafe pattern ``` # The SDK executes whatever 'command' contains — no checks params = StdioServerParameters( command=untrusted_value, # attacker-controlled = RCE args=untrusted_args, ) # subprocess.Popen(command, args) runs on your host ``` This is classic command injection. The novelty is that MCP's design routes untrusted server definitions straight into a subprocess launcher. ## Why it "won't be patched" Anthropic confirmed the behavior and declined to change the protocol. Their position: the stdio execution model is a **secure default**, and sanitizing input is the developer's responsibility. Launching a local subprocess is the whole point of stdio transport. There is logic to it. A stdio server is meant to run a local binary you chose. The SDK cannot know which commands you consider safe. But the practical result is blunt: **there is no upstream fix coming.** The security boundary is yours to enforce. **Read this as a supply-chain risk.** The danger is not you typing a command. It is a malicious server definition — from a registry, a shared config, or a compromised dependency — flowing into your stdio launcher. ## The blast radius: real tools got hit This was not theoretical. OX Security's audit produced CVEs across widely deployed AI platforms, including: - **Windsurf** - **GPT Researcher** - **LiteLLM** (CVE-2026-30623, fixed in v1.83.7-stable and later) - **Agent Zero** - **LangFlow** If you run any of these, update to a patched release now. The downstream projects fixed their exposure even though the SDK behavior stands. ## Are you affected? A quick checklist Work through these. Any "yes" means you need to act. - Do you configure stdio MCP servers from a file, database, or registry an attacker could touch? - Does any `command` or `args` value come from user input or a remote source? - Do you install MCP servers from public registries without reviewing what they launch? - Do you run MCP servers with more OS privileges than they need? ## How to protect your MCP servers Since the SDK will not sanitize for you, build the guardrails yourself. 1. **Allowlist the command field.** Only permit a fixed set of known-good executables. Reject everything else. 2. **Never pass untrusted input into `command` or `args`.** Treat any external server definition as hostile until you have reviewed it. 3. **Prefer remote transports for untrusted servers.** Streamable HTTP does not launch a local subprocess. Use stdio only for binaries you control. 4. **Drop privileges.** Run stdio servers in a sandbox or container with the least OS access they need. Contain the blast if something slips through. 5. **Review the registry entry before you install.** Read exactly what command a third-party server runs. 6. **Update downstream tools.** Windsurf, LiteLLM, LangFlow, and others shipped fixes — apply them. Not sure if your MCP server is exposed? Scan it for risky configuration and connection issues before an attacker finds them. [Scan your MCP server →](/mcp-security-scanner) ## How MCP Playground can help Part of defending a server is knowing exactly what it does when a model connects — which tools it exposes and what they run. [MCP Playground](/mcp-test-server) connects a server in the browser and surfaces every tool and call. Pair it with a [tool-poisoning review](/blog/mcp-security-tool-poisoning-owasp-top-10-mcp-scan) to catch a server that behaves differently than its description claims. ## Frequently Asked Questions **What is the MCP stdio RCE vulnerability?** It is a systemic command-injection flaw in the MCP SDK's stdio transport, disclosed by OX Security on April 15, 2026. The transport launches a configured command as a subprocess with no validation, enabling remote code execution. **Is the MCP stdio RCE patched?** Not in the SDK. Anthropic considers the behavior by design and puts sanitization on the developer. Downstream tools like LiteLLM shipped their own fixes — CVE-2026-30623 is fixed in LiteLLM v1.83.7-stable and later. **How do I protect my MCP server?** Allowlist the command field, never pass untrusted input into command or args, prefer remote HTTP transports for untrusted servers, and run stdio servers with least privilege in a sandbox. ## Conclusion **The MCP stdio RCE is a design-level flaw, not a bug with a patch.** It affects every language SDK, and Anthropic put the security boundary on you. Allowlist your commands, distrust external server definitions, and drop privileges. Then verify: [scan your MCP server](/mcp-security-scanner) to find exposure before someone else does. ## Frequently asked questions ### What is the MCP stdio RCE vulnerability? It is a systemic command-injection flaw in the MCP SDK stdio transport, disclosed by OX Security on April 15, 2026. The stdio transport accepts a command field and launches it as a local subprocess with no validation or allowlist, which can lead to remote code execution across every language SDK — Python, TypeScript, Java, and Rust. ### How many systems are affected? OX Security estimated the flaw affects more than 150 million SDK downloads and over 7,000 publicly exposed servers, with 12 or more CVEs disclosed across tools like Windsurf, GPT Researcher, LiteLLM, Agent Zero, and LangFlow. ### Is the MCP stdio RCE patched? Not in the SDK itself. Anthropic confirmed the stdio execution behavior is by design and declined to change the protocol, stating sanitization is the developer responsibility. Individual downstream tools shipped fixes — for example, CVE-2026-30623 is fixed in LiteLLM v1.83.7-stable and later. ### How do I protect my MCP server from the stdio RCE? Allowlist the command field to a fixed set of known-good executables, never pass untrusted input into command or args, prefer remote HTTP transports for servers you do not control, run stdio servers with least privilege in a sandbox or container, and review registry entries before installing third-party servers. ### Why is stdio transport risky in MCP? Because stdio transport is designed to launch a local binary as a subprocess. The SDK routes the configured command straight into a subprocess launcher without validation, so if any part of that command comes from an untrusted source — a config file, a registry, or a remote payload — it becomes an arbitrary code execution path. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-stdio-rce-vulnerability — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # GPT-5.6 MCP: Testing Servers With Sol, Terra & Luna (2026) > OpenAI's GPT-5.6 Sol, Terra, and Luna are built for agentic tool calling. Here is how to test MCP servers with each model — free in your browser. **Source:** https://mcpplaygroundonline.com/blog/gpt-5-6-mcp-servers-sol-terra-luna **Author:** Nikhil Tiwari **Published:** 2026-07-13 **Category:** Development **Reading time:** 10 min read --- 📖 TL;DR - **GPT-5.6** shipped July 9, 2026 in three tiers — **Sol** (flagship), **Terra** (balanced), and **Luna** (cheapest) — all tuned for agentic tool calling. - All three share a **1M-token context window**, 128K max output, and native **MCP support** in the Responses API. - Test any MCP server against _Sol, Terra, or Luna_ in [MCP Agent Studio](/mcp-agent-studio) — pick the model, connect a server, and watch each tool call live. OpenAI dropped **GPT-5.6** on July 9, 2026 — and this one is aimed squarely at agents. Three models landed at once: _Sol_, _Terra_, and _Luna_. Each is built to **call tools, not just chat**. That makes **testing MCP servers with GPT-5.6** a different exercise than testing a plain chat model. Tool selection is the whole game. I have spent this week pointing all three at MCP servers — GitHub, Postgres, Playwright, and multi-server setups. This post is what I learned. You will see **which tier to run for which workload**, how the new tool-calling features change MCP, and how to test each one free in your browser. Skip it and you will overpay for Sol on jobs Luna handles fine. ## What Is GPT-5.6? Sol, Terra, and Luna Explained **GPT-5.6 is a three-tier model family, not a single model.** OpenAI split it by cost and horsepower so you match the model to the job. Here is the lineup, straight from OpenAI's pricing page: Model Built for Input / Output (per 1M) **GPT-5.6 Sol** Flagship — ambitious agentic work $5.00 / $30.00 **GPT-5.6 Terra** Balanced — efficient, high-volume work $2.50 / $15.00 **GPT-5.6 Luna** Fast, affordable — everyday work $1.00 / $6.00 The specs are shared across all three. **Every tier gets a 1M-token context window, 128K max output, and a February 16, 2026 knowledge cutoff.** So the choice is not about context or capability limits. **It is about how much reasoning each task actually needs.** New to the protocol these models call? Start with [what is Model Context Protocol](/blog/what-is-model-context-protocol), then come back. ## Why GPT-5.6 Changes MCP Tool Calling Here is the part that matters for MCP. **GPT-5.6 does not just call tools one at a time — it can orchestrate them.** The headline feature is _Programmatic Tool Calling_. The model writes JavaScript that chains your tool calls, then runs it in an **isolated V8 sandbox with no network access**. Why care? **The old loop round-trips every tool result back through the model.** Ten calls means ten expensive turns. With Programmatic Tool Calling, the model batches that logic into one script. OpenAI reports **token reductions of 38% to 63.5%** on real workloads. For MCP servers with many tools, that is a big deal. **Fewer round-trips means lower cost and faster agents.** There is a second feature: _ultra multi-agent mode_. GPT-5.6 spins up four subagents in parallel by default. On Terminal-Bench 2.1, that lifted Sol from **88.8% to 91.9%**. Parallel agents split a hard MCP task into focused lanes. Want to see how a model handles your server's tools before you trust any of this? [Test any MCP server free](/mcp-test-server) and watch each call in the browser. ## Sol vs Terra vs Luna: Which for MCP Servers? **Do not default to Sol.** The whole point of three tiers is to stop overpaying. Here is how I split them for MCP work after a week of runs: Model Best MCP job When I skip it **Sol** Long multi-server chains; write actions; ambiguous goals Simple reads or listing tools **Terra** Everyday agents; high-volume automation Plans that span 8+ dependent calls **Luna** Fast lookups, single-tool reads, smoke tests Anything needing real multi-step planning My rule: **start on Luna, move to Terra when it misses steps, reach for Sol only on the hard, expensive-to-fail agents.** The price gap makes this worth it. **Sol costs five times Luna on input and output.** A wrong model choice adds up fast at scale. Do not guess — **run the same prompt on two tiers side by side** and compare the tool calls. That test takes 30 seconds in the studio. ## How to Test MCP Servers With GPT-5.6 (Step by Step) You do not need the OpenAI API or an SDK to try this. The whole loop runs in the browser. Here is the flow I use in [MCP Agent Studio](/mcp-agent-studio). ### Step 1 — Connect Your MCP Server **Paste your MCP server URL into the connection field.** Any Streamable HTTP or SSE endpoint works. No server yet? Deploy one in a click from the [hosted MCP catalog](/mcp-hosted) — GitHub, Playwright, Postgres, and more. ### Step 2 — Pick a GPT-5.6 Tier Open the **model selector** and choose _GPT-5.6 Sol_, _Terra_, or _Luna_. Each shows its credit cost per prompt. For a first run, **Luna is plenty** — cheap and fast. Escalate only when the agent stumbles. ### Step 3 — Send and Inspect Every Tool Call Send a prompt like _"list my open GitHub PRs and flag the stale ones."_ Watch the tool calls stream in the panel. **Click any call to see its exact input and output.** That trace is how you confirm GPT-5.6 picked the right tool with the right arguments. Three steps, start to finish: 1. **Connect** the MCP server URL (plus token if needed) 2. **Select** a GPT-5.6 tier in the model dropdown 3. **Chat** and inspect each tool call live Want the wider workflow? The [step-by-step guide to testing MCP servers](/blog/how-to-test-mcp-servers-step-by-step) covers the full loop. ## GPT-5.6 vs Claude for MCP Agents: The Honest Take **GPT-5.6 is not a clean sweep.** It wins some benchmarks and loses others — and the split matters for MCP. Where **Sol pulls ahead** is agentic, tool-heavy work. On _Agents' Last Exam_, Sol set a new high, beating [Claude Fable 5](/blog/claude-fable-5-mcp-servers) by double digits. It also topped the Coding Agent Index and led Terminal-Bench 2.1. **For long-horizon MCP agents, that is the relevant lane.** But on _SWE-Bench Pro_, Sol scored 64.6% — **trailing Claude by roughly 15 points**. On raw code-fix accuracy, Claude still leads. So the honest read: **GPT-5.6 for tool orchestration and cost, Claude for deep code reasoning.** The right answer depends on your server. The only way to know for your MCP setup is to test both. The studio has **70+ models side by side** — see the [best model for MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling) for the full breakdown. ## Getting Reliable Tool Calls From GPT-5.6 Even a flagship model needs a clean setup. **Most "the agent broke" moments are schema or prompt problems, not model problems.** Here is what keeps GPT-5.6 reliable in my runs: - **Write tight tool descriptions.** GPT-5.6 reads them literally — vague descriptions cause vague calls. - **Mark required arguments clearly.** Ambiguous schemas trip up even strong models. - **Confirm before write actions.** Ask the agent to state the exact change first. - **Start cheap.** Run Luna to smoke-test the connection, then escalate for the real task. A subtle one: **the server, not the model, returns most errors you will see.** A 401 or 410 in a tool output is the API talking, not GPT-5.6. When calls fail, this [MCP troubleshooting guide](/blog/mcp-server-troubleshooting-common-errors-fix) maps the common ones fast. And before you point any agent at a production server, **scan it**. [Scan your MCP server](/mcp-security-scanner) for tool-poisoning and injection risks first. ## How MCP Playground Helps **MCP Playground is where I test all three GPT-5.6 tiers without touching the API.** It runs in the browser, free. Connect any MCP server, pick _Sol, Terra, or Luna_ — or any of 70+ models — and watch every tool call in real time. The **compare view** lets me A/B Sol against Luna, or GPT-5.6 against Claude, on the same prompt. So I spend the flagship only where it earns its keep. And the [hosted MCP catalog](/mcp-hosted) gives me a live server URL in one click — no infra to babysit. ## Frequently Asked Questions **What are GPT-5.6 Sol, Terra, and Luna?** They are the three tiers of OpenAI's GPT-5.6 family, launched July 9, 2026. Sol is the flagship, Terra is balanced, and Luna is the cheapest — all built for agentic tool calling. **Which GPT-5.6 model is best for MCP servers?** Start with Luna for simple reads, use Terra for everyday agents, and reserve Sol for long multi-server chains and write-heavy tasks where a wrong tool call is costly. **Can I test MCP servers with GPT-5.6 for free?** Yes. In MCP Agent Studio you connect any MCP server, pick a GPT-5.6 tier, and watch every tool call live — in the browser, no API key setup. ## Conclusion **GPT-5.6 is the most agent-focused release OpenAI has shipped** — three tiers, programmatic tool calling, and native MCP support. Sol leads on tool orchestration; Luna and Terra cover everyday agents cheaply. The fastest way to find your tier is to try them on your own server. [Test any MCP server free](/mcp-test-server) and switch between Sol, Terra, and Luna mid-chat to see which one holds the plan. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work, why the same server behaves differently per model, and what to measure. Other guides in this series: [DeepSeek V4](/blog/testing-mcp-with-deepseek), [Qwen](/blog/test-mcp-server-with-qwen-models), [Gemini](/blog/test-mcp-server-with-gemini-models), [GLM](/blog/test-mcp-server-with-glm-models), [GLM 5.3](/blog/glm-5-3-mcp-servers), [Grok](/blog/testing-mcp-with-grok-xai), [Kimi K2.6](/blog/test-mcp-server-with-kimi-k2-6), [Fable 5.1 vs GPT-6 Astra](/blog/fable-5-1-vs-gpt-6-astra-mcp). ## Frequently asked questions ### What are GPT-5.6 Sol, Terra, and Luna? They are the three tiers of OpenAI's GPT-5.6 model family, launched July 9, 2026. Sol is the flagship for ambitious agentic work ($5/$30 per 1M tokens), Terra is the balanced tier for high-volume work ($2.50/$15), and Luna is the fast, affordable tier for everyday work ($1/$6). All three share a 1M-token context window, 128K max output, and native MCP support. ### Which GPT-5.6 model is best for testing MCP servers? It depends on the task. Start with Luna for simple reads, listing tools, and smoke tests. Move to Terra for everyday agents and high-volume automation. Reserve Sol for long multi-server chains, ambiguous goals, and write actions where a wrong tool call is expensive. Because Sol costs five times Luna, matching the tier to the job saves real money. ### How is GPT-5.6 different for MCP tool calling? GPT-5.6 adds Programmatic Tool Calling, where the model writes JavaScript that orchestrates your tool calls inside an isolated V8 sandbox with no network access. That batches logic instead of round-tripping every result through the model, cutting tokens by 38 to 63.5 percent. It also has an ultra multi-agent mode that runs four subagents in parallel. ### Is GPT-5.6 better than Claude for MCP agents? It is a split. GPT-5.6 Sol leads on agentic and tool-heavy benchmarks like Agents' Last Exam and Terminal-Bench, which map closely to MCP workloads. But Claude still leads on raw code-fix accuracy, scoring higher on SWE-Bench Pro. The best choice depends on your server, so test both side by side in MCP Playground. ### Can I test MCP servers with GPT-5.6 for free? Yes. MCP Playground runs entirely in the browser. You connect any MCP server, pick GPT-5.6 Sol, Terra, or Luna from the model selector, and watch every tool call in real time with no local setup and no OpenAI API key wrangling. --- _Canonical page: https://mcpplaygroundonline.com/blog/gpt-5-6-mcp-servers-sol-terra-luna — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Build Your First MCP AI Agent — No Code, Right in Your Browser (2026) > Build a no-code AI agent in minutes — connect an MCP server, pick a model, and chat. A beginner walkthrough for your first MCP agent, free in the browser. **Source:** https://mcpplaygroundonline.com/blog/build-first-mcp-agent-no-code **Author:** Nikhil Tiwari **Published:** 2026-07-09 **Category:** Tutorial **Reading time:** 9 min read --- 📖 TL;DR - You can build a **no-code AI agent** in the browser — no install, no Python, no API key setup. - Open [MCP Agent Studio](/mcp-agent-studio), connect an MCP server, pick a model, and chat. That is the whole loop. - No server URL? **Browse the registry, spin up a hosted server, or load a template** — each one fills the connection for you. Most guides to _AI agents_ start with a terminal, a virtualenv, and 40 lines of setup. **You do not need any of that to build your first MCP agent.** You need a browser and five minutes. A **no-code AI agent** is just a model wired to real tools through the _Model Context Protocol_. The studio handles the wiring. I will walk you through it the way I would show a teammate on their first day — connect, message, model, send. By the end you will have a **working MCP agent online** that reads live data and calls real tools. Skip this and you are still stuck reading about agents instead of running one. ## What Is an MCP AI Agent (No Code Needed)? An **MCP agent is an AI model that can call real tools** — not just chat. It reads, writes, and acts through an MCP server. The _Model Context Protocol_ is the standard that connects the model to those tools. New to it? Read [what is Model Context Protocol](/blog/what-is-model-context-protocol) first. Here is the mental model. **The MCP server exposes tools; the AI model decides which to call.** Your prompt sets the goal. Say you connect a GitHub MCP server. You type _"list my open pull requests."_ The model picks the right tool and runs it. **No code means you never touch the tool schema yourself.** The server publishes it, the model reads it, you just chat. That is the whole shift. For a deeper take on the moving parts, see [what is an MCP agent](/blog/what-is-mcp-agent-tool-calling). ## What You Need to Build an MCP Agent (No Code) Almost nothing. That is the point of a **browser-based, no-code agent**. Here is the full checklist: - A **free MCP Playground account** — sign in and you are in the studio - An **MCP server URL** — or use a hosted one / template if you have none - An **access token**, only if that server needs one (many public ones do not) **No local runtime. No SDK. No config file.** The model, the tools, and the trace all run in the browser. If you have ever tested an endpoint in Postman, this will feel familiar. Same idea — for AI agents. Ready? [Open MCP Agent Studio](/mcp-agent-studio) and follow along. ## Build Your First MCP Agent in 4 Steps (No Code) The studio opens the walkthrough automatically on your first visit. Here are the same four steps, in order. ### Step 1 — Connect an MCP Server **Paste your MCP server URL into the connection field.** Any Streamable HTTP or SSE endpoint works. If the server needs auth, drop the _access token_ in the field beside the URL. Public servers skip this. No URL of your own? The next section covers three one-click ways to get one. ### Step 2 — Type Your First Message **Tell the agent what you want in plain English.** Start simple — _"list the available tools"_ is a perfect first prompt. The model reads the server's tools and decides which to call. You never name a function yourself. ### Step 3 — Pick a Model **Open the model selector and choose one of 70+ models** — Claude, GPT, Gemini, and more. Each shows its credit cost per prompt. For a first run, a fast, cheap model like **Claude Haiku 4.5** is plenty. Not sure which? See the [best model for MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling). ### Step 4 — Send and Watch the Tools Run **Hit send — or press Enter — and watch the tool calls stream in live.** Click any call to inspect its exact input and output. That trace is how you learn what your agent actually did. Three things happen, in order: 1. **Connect** the MCP server URL (plus token if needed) 2. **Pick** a model and type your goal 3. **Send**, then inspect every tool call Want the wider tour of the interface? The [MCP Agent Studio guide](/blog/mcp-agent-studio-guide) goes deeper. ## No Server URL? Three Ways to Start (Still No Code) This is where most beginners stall — **"I do not have an MCP server to connect."** You do not need to build one. The studio gives you three no-code paths, all inside the connection bar. **1\. Browse the registry.** Click _Browse_ and pick a server from the [public MCP registry](/mcp-servers). The URL fills in for you. **2\. Spin up a hosted server.** Click _Hosted_ to deploy one from the [hosted MCP catalog](/mcp-hosted) — GitHub, Playwright, Airtable, and more — in one click. **3\. Load a template.** Templates come pre-wired with a server, a model, and a system prompt. You just add your token and chat. Every path ends the same way: a live server URL sitting in the studio, ready to run. Want to poke at a server before you commit? [Test any MCP server free](/mcp-test-server) and see its tools first. ## A Real Example: Your First MCP Agent in 60 Seconds Let me make this concrete with a **public, no-token server** so you can follow along right now. Use the [DeepWiki](https://deepwiki.com) MCP server — it answers questions about any public GitHub repo. Here is the 60-second run: 1. Paste `https://mcp.deepwiki.com/mcp` into the connection field 2. Leave the token blank — it is public 3. Pick a fast model like **Claude Haiku 4.5** 4. Type _"What does the modelcontextprotocol/servers repo do?"_ and send **The agent calls DeepWiki's tools and answers from the live repo** — not from stale training data. You just built a working MCP agent. Swap in your own server URL and the loop is identical. That is the whole no-code workflow. ## Common First-Agent Mistakes (and Fixes) Your first agent will hit one of these. Here is how I unstick each one. **"Nothing happened when I sent a message."** You likely skipped the URL. The studio needs a connected server before it will run. **"The server returned 401 or 403."** That server needs a token. Paste your access token in the field next to the URL. **"The model did not call any tools."** Make the goal explicit. _"List the available tools"_ beats a vague _"help me."_ **"It picked the wrong tool."** Try a stronger model. Reasoning quality drives tool selection — see [how to test an AI agent with MCP](/blog/how-to-test-ai-agent-with-mcp). **"My server URL will not connect."** Check the transport. Most modern servers use Streamable HTTP; older ones use SSE. The [test-online guide](/blog/how-to-test-mcp-server-online-no-setup-required) covers this. ## How MCP Playground Helps You Build Agents Online **[MCP Agent Studio](/mcp-agent-studio) is the no-code path from zero to a working agent.** Everything runs in the browser. Connect any MCP server, pick from 70+ models, and watch every tool call in real time. No install, no API key wrangling. When your agent works, **save it and reuse it** — or export it as a callable API. The hosted catalog hands you a live server URL in one click. ## Frequently Asked Questions **Can I build an AI agent without coding?** Yes. In MCP Agent Studio you connect an MCP server, pick a model, and chat — no code, no install, right in the browser. **What is the fastest way to build my first MCP agent?** Open the studio, paste a public server URL like DeepWiki, pick a fast model, and send a prompt. Under a minute, start to finish. **Do I need my own MCP server?** No. Browse the registry, spin up a hosted server, or load a template — each gives you a ready URL with no setup. ## Conclusion **Building a no-code AI agent is a four-step loop** — connect a server, type a message, pick a model, send. The browser does the rest. The fastest way to learn it is to run one. [Test any MCP server free](/mcp-test-server), then build your first agent in the studio. ## Frequently asked questions ### Can I build an AI agent without coding? Yes. MCP Agent Studio lets you build a no-code AI agent in the browser. You connect an MCP server by pasting its URL, pick one of 70+ models, and chat in plain English. The model reads the server tools and calls them for you — no install, no SDK, no config file. ### What is the fastest way to build my first MCP agent? Open MCP Agent Studio, paste a public MCP server URL such as https://mcp.deepwiki.com/mcp, leave the token blank, pick a fast model like Claude Haiku 4.5, and send a prompt. You will have a working MCP agent that calls live tools in under a minute. ### Do I need my own MCP server to build an agent? No. If you do not have a server URL, you can browse the public MCP registry, spin up a hosted server from the catalog in one click, or load a pre-wired template. Each option fills the connection for you so you can start chatting right away. ### Is building an MCP agent online free? Yes. MCP Playground is free to start and runs entirely in the browser. You get a free account, connect any MCP server, and test agents across 70+ models with no local setup and no credit card required. --- _Canonical page: https://mcpplaygroundonline.com/blog/build-first-mcp-agent-no-code — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Claude Fable 5 + MCP Servers: Building Smarter Agents in 2026 > Pair Claude Fable 5 with MCP servers to run reliable multi-tool agents. Setup, model comparison, and practical tips — test free in your browser. **Source:** https://mcpplaygroundonline.com/blog/claude-fable-5-mcp-servers **Author:** Nikhil Tiwari **Published:** 2026-07-05 **Category:** Development **Reading time:** 9 min read --- 📖 TL;DR - **Claude Fable 5** is the flagship of the Claude 5 family — built to reason across many MCP tools without dropping the plot. - Connect any MCP server in [MCP Playground Agent Studio](/mcp-agent-studio), pick _Claude Fable_ from the model list, and chat. - Use **Sonnet 5** for everyday runs; save **Fable 5** for hard, multi-step, multi-server agents where a wrong tool call is expensive. _Model Context Protocol_ turned every API into a tool an AI can call. But the tool is only half the story. The **model driving those tools decides whether your agent ships or stalls**. That is where Claude Fable 5 comes in. I have been running **Claude Fable 5 against MCP servers** all week — across GitHub, Todoist, Postgres, and multi-server setups. This post is what I would tell a teammate: what Fable 5 is, why it pairs so well with MCP, and how to wire it up in minutes. You will also see **when Fable 5 is overkill** — and when a cheaper model wins. Pick wrong and you either burn budget or miss tool calls. ## What Is Claude Fable 5? **Claude Fable 5 is the top-tier model in the Claude 5 family.** Think of it as the flagship above Sonnet 5 — the one you reach for when reasoning cannot slip. It is built for _reasoning_ — the slow, careful kind that agents need. Not just fast chat replies. In [MCP Playground](/mcp-agent-studio), Fable 5 sits in the **frontier tier**. It is the most capable option, and the priciest per run. That pricing tells you the intent. You **spend Fable 5 on tasks where a wrong tool call costs more than the model does**. Where it shines: - **Long, multi-step tool chains** that would confuse a smaller model - **Ambiguous instructions** that need real planning before acting - **Multi-server agents** juggling GitHub, a database, and Slack at once New to the protocol itself? Start with [what is Model Context Protocol](/blog/what-is-model-context-protocol), then come back. ## Why Pair Fable 5 With MCP Servers? Here is the problem. **MCP gives a model dozens of tools — and dozens of ways to pick the wrong one.** A weak model calls `delete_task` when you meant `complete_task`. Or forgets a required argument. Or loops. That is the frustration every agent builder feels. **The tools work; the reasoning wobbles.** Your demo passes, then production drifts. **Fable 5 fixes the reasoning half.** It reads a tool schema, plans the sequence, and fills arguments with fewer misses. I saw this clearly on a **multi-server MCP agent** — GitHub plus Postgres plus Slack, one prompt. Smaller models grabbed the first plausible tool. Fable 5 paused, checked the schema, then chained three calls in the right order. That difference matters most on _write_ actions. Creating an issue, running SQL, sending a message — **you do not get a second try**. Want to see tool selection live before you trust it? [Test any MCP server free](/mcp-test-server) and watch each call in the browser. For the deeper contrast between tools and plain function calls, read [MCP vs function calling vs API](/blog/mcp-vs-function-calling-vs-api-comparison). ## How to Use Fable 5 With MCP Servers (Step by Step) You do not need a local setup. The whole loop runs in the browser. Here is the flow I use in [MCP Playground Agent Studio](/mcp-agent-studio). ### Connect a Remote or Hosted MCP Server **Paste your MCP server URL** into the connection field. Any streamable-HTTP or SSE endpoint works. No server yet? Deploy one in a click from the [hosted MCP catalog](/mcp-hosted) — GitHub, Todoist, Airtable, and more. Each hosted server gives you a **live URL you drop straight into the studio**. Then add your access token. Bringing a remote endpoint? This guide on [remote MCP servers](/blog/remote-mcp-servers) covers the transport details. ### Switch the Model to Claude Fable Open the **model selector** and choose _Claude Fable_. That is it — the agent now reasons with Fable 5. Send a prompt like _"list my open GitHub PRs and flag the stale ones."_ Watch the tool calls stream in the panel. **Every call shows its input and output.** So you can confirm Fable 5 picked the right tool with the right arguments. Three steps, start to finish: 1. **Connect** the MCP server URL (plus token) 2. **Select** Claude Fable in the model dropdown 3. **Chat** and inspect each tool call New to Agent Studio? The [Claude MCP apps guide](/blog/claude-mcp-apps-full-guide) walks through the wider workflow. ## Fable 5 vs Sonnet 5 vs Opus 4.8 for MCP Agents **Fable 5 is not always the right call.** The full Claude lineup is in the studio, and each model has a lane. Here is how I split them for MCP work: Model Best for When I skip it **Claude Fable 5** Hard multi-step, multi-server agents; write actions Simple, single-tool reads **Claude Sonnet 5** Everyday agents; most templates Plans that span 5+ tool calls **Claude Opus 4.8** Deep code reasoning, long context Quick automation tasks **Claude Haiku 4.5** Fast, cheap lookups; listing tools Anything needing real planning My rule of thumb: **start on Sonnet 5, escalate to Fable 5 when the agent misses steps.** Do not guess — **run the same prompt on two models side by side**. The studio's compare view makes this a 30-second test. For a broader framing of the tradeoff, see [MCP vs REST API: what's different](/blog/mcp-vs-rest-api-whats-different). ## Best MCP Servers to Run With Fable 5 Fable 5 earns its cost on **servers with many tools and real consequences**. Here are the ones I reach for. - **GitHub MCP** — reviewing PRs and chaining commits needs planning. See [10 things you can do with the GitHub MCP server](/blog/10-things-you-can-do-with-github-mcp-server). - **Postgres MCP** — natural-language SQL where a bad query is expensive. Recipe: [Postgres MCP analytics agent](/blog/postgres-mcp-claude-analytics-agent-recipe). - **Multi-server combos** — GitHub + Linear + Slack in one conversation. This is where **Fable 5 pulls ahead hardest**. The pattern is simple. **More tools plus write access equals more reason to run Fable 5.** For single-tool reads — a weather lookup, a doc fetch — a Haiku or Sonnet run is plenty. **Match the model to the blast radius.** Browsing for ideas? The [awesome MCP servers list](/blog/awesome-mcp-servers) has 70+ tested options to point Fable 5 at. ## Getting Reliable Tool Calls From Fable 5 Even a flagship model needs a clean setup. **Most "the agent broke" moments are really schema or prompt problems.** Here is what keeps Fable 5 reliable in my runs: - **Write tight tool descriptions.** Fable 5 reads them literally — vague descriptions cause vague calls. - **Mark required arguments clearly.** Ambiguous schemas are where even strong models slip. - **Confirm before write actions.** Ask the agent to state the exact change first. - **Watch the tool panel.** If an input looks wrong, fix the prompt, not the model. A subtle one: **the server, not the model, returns most errors you will see.** A 410 or 401 in a tool output is the API talking, not Fable 5. When calls fail, this [MCP server troubleshooting guide](/blog/mcp-server-troubleshooting-common-errors-fix) maps the common ones fast. And before you point any agent at a production server, **scan it**. [Scan your MCP server](/mcp-security-scanner) for tool-poisoning and injection risks first. ## How MCP Playground Helps **MCP Playground is where I test all of this without installing anything.** It runs in the browser, free. Connect any MCP server, pick _Claude Fable_ or any of 70+ models, and watch every tool call in real time. The **compare view** lets me A/B Fable 5 against Sonnet 5 on the same prompt. So I only spend the frontier model where it earns its keep. And the [hosted MCP catalog](/mcp-hosted) gives me a live server URL in one click — no infra to babysit. ## Frequently Asked Questions **Is Claude Fable 5 good for MCP agents?** Yes — it is the flagship Claude 5 model, tuned for reasoning across many tools. It shines on multi-step, multi-server agents where a wrong tool call is costly. **How do I use Claude Fable 5 with an MCP server?** Open MCP Playground Agent Studio, paste your MCP server URL and token, choose _Claude Fable_ in the model list, and chat. Every tool call is shown live. **Fable 5 or Sonnet 5 for MCP?** Start on Sonnet 5 for everyday runs. Escalate to Fable 5 when the agent misses steps or the task chains many tools with write access. ## Conclusion **Claude Fable 5 is the model you save for the hard MCP agents** — multi-step, multi-server, write-heavy work where reasoning cannot wobble. For everyday runs, Sonnet 5 does the job cheaper. The fastest way to feel the difference is to try both on your own MCP server. [Test any MCP server free](/mcp-test-server) and switch models mid-chat to see which one holds the plan. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work, why the same server behaves differently per model, and what to measure. Other guides in this series: [DeepSeek V4](/blog/testing-mcp-with-deepseek), [Qwen](/blog/test-mcp-server-with-qwen-models), [Gemini](/blog/test-mcp-server-with-gemini-models), [GLM](/blog/test-mcp-server-with-glm-models), [GLM 5.3](/blog/glm-5-3-mcp-servers), [Grok](/blog/testing-mcp-with-grok-xai), [Kimi K2.6](/blog/test-mcp-server-with-kimi-k2-6), [Fable 5.1 vs GPT-6 Astra](/blog/fable-5-1-vs-gpt-6-astra-mcp). ## Frequently asked questions ### Is Claude Fable 5 good for MCP agents? Yes. Claude Fable 5 is the flagship model in the Claude 5 family, tuned for reasoning across many tools. It shines on multi-step, multi-server MCP agents where a wrong tool call is costly. For simple single-tool reads, a cheaper model like Sonnet 5 or Haiku 4.5 is usually enough. ### How do I use Claude Fable 5 with an MCP server? Open MCP Playground Agent Studio in your browser, paste your MCP server URL and access token, choose Claude Fable in the model selector, and send a prompt. Each tool call is shown live with its input and output, so you can confirm the model picked the right tool. ### Should I use Fable 5 or Sonnet 5 for MCP? Start on Sonnet 5 for everyday agents and most templates. Escalate to Fable 5 when the agent misses steps, the task chains five or more tool calls, or it performs write actions where mistakes are expensive. Use the compare view to A/B both on the same prompt. ### Where can I test Claude Fable 5 with MCP servers? MCP Playground lets you connect any MCP server, pick Claude Fable or any of 70+ models, and watch every tool call in real time — free and in the browser, with no local setup. --- _Canonical page: https://mcpplaygroundonline.com/blog/claude-fable-5-mcp-servers — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # n8n MCP Server: Connect n8n to Claude and AI Agents (2026 Guide) > n8n speaks MCP in both directions: expose a workflow as an MCP server so Claude can call it, or let an n8n AI Agent call external MCP servers as tools. Here is how each node works, how to wire it to Claude, and how to test it before you ship. **Source:** https://mcpplaygroundonline.com/blog/n8n-mcp-server-guide **Author:** Nikhil Tiwari **Published:** 2026-06-30 **Updated:** 2026-06-30 **Category:** Guide **Reading time:** 11 min read --- 📖 TL;DR - n8n speaks MCP **two ways**: as a server (expose a workflow as tools) and as a client (an AI Agent that calls other MCP servers). - The **MCP Server Trigger** node turns any workflow into an MCP endpoint Claude or Cursor can connect to. - The **MCP Client Tool** node plugs external MCP servers into an n8n _AI Agent_ node as callable tools. - You expose tools by wiring normal n8n nodes (HTTP Request, Postgres, Slack…) into the MCP Server Trigger. - Test the endpoint against a real model **before** you connect it to anything in production. Table of Contents 1. [What Is the n8n MCP Server?](#what-is) 2. [Two Directions](#two-directions) 3. [n8n as an MCP Server](#server-trigger) 4. [n8n as an MCP Client](#client-tool) 5. [Expose a Workflow Step by Step](#step-by-step) 6. [Connect It to Claude](#connect-claude) 7. [Test Before You Connect](#test-first) 8. [Common Errors & Fixes](#errors) 9. [n8n vs a Custom Server](#when-to-use) 10. [FAQ](#faq) ## What Is the n8n MCP Server? **n8n is a workflow automation tool that now speaks the Model Context Protocol natively.** That means an AI agent like Claude can call your n8n workflows the same way it calls any other MCP tool. Before this existed, connecting n8n to an LLM meant webhooks and custom glue. You wrote an endpoint, described it by hand, and hoped the model called it right. MCP removes that friction. n8n exposes a standard, self-describing tool surface, and any MCP client discovers it automatically. If MCP itself is new to you, read [What Is the Model Context Protocol?](/blog/what-is-model-context-protocol) first — this guide assumes you know what a tool call is. n8n ships **two dedicated MCP nodes**, and most confusion comes from mixing them up. Let me draw the line clearly. ## Two Directions: Server vs Client n8n can sit on _either_ side of an MCP connection. Which node you reach for depends on who is calling whom. Node Role Use it when… **MCP Server Trigger** n8n _is_ the server You want Claude/Cursor to call your n8n workflow as a tool **MCP Client Tool** n8n _is_ the client You want an n8n AI Agent to call an external MCP server **MCP Server Trigger** = n8n exposes tools outward. **MCP Client Tool** = n8n consumes tools from elsewhere. That single distinction unlocks the rest of this guide. ## n8n as an MCP Server (MCP Server Trigger) The **MCP Server Trigger** node turns a workflow into a live MCP endpoint. Drop the node onto a canvas and it gives you a URL — a Streamable HTTP / SSE endpoint that any MCP client can connect to. You decide what tools that endpoint exposes by **wiring regular n8n nodes into the trigger**. An HTTP Request node becomes a tool. A Postgres node becomes a tool. A Slack node becomes a tool. Each connected node shows up in the client's `tools/list` response, with its parameters described as a JSON schema the model can reason over. So you are not writing protocol code. You are dragging the same nodes you already use in n8n, and the trigger handles the MCP plumbing. **Watch the tool descriptions.** The model picks tools based on their names and descriptions. A node labelled "HTTP Request1" tells Claude nothing. Rename it to something like "create\_invoice" with a clear description. ## n8n as an MCP Client (MCP Client Tool) The **MCP Client Tool** node does the opposite. It lets an n8n _AI Agent_ node call tools that live on an external MCP server. Say you built an AI Agent workflow in n8n and you want it to use the GitHub MCP server. You add an MCP Client Tool node, point it at the GitHub MCP endpoint, and the agent can now call those tools. This is how you give an n8n agent superpowers it does not natively have — databases, browsers, third-party APIs — without building each integration yourself. For the orchestration patterns behind multi-tool agents, see [multi-agent MCP with CrewAI and LangChain](/blog/multi-agent-mcp-crewai-langchain-guide) and [how MCP tool calling works](/blog/what-is-mcp-agent-tool-calling). ## Step by Step: Expose an n8n Workflow as an MCP Server Here is the shortest path from blank canvas to a working MCP endpoint. 1. Create a new workflow and add the **MCP Server Trigger** node. 2. Copy the **MCP URL** it generates — this is the endpoint clients connect to. 3. Add a tool node (e.g. **HTTP Request** or **Postgres**) and connect it to the trigger's tool output. 4. Give the tool node a **clear name and description** — this is what the model sees. 5. Turn on **Bearer auth** on the trigger and save the token somewhere safe. 6. **Activate** the workflow. An inactive workflow will not serve MCP requests. That last step trips up everyone once. **The MCP Server Trigger only responds when the workflow is active** — a saved-but-inactive workflow returns nothing. 💡 Before you paste that URL into Claude, confirm the endpoint actually lists your tools. [Test your n8n MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) ## Connect Your n8n MCP Server to Claude Once the endpoint is live, connecting Claude is a config edit. For **Claude Desktop**, add your n8n endpoint to the MCP config file. Remote HTTP servers go under `mcpServers` with the URL and your bearer token: ``` { "mcpServers": { "n8n": { "url": "https://your-n8n-host/mcp/your-workflow-id/sse", "headers": { "Authorization": "Bearer YOUR_TOKEN" } } } } ``` Restart Claude Desktop and your n8n tools appear in the tool list. For the full config-file walkthrough across clients, see [the MCP config files guide](/blog/complete-guide-mcp-config-files-claude-desktop-cursor-lovable) and [how to set up MCP in Claude Desktop](/blog/how-to-setup-mcp-claude-desktop). Using Cursor instead? The flow is nearly identical — drop the same URL into Cursor's MCP settings ([Cursor MCP setup guide](/blog/cursor-mcp-setup-guide)). ## Test Your n8n MCP Server Before You Connect It **Problem:** you wire up the workflow, paste the URL into Claude, and the model either ignores your tool or calls it with the wrong arguments. That wastes time, because you are debugging two systems at once — n8n and the client — with no visibility into either. **The fix is to test the endpoint in isolation first.** Open the URL in a browser-based MCP tester, watch `tools/list` return your tools, and call one by hand. If the tool names and schemas look right there, the problem is your client config. If they look wrong, the problem is your n8n wiring. You just halved the debugging surface. Shipping an n8n MCP workflow? Paste your endpoint into the browser, watch a real model discover and call your tools, and catch schema bugs before Claude ever sees them. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Chat with it in Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio) ## Common n8n MCP Errors & Fixes The same handful of problems account for most failed connections. - **Client connects but sees no tools:** the workflow is not _active_, or no tool nodes are wired into the trigger. - **401 / Unauthorized:** the bearer token in your client config does not match the trigger's token. - **Model never calls the tool:** vague tool names or empty descriptions — rename them so the intent is obvious. - **Tool runs but returns nothing useful:** the connected node returns raw data the model cannot parse; shape the output to plain text or clean JSON. - **Works locally, fails when remote:** your n8n instance is not reachable over HTTPS, or a proxy is stripping the SSE connection. For a broader checklist, see [MCP server troubleshooting](/blog/mcp-server-troubleshooting-common-errors-fix). ## n8n MCP vs Building a Custom MCP Server n8n is not always the right tool. Pick based on what you are building. ### Use the n8n MCP Server when… - The logic is already a workflow — approvals, data syncs, notifications. - You want non-developers to edit what the agent can do. - You need a dozen integrations stitched together fast, with no SDK code. ### Build a custom MCP server when… - You need fine control over tool schemas, errors, and streaming. - The server is a product surface, not an internal automation. - Performance and versioning matter more than drag-and-drop speed. If you land on the custom route, start with [the Node.js MCP server guide](/blog/build-custom-mcp-server-using-nodejs-simple-guide) or [the Python FastMCP tutorial](/blog/build-mcp-server-python-fastmcp-tutorial). You can also wrap your existing API — see [wrapping APIs as MCP tools](/blog/wrap-existing-apis-as-mcp-tools-simple-guide). Already automate with Zapier? The same idea applies there — compare with [Zapier MCP for Claude](/blog/zapier-mcp-claude-automations-guide). ## Frequently Asked Questions **What is the difference between the MCP Server Trigger and MCP Client Tool in n8n?+** The MCP Server Trigger makes n8n a server: it exposes your workflow's nodes as tools that an external client like Claude can call. The MCP Client Tool does the reverse: it lets an n8n AI Agent node call tools hosted on an external MCP server. One serves tools out, the other consumes tools in. **Can Claude call an n8n workflow directly?+** Yes. Add an MCP Server Trigger to the workflow, activate it, and add its URL and bearer token to Claude's MCP config. Claude then discovers the workflow's tools and can call them like any other MCP tool. **Why does my n8n MCP server return no tools?+** The most common cause is an inactive workflow — the MCP Server Trigger only responds when the workflow is active. The second most common cause is having no tool nodes wired into the trigger's tool output. Activate the workflow and connect at least one tool node. **Do I need to self-host n8n to use MCP?+** No. Both the self-hosted and cloud versions of n8n support the MCP nodes. Self-hosting gives you more control over networking and the endpoint URL, which can matter when exposing the server to remote clients over HTTPS. **How do I test an n8n MCP server before connecting it to Claude?+** Paste the MCP Server Trigger URL (with its bearer token) into a browser-based MCP tester. Confirm tools/list returns your tools with sensible names and schemas, then call one manually. If that works, any remaining issue is in your client config rather than n8n. ## Related Guides - [What Is the Model Context Protocol (MCP)?](/blog/what-is-model-context-protocol) - [Zapier MCP for Claude — Automations Guide](/blog/zapier-mcp-claude-automations-guide) - [Wrap Existing APIs as MCP Tools](/blog/wrap-existing-apis-as-mcp-tools-simple-guide) - [The Complete Guide to MCP Config Files](/blog/complete-guide-mcp-config-files-claude-desktop-cursor-lovable) - [MCP Server Troubleshooting — Common Errors](/blog/mcp-server-troubleshooting-common-errors-fix) ## Further Reading - [n8n Docs: MCP Server Trigger node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger/) - [n8n Docs: MCP Client Tool node](https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.toolmcp/) - [Official: MCP Specification](https://modelcontextprotocol.io/specification) - [Official: MCP Transports](https://modelcontextprotocol.io/docs/concepts/transports) 🤖 Test your n8n workflow against a live AI model Before Claude depends on your workflow, make sure the tools actually fire. Use [MCP Agent Studio](/mcp-agent-studio) to chat with your n8n MCP server and watch a real model call its tools. Works with Claude, GPT, Gemini and more. Free credits on sign-up. ## Frequently asked questions ### What is the difference between the MCP Server Trigger and MCP Client Tool in n8n? The MCP Server Trigger makes n8n a server: it exposes your workflow nodes as tools an external client like Claude can call. The MCP Client Tool does the reverse: it lets an n8n AI Agent node call tools hosted on an external MCP server. One serves tools out, the other consumes tools in. ### Can Claude call an n8n workflow directly? Yes. Add an MCP Server Trigger to the workflow, activate it, and add its URL and bearer token to Claude MCP config. Claude then discovers the workflow tools and can call them like any other MCP tool. ### Why does my n8n MCP server return no tools? The most common cause is an inactive workflow — the MCP Server Trigger only responds when the workflow is active. The second is having no tool nodes wired into the trigger output. Activate the workflow and connect at least one tool node. ### Do I need to self-host n8n to use MCP? No. Both the self-hosted and cloud versions of n8n support the MCP nodes. Self-hosting gives you more control over networking and the endpoint URL, which can matter when exposing the server to remote clients over HTTPS. ### How do I test an n8n MCP server before connecting it to Claude? Paste the MCP Server Trigger URL with its bearer token into a browser-based MCP tester. Confirm tools/list returns your tools with sensible names and schemas, then call one manually. If that works, any remaining issue is in your client config rather than n8n. --- _Canonical page: https://mcpplaygroundonline.com/blog/n8n-mcp-server-guide — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # MCP vs A2A: Model Context Protocol vs Agent2Agent (2026 Guide) > MCP and A2A solve different problems. MCP connects an agent to tools and data; A2A lets agents talk to each other. Learn how Model Context Protocol and Agent2Agent differ, when to use each, and why most real agent stacks end up using both. **Source:** https://mcpplaygroundonline.com/blog/mcp-vs-a2a-agent2agent-protocol **Author:** Nikhil Tiwari **Published:** 2026-06-26 **Updated:** 2026-06-26 **Category:** Comparison **Reading time:** 11 min read --- 📖 TL;DR - **MCP (Model Context Protocol)** connects one agent to tools, data, and APIs — a vertical link from agent down to capabilities. - **A2A (Agent2Agent)** connects agents to other agents — a horizontal link so independent agents can delegate work. - MCP is from Anthropic; A2A started at Google and is now a Linux Foundation project. They are **complementary, not competitors**. - Use MCP to give an agent its toolbox. Use A2A to let that agent hire other agents. - Most production stacks in 2026 run **both**: A2A between agents, MCP from each agent to its tools. Table of Contents 1. [The Key Difference](#key-difference) 2. [What Is MCP?](#what-is-mcp) 3. [What Is A2A?](#what-is-a2a) 4. [Side-by-Side](#side-by-side) 5. [Architecture & Transport](#architecture) 6. [Discovery: Tools vs Agent Card](#discovery) 7. [When to Use Each](#when-to-use) 8. [Using Both Together](#use-both) 9. [FAQ](#faq) ## The Key Difference in One Sentence **MCP connects an agent to its tools. A2A connects an agent to other agents.** That is the whole comparison in a line. The two protocols sit on different axes of the same system. _MCP_ is **vertical**: it runs from a single agent down to the tools, files, and APIs it can call. Think of it as the agent's toolbox. _A2A_ is **horizontal**: it runs sideways, between peer agents that each have their own tools and reasoning. Think of it as agents hiring each other. So "MCP vs A2A" is rarely an either/or pick. Once you understand the axes, the question becomes **where each one belongs in your stack** — which is what the rest of this guide covers. ## What Is MCP (Model Context Protocol)? **MCP is an open standard from Anthropic, released in November 2024, for connecting AI models to external systems.** An MCP server exposes three things to a model: _tools_ (functions the model can call), _resources_ (data it can read), and _prompts_ (reusable templates). The model is the client. It discovers what a server offers, picks a tool, and calls it with arguments — all over JSON-RPC 2.0. The point is to kill custom glue code. Instead of writing a one-off integration for every API, you expose a standard MCP surface once and any MCP-aware client can use it. If you are new to it, start with [What Is the Model Context Protocol?](/blog/what-is-model-context-protocol) and [how MCP tool calling works](/blog/what-is-mcp-agent-tool-calling). MCP answers one question: **how does this agent reach the outside world?** Files, databases, GitHub, Slack, your own REST API — all of it becomes callable through a single protocol. ## What Is A2A (Agent2Agent)? **A2A is an open protocol for agent-to-agent communication.** Google announced it in April 2025 and donated it to the Linux Foundation in June 2025, with backing from 50+ partners. MCP assumes the client is a model talking to tools. A2A assumes both sides are _full agents_ — each with its own model, memory, and tools. A2A lets a "client agent" hand a task to a "remote agent" and get results back, without either side exposing its internal logic. That last part matters. A2A agents are **opaque** — they collaborate as black boxes. The client agent does not see the remote agent's tools or prompts, only the task and its output. The core building blocks are the _Agent Card_ (a public capability profile), _Tasks_ (units of work with a lifecycle), _Messages_, and _Artifacts_ (the results a task produces). A real example: a hiring agent asks a sourcing agent to find candidates, then asks a scheduling agent to book interviews. Three separate agents, possibly three vendors, coordinating over A2A. A2A answers a different question than MCP: **how do independent agents delegate work to each other?** ## MCP vs A2A: Side-by-Side Comparison MCP A2A **Connects** Agent → tools & data Agent ↔ agent **Axis** Vertical (down to capabilities) Horizontal (across peers) **Origin** Anthropic (Nov 2024) Google → Linux Foundation (2025) **Unit of work** Tool call Task (with a lifecycle) **Discovery** tools/list, resources/list Agent Card (JSON profile) **Other side is** A concrete tool surface An opaque, autonomous agent **Transport** JSON-RPC 2.0 over STDIO or Streamable HTTP JSON-RPC 2.0 over HTTP(S), SSE, webhooks **Best for** Giving one agent capabilities Coordinating many agents The rows that matter most are the first two. **Everything else follows from "agent-to-tool" versus "agent-to-agent".** ## MCP vs A2A: Architecture and Transport Both protocols speak **JSON-RPC 2.0**, so the wire format feels familiar across the two. The shape of what they exchange is where they split. ### MCP architecture An MCP host (like Claude Desktop) runs one or more MCP clients. Each client holds a session with one MCP server. Transport is either _STDIO_ for local servers or _Streamable HTTP_ for remote ones. The exchange is request/response: list tools, call a tool, get a result. For a deeper protocol breakdown, see [MCP vs REST API](/blog/mcp-vs-rest-api-whats-different) and [MCP vs function calling](/blog/mcp-vs-function-calling-vs-api-comparison). ### A2A architecture A2A has a _client agent_ and a _remote agent_, both running as HTTP services. The client sends a task; the remote agent works it and returns artifacts. Because agent tasks can be long-running, A2A leans on **Server-Sent Events for streaming** and webhook push notifications for updates that arrive minutes — or hours — later. A task moves through states: _submitted_, _working_, _input-required_, _completed_, _failed_, or _canceled_. That lifecycle is something MCP's single tool call does not model. **Key nuance:** MCP optimizes for a fast, synchronous tool call. A2A optimizes for a delegated task that may take a while and report back asynchronously. The transport choices flow directly from that. ## Discovery: tools/list vs the Agent Card Discovery is the cleanest way to feel the difference between the two protocols. **In MCP, a client asks a server "what can you do?" by calling `tools/list`.** It gets back concrete tools with names, descriptions, and JSON input schemas. The model then reasons over that list and calls a specific tool. The server's capabilities are _transparent_ by design. **In A2A, discovery happens through the Agent Card** — a JSON document an agent publishes at a well-known URL (typically `/.well-known/agent-card.json`). The Agent Card describes the agent's skills, endpoint, auth requirements, and supported modes — but not its internal tools. A client agent reads the card to decide _whether to delegate_, not _which function to invoke_. So MCP discovery says "here are my functions." A2A discovery says "here is what I can take on." One exposes a toolbox; the other advertises a hire-able specialist. When you build an MCP server, that `tools/list` response is the contract a model depends on. Vague names or weak schemas quietly break tool selection. 💡 The fastest way to check that contract is to run your server against a real model and watch which tools it picks. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) ## When to Use MCP vs A2A Pick based on what is on the other end of the connection. ### Reach for MCP when… - You want one agent to read a database, hit an API, or touch the filesystem. - The capability is a **function**, not an autonomous actor. - You need fast, synchronous calls with structured inputs and outputs. - You are wrapping your own services so any MCP client can use them. ### Reach for A2A when… - You have **multiple agents** that should delegate work to each other. - Those agents are built on different frameworks or owned by different teams or vendors. - A unit of work is a long-running _task_, not a single call. - You want agents to collaborate without exposing each other's internals. A quick gut check: if the thing you are connecting to **cannot reason on its own**, it is an MCP tool. If it **can**, it is an A2A agent. Building a multi-agent system today? Pair this with [multi-agent MCP with CrewAI and LangChain](/blog/multi-agent-mcp-crewai-langchain-guide) for the orchestration side. ## Why You'll Often Use Both Together The framing "MCP vs A2A" sells the wrong story. In real systems, **they stack**. Google said as much when it launched A2A: it is positioned as _complementary_ to MCP, not a replacement. Here is the mental model. **A2A is how agents coordinate. MCP is how each agent gets work done.** Walk through one task. A user asks a "travel planner" agent to book a trip. 1. The planner agent uses **A2A** to delegate flights to a flight agent and hotels to a hotel agent. 2. The flight agent uses **MCP** to call an airline API and a payments tool. 3. The hotel agent uses **MCP** to query a booking database and a maps service. 4. Results flow back over A2A as artifacts, and the planner assembles the itinerary. A2A handles the conversation between agents. MCP handles each agent's grip on the real world. Remove either and the system stops working. That is why I treat them as **two layers of the same architecture**, not rival standards. Most serious agent platforms in 2026 ship support for both. Building the MCP layer of your agent stack? Test your MCP server against real models in the browser before any agent — or any other agent — depends on it. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Chat with your server in Agent Studio](https://mcpplaygroundonline.com/mcp-agent-studio) ## Frequently Asked Questions **Does A2A replace MCP?+** No. They operate on different axes. MCP connects an agent to tools and data; A2A connects agents to each other. Google explicitly positions A2A as complementary to MCP, and most agent stacks use both. **Who created MCP and A2A?+** Anthropic released MCP in November 2024. Google announced A2A in April 2025 and donated it to the Linux Foundation in June 2025, where it is now a vendor-neutral open project. **What is an Agent Card in A2A?+** An Agent Card is a JSON document an agent publishes at a well-known URL describing its skills, endpoint, and auth requirements. Other agents read it to decide whether to delegate a task — it is A2A's discovery mechanism, similar in spirit to MCP's tools/list. **Can I use MCP and A2A in the same system?+** Yes, and most production systems do. A2A handles coordination between agents while each agent uses MCP to call its own tools and data sources. They form two layers of one architecture rather than competing choices. **Is A2A the same as multi-agent frameworks like CrewAI?+** Not quite. Frameworks like CrewAI or LangGraph orchestrate agents inside one application. A2A is an open wire protocol for agents to communicate across frameworks, teams, and vendors — including agents the framework did not build. ## Related Guides - [What Is the Model Context Protocol (MCP)? A Developer's Guide](/blog/what-is-model-context-protocol) - [MCP vs REST API — What's Different?](/blog/mcp-vs-rest-api-whats-different) - [MCP vs Function Calling vs API](/blog/mcp-vs-function-calling-vs-api-comparison) - [Multi-Agent MCP with CrewAI and LangChain](/blog/multi-agent-mcp-crewai-langchain-guide) - [What Is an MCP Agent? Tool Calling Explained](/blog/what-is-mcp-agent-tool-calling) - [Agent Skills vs MCP vs Function Calling vs A2A](/blog/agent-skills-vs-mcp) ## Further Reading - [Official: MCP Specification](https://modelcontextprotocol.io/specification) - [Official: MCP Transports](https://modelcontextprotocol.io/docs/concepts/transports) - [Official: A2A Protocol Docs](https://a2a-protocol.org/) - [A2A Specification on GitHub](https://github.com/a2aproject/A2A) - [Google: Announcing the Agent2Agent Protocol](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) - [Linux Foundation: A2A Project Launch](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project) 🤖 Test the MCP layer of your agent stack with a live AI model Before your agents start delegating over A2A, make sure each one's tools actually work. Use [MCP Agent Studio](/mcp-agent-studio) to chat with your MCP server and watch a real model call its tools. Works with Claude, GPT, Gemini and more. Free credits on sign-up. ## Frequently asked questions ### Does A2A replace MCP? No. They operate on different axes. MCP connects an agent to tools and data; A2A connects agents to each other. Google explicitly positions A2A as complementary to MCP, and most agent stacks use both. ### Who created MCP and A2A? Anthropic released MCP in November 2024. Google announced A2A in April 2025 and donated it to the Linux Foundation in June 2025, where it is now a vendor-neutral open project. ### What is an Agent Card in A2A? An Agent Card is a JSON document an agent publishes at a well-known URL describing its skills, endpoint, and auth requirements. Other agents read it to decide whether to delegate a task — it is A2A discovery, similar in spirit to MCP tools/list. ### Can I use MCP and A2A in the same system? Yes, and most production systems do. A2A handles coordination between agents while each agent uses MCP to call its own tools and data sources. They form two layers of one architecture rather than competing choices. ### Is A2A the same as multi-agent frameworks like CrewAI? Not quite. Frameworks like CrewAI or LangGraph orchestrate agents inside one application. A2A is an open wire protocol for agents to communicate across frameworks, teams, and vendors — including agents the framework did not build. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-vs-a2a-agent2agent-protocol — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # MCP Gateway: How to Aggregate and Secure Multiple MCP Servers (2026) > Connecting an AI agent to ten MCP servers means ten auth flows, ten logs to chase, and ten ways to get attacked. An MCP gateway puts one secured endpoint in front of all of them. Here is what an MCP gateway does, when you need one, and how to test servers behind it. **Source:** https://mcpplaygroundonline.com/blog/mcp-gateway-guide **Author:** Nikhil Tiwari **Published:** 2026-06-20 **Category:** Guide **Reading time:** 11 min read --- 📖 TL;DR — Key Takeaways - An **MCP gateway** is a proxy that sits between your AI client and many MCP servers, exposing them through **one secured endpoint** - It solves the mess you hit at scale: **auth sprawl, no central logging, tool-name collisions, and direct exposure to untrusted servers** - Core jobs: **tool aggregation, OAuth termination, access policy, rate limiting, observability, and security filtering** - A _gateway_ is runtime infrastructure; a _registry_ is a discovery index — they are not the same thing - Test each server before and after it sits behind the gateway with [MCP Playground](https://mcpplaygroundonline.com/mcp-test-server) One MCP server is easy. You paste a URL, the client lists the tools, and a model starts calling them. Ten servers is a different story. That is where an **MCP gateway** stops being optional. Wire ten servers directly into an agent and you inherit ten auth flows, ten sets of logs, ten places a tool name can collide, and ten third parties you now trust with your prompts. A gateway puts a single front door in front of all of them — with auth, policy, and logging in one place. This guide covers what an MCP gateway does, how it differs from a registry, the options in 2026, and how to test servers that live behind one. New to the protocol? Start with [what the Model Context Protocol is](/blog/what-is-model-context-protocol), then come back. 📑 Table of Contents 1. [What is an MCP gateway?](#what) 2. [Why you need one](#why) 3. [What an MCP gateway does](#features) 4. [Gateway vs registry vs proxy](#vs) 5. [MCP gateway options in 2026](#options) 6. [The architecture pattern](#setup) 7. [Security: the real reason](#security) 8. [Testing servers behind a gateway](#testing) 9. [FAQ](#faq) ## What is an MCP gateway? An _MCP gateway_ is a server that speaks MCP on both sides. It is a client to your real MCP servers and a server to your AI app. Your agent connects to one endpoint. The gateway connects out to every backend server and merges their tools, resources, and prompts into a single catalog. **If you have used an API gateway, the mental model is identical.** One ingress, many backends, with auth and policy enforced at the edge. The agent never knows there are ten servers behind the curtain. It sees one server with a lot of tools. That indirection is the whole point. It is where you get to add the things a raw server connection does not give you. ## Why you need an MCP gateway Here is the problem. MCP makes it trivial to connect one server. It does nothing to help you manage fifty. Now agitate that. Each server you bolt on directly adds its own credentials, its own failure mode, and its own attack surface to your agent. The pain shows up in concrete ways: - **Auth sprawl** — every server wants its own token or OAuth flow, scattered across config files - **No central logging** — when an agent does something wrong, you have no single place to see which tool ran - **Tool-name collisions** — two servers both expose `search` and the model can't tell them apart - **Blind trust** — a third-party server can ship a poisoned tool description straight into your model's context - **No rate limiting** — a runaway agent loop hammers a paid API with no throttle in front of it - **Config drift** — every client (Claude Desktop, Cursor, your app) needs the same server list maintained by hand **A gateway collapses all of that into one control point.** One token to your gateway. One log stream. One policy. One list to maintain. If you run a single local server for yourself, you do not need this. If you run agents in production across a team, you will build a gateway whether you call it that or not. ## What an MCP gateway actually does Strip away the marketing and a gateway does six jobs. Some products do all six; many do two or three well. - **Tool aggregation and namespacing** — merges tools from many servers and prefixes names (like `github__create_issue`) so collisions disappear - **Auth termination** — handles OAuth 2.1 and token exchange to each backend, so the client holds one credential instead of many - **Access policy** — decides which user, agent, or app can see and call which tools (RBAC at the tool level) - **Observability** — central JSON-RPC logging, tracing, and metrics for every tool call passing through - **Rate limiting and caching** — throttles abusive loops and caches repeat `tools/list` responses - **Security filtering** — scans tool descriptions and results for poisoning and injection before they reach the model The namespacing alone is worth it. Tool-name collisions are one of the quietest ways a multi-server agent goes wrong, and a model has no way to resolve them on its own. For the auth piece specifically, my [guide to MCP server OAuth and bearer tokens](/blog/mcp-server-oauth-authentication-guide) covers what the spec actually requires before you put a gateway in front of it. Check each server before it goes behind the gateway Paste a server URL, pick a model, and watch every tool call as structured JSON. No setup. Free credits on sign-up. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Open Agent Studio](/mcp-agent-studio) ## MCP gateway vs registry vs proxy These three terms get mixed up constantly. They solve different problems. Thing What it does When you reach for it **Registry** A searchable index of servers — discovery, not traffic Finding a server to use **Proxy** Forwards traffic to one server, maybe adds auth or a transport switch Exposing one local server remotely **Gateway** Aggregates many servers, adds auth, policy, logging, and security Running many servers in production **A registry tells you a server exists. A gateway carries the traffic.** You often use both: discover a server in a registry, then add it to your gateway. If you are publishing servers rather than consuming them, see [how to publish your MCP server to the registry](/blog/how-to-publish-your-mcp-server-to-registry). ## MCP gateway options in 2026 The space moved fast. By mid-2026 you have a real spread of choices, from open-source projects to managed platforms. - **Docker MCP Gateway** — open source, runs each server in a container, with secrets handling and tool filtering built in; ships with Docker's MCP Toolkit - **IBM ContextForge (MCP Gateway)** — open-source gateway and registry that federates many servers behind one endpoint with admin UI and auth - **Cloud AI gateways** — providers like Cloudflare and the big clouds added MCP routing on top of existing AI-gateway and API-management products - **Security-first gateways** — vendors focused on scanning tool descriptions and results for poisoning and injection as traffic passes through - **Roll your own** — a thin MCP server that fans out to backends; fine for a handful of internal servers, painful past that My advice: do not start by building one. Pick an open-source gateway, run your existing servers behind it, and only build custom logic when an off-the-shelf option blocks you. Need this for dev or testing, not production? Skip the gateway. [MCP Agent Studio](/mcp-agent-studio) lets you connect **multiple MCP servers in the same chat window** and run a model against all of their tools at once — no aggregation layer to deploy, no namespacing config, no container. It is the fastest way to see how a set of servers behaves together before you decide whether you even need a standing gateway. [Connect multiple servers in one chat →](/mcp-agent-studio) Whatever you pick, the backends are still ordinary MCP servers. Containerizing them is the same work as any deploy — my [Docker production guide](/blog/deploy-mcp-server-docker-production-guide) covers it. ## The MCP gateway architecture pattern You do not need a diagram tool to picture this. The flow is linear. 1. **Client connects once** — your agent or IDE points at the gateway's single Streamable HTTP endpoint with one credential 2. **Gateway authenticates the caller** — it checks who is asking and which tools that identity is allowed to see 3. **Gateway fans out** — it holds live connections to each backend server and merges their `tools/list` output into one namespaced catalog 4. **Model calls a tool** — the gateway routes the `tools/call` to the right backend, attaches that backend's own auth, and waits 5. **Result flows back** — the gateway logs the call, optionally scans the result, and returns it to the client The client stays simple. The complexity — credentials, routing, policy — lives in one place you control and can audit. Most gateways speak _Streamable HTTP_ on the client side, which is the production transport in current MCP. For background on remote connections, see [remote MCP servers](/blog/remote-mcp-servers). ## Security: the real reason gateways matter Aggregation is convenient. Security is the reason gateways got serious investment in 2026. When your agent connects to a third-party server directly, that server's tool descriptions go straight into your model's context. A malicious description is a prompt-injection payload with a clean delivery path. That attack has a name — _tool poisoning_. A gateway is the natural chokepoint to catch it before it reaches the model. A security-aware gateway can: - **Scan tool descriptions** for hidden instructions before exposing them to the client - **Filter results** for injected content coming back from a tool call - **Pin server versions** so a silent description change ("rug pull") is flagged, not trusted - **Enforce least privilege** so a compromised server can't reach tools it never needed **Before you put any server behind a shared gateway:** a poisoned tool or exposed endpoint becomes everyone's problem once it is aggregated. [Scan your MCP server →](https://mcpplaygroundonline.com/mcp-security-scanner) for injection and exposure first. For the full threat list, read my breakdown of [tool poisoning and the OWASP MCP Top 10](/blog/mcp-security-tool-poisoning-owasp-top-10-mcp-scan) and the [guide to how attackers find exposed MCP servers](/blog/mcp-server-security-complete-guide-2026). ## How to test MCP servers behind a gateway A gateway adds a layer, and layers hide bugs. Test in two places, not one. **First, test each server on its own.** Before a server joins the gateway, confirm a real model can find its tools and call them with valid arguments. That is exactly what [MCP Playground](https://mcpplaygroundonline.com/mcp-test-server) is for. Paste the server URL, pick a model, send a prompt, and watch every tool call as structured JSON — no local client to build. **Then, test through the gateway endpoint.** Point the same tool at your gateway URL and re-run the prompt. Now you are checking the layer the gateway added. What I look for when testing through a gateway: - **Namespacing** — do tool names come through prefixed, and can the model still pick the right one? - **Auth pass-through** — does a call reach the backend with the right credentials, or fail at the gateway? - **Latency** — the extra hop costs milliseconds; make sure it is milliseconds, not seconds - **Tool count** — a bloated, aggregated catalog can blow your context window and confuse tool choice That last point bites people. Merge ten servers and you might hand the model 120 tools — my note on [how tools eat your context window](/blog/mcp-token-counter-optimize-context-window) explains why that hurts, and why gateway-side tool filtering matters. ## Frequently asked questions **What is an MCP gateway in simple terms? +** An MCP gateway is a server that sits between your AI client and many MCP servers. Your client connects to one endpoint, and the gateway merges the tools from every backend server into a single catalog while adding authentication, access policy, logging, rate limiting, and security filtering. It is the same pattern as an API gateway, applied to the Model Context Protocol. **Is an MCP gateway the same as the MCP registry? +** No. A registry is a searchable index for discovering MCP servers — it does not carry traffic. A gateway is runtime infrastructure that proxies and secures the actual tool calls. You often use both: discover a server in a registry, then add it to your gateway so its tools run through one secured endpoint. **Do I need an MCP gateway for a single server? +** Usually not. For one local server you use yourself, a direct connection is simpler. A gateway earns its place once you run several servers, share them across a team, expose third-party servers to your agents, or need central auth, logging, and security policy. At that point the gateway replaces a pile of per-server config and risk. **How do I test a server that sits behind a gateway? +** Test in two passes. First point a tool like MCP Playground at the individual server URL and confirm a model can call its tools with valid arguments. Then point the same tool at the gateway endpoint and re-run the prompt to check the layer the gateway adds — namespacing, auth pass-through, latency, and whether the aggregated tool count is still manageable for the model. Test every server before and after the gateway Run your MCP servers against real models in the browser, then scan them for injection before they go behind a shared endpoint. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Scan your MCP server](https://mcpplaygroundonline.com/mcp-security-scanner) ## Further Reading - [What Is the Model Context Protocol (MCP)?](/blog/what-is-model-context-protocol) - [How to Add Authentication to Your MCP Server (OAuth 2.1)](/blog/mcp-server-oauth-authentication-guide) - [Tool Poisoning and the OWASP MCP Top 10](/blog/mcp-security-tool-poisoning-owasp-top-10-mcp-scan) - [Remote MCP Servers — Test and Connect Online](/blog/remote-mcp-servers) - [Deploy an MCP Server to Production with Docker](/blog/deploy-mcp-server-docker-production-guide) - [How to Publish Your MCP Server to the Registry](/blog/how-to-publish-your-mcp-server-to-registry) - [Official: MCP Specification](https://modelcontextprotocol.io/specification) - [Official: MCP Transports (Streamable HTTP)](https://modelcontextprotocol.io/docs/concepts/transports) - [Docker MCP Gateway on GitHub](https://github.com/docker/mcp-gateway) ## Frequently asked questions ### What is an MCP gateway in simple terms? An MCP gateway is a server that sits between your AI client and many MCP servers. Your client connects to one endpoint, and the gateway merges the tools from every backend server into a single catalog while adding authentication, access policy, logging, rate limiting, and security filtering. It is the same pattern as an API gateway, applied to the Model Context Protocol. ### Is an MCP gateway the same as the MCP registry? No. A registry is a searchable index for discovering MCP servers — it does not carry traffic. A gateway is runtime infrastructure that proxies and secures the actual tool calls. You often use both: discover a server in a registry, then add it to your gateway so its tools run through one secured endpoint. ### Do I need an MCP gateway for a single server? Usually not. For one local server you use yourself, a direct connection is simpler. A gateway earns its place once you run several servers, share them across a team, expose third-party servers to your agents, or need central auth, logging, and security policy. At that point the gateway replaces a pile of per-server config and risk. ### How do I test a server that sits behind a gateway? Test in two passes. First point a tool like MCP Playground at the individual server URL and confirm a model can call its tools with valid arguments. Then point the same tool at the gateway endpoint and re-run the prompt to check the layer the gateway adds — namespacing, auth pass-through, latency, and whether the aggregated tool count is still manageable for the model. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-gateway-guide — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Why Testing MCP Servers With Real AI Models Matters (2026) > A curl request proves your MCP server responds. It says nothing about whether a model can actually use it. Here is why testing MCP servers with real AI models matters, how model performance changes your results, and how to check that your server works across different models. **Source:** https://mcpplaygroundonline.com/blog/testing-mcp-servers-with-real-ai-models **Author:** Nikhil Tiwari **Published:** 2026-06-13 **Category:** Testing **Reading time:** 10 min read --- 📖 TL;DR — Key Takeaways - **Curl and unit tests check the wire format. A real model checks whether the tool is usable** — those are different failures - A model decides _which_ tool to call, _when_, and _with what arguments_ — your schema and descriptions drive all three - **The same MCP server behaves differently across models** — GPT, Claude, Gemini, and the open-weight models pick tools and shape arguments differently - Model performance gains in 2026 changed tool-calling reliability — test against current models, not last year's - Run your server against multiple models in one place with [MCP Playground](https://mcpplaygroundonline.com/mcp-test-server) before you ship Your MCP server returns a clean `200`. The JSON validates. Every unit test is green. So it works, right? Not quite. **Testing MCP servers with real AI models is the only way to know your tools are actually usable** — and that is a separate question from whether they respond. A model has to read your tool descriptions, pick the right tool, and build valid arguments on its own. Curl never does any of that. I've watched servers pass every wire-level test and still fail in a live agent loop. The model couldn't tell two tools apart. Or it guessed an argument shape that didn't exist. This post covers why model-in-the-loop testing matters, how model performance changes your results, and how to check your server across different models before users do. 📑 Table of Contents 1. [What testing with real models means](#what) 2. [Why it matters](#why) 3. [What curl and unit tests miss](#gap) 4. [How model performance changes results](#performance) 5. [Checking different models](#different-models) 6. [A cross-model testing workflow](#workflow) 7. [How MCP Playground helps](#playground) 8. [FAQ](#faq) ## What testing MCP servers with real AI models means There are two layers to an MCP server, and they fail in different ways. **The transport layer** is the wire: JSON-RPC over Streamable HTTP or STDIO. Does the server respond, list tools, and return valid results? Curl and unit tests cover this fine. **The semantic layer** is whether a model can _use_ the tools. Can it find the right one, read the schema, and pass correct arguments without help? Testing with a real model means putting an actual LLM in the loop. You send a natural-language prompt, the model reads your `tools/list` output, and it decides what to call. That is the same flow your users hit in production. New to the protocol? Start with [what the Model Context Protocol is](/blog/what-is-model-context-protocol), then come back. ## Why testing MCP servers with real AI models matters Here's the problem. Your tool definition is a contract written for a reader you never meet during development — the model. A tool named `get_data` with a one-word description passes every schema validator. It also tells the model almost nothing about when to use it. Now agitate that. You have three tools that all sound similar. The model picks the wrong one. Or it skips your tool entirely and hallucinates an answer instead. None of that shows up in a unit test. The server worked perfectly — nobody called it correctly. The failures only a real model exposes: - **Tool selection** — the model picks the wrong tool, or ignores yours - **Argument construction** — it fills a required field with a value of the wrong type or format - **Ambiguous descriptions** — two tools read as interchangeable, so choice becomes a coin flip - **Multi-step chaining** — the model can't sequence tool A's output into tool B's input - **Over-calling** — a vague description makes the model call your tool when it shouldn't **Every one of these is a real bug your users will hit.** And every one is invisible until a model drives the server. That is why model-in-the-loop testing isn't optional. See your server through a model's eyes Paste a server URL, pick a model, and watch every tool call as structured JSON. No setup. Free credits on sign-up. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Open Agent Studio](/mcp-agent-studio) ## What curl and unit tests quietly miss I'm not against unit tests. They're fast, deterministic, and they belong in CI. But they test the half of the server that rarely breaks in surprising ways. Here's the split I use: Question curl / unit test real model Does the server respond? ✅ ✅ Is the JSON schema valid? ✅ ✅ Does a model pick the right tool? ❌ ✅ Are the descriptions clear enough? ❌ ✅ Can it chain multiple tools? ❌ ✅ **Unit tests confirm the wire format. A real model confirms the product.** You need both, but only one of them mirrors what your users actually do. For a full breakdown of a test plan, see my [step-by-step guide to testing MCP servers](/blog/how-to-test-mcp-servers-step-by-step) and [how QA teams should approach it](/blog/how-qa-teams-should-test-mcp-servers). ## How AI model performance changes your MCP results Tool calling is a model capability, and it has improved sharply over the last year. That cuts both ways for your testing. A stronger model is more forgiving. It can infer intent from a weak tool description and still pick correctly. So a server that "works" on the latest frontier model may be hiding sloppy schemas. Swap in a smaller or older model and the cracks show. The weak description that the frontier model papered over now produces wrong tool calls. **This is the trap: you test on your favorite model, ship, then a user runs your server on a cheaper one and it falls apart.** Performance shows up in concrete ways: - **Parallel tool calls** — newer models fire several tools in one turn; older ones go one at a time - **Argument accuracy** — better models respect enums, formats, and required fields more reliably - **Recovery** — a strong model reads an error result and retries with a fix; a weak one loops or gives up - **Reasoning before calling** — reasoning models plan a tool sequence instead of guessing the first step Because of this, last year's test run doesn't validate today's reality. Models update constantly — re-test against current ones. My breakdown of the [best AI model for MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling) goes deeper on the differences. ## Checking how different models work with your MCP server Here's the part most people skip: **the same MCP server behaves differently across models.** Tool calling isn't standardized behavior — each model family has its own habits. If you only ship to one client, test on the model that client uses. If you publish a public server, you don't get to choose — so test broadly. What I watch for across families: - **Claude (Opus 4.7, Sonnet 4.6)** — strong at reading long descriptions and chaining tools; good baseline for "is my schema clear" - **GPT-5.x** — aggressive parallel tool calls; exposes race conditions in stateful servers fast - **Gemini 3** — strict about argument formats; surfaces loose schema definitions - **Open-weight (DeepSeek V4, Qwen 3.x, GLM, Kimi, MiniMax)** — more sensitive to vague descriptions; the honest stress test for tool clarity A concrete example. I once had a tool with an optional `format` field. Claude ignored it and defaulted correctly. A smaller open model passed an invalid value every time. The fix wasn't the model — it was my description. I made the allowed values explicit, and every model got it right. **Cross-model testing turns a "model bug" into a schema fix you control.** I've written client-specific walkthroughs if you want the exact setup: [ChatGPT and OpenAI](/blog/test-mcp-server-with-chatgpt-and-openai), [Gemini models](/blog/test-mcp-server-with-gemini-models), [DeepSeek V4](/blog/testing-mcp-with-deepseek), and [Grok](/blog/testing-mcp-with-grok-xai). ## A practical cross-model MCP testing workflow You don't need a test farm. Here's the order I work in before shipping a server. 1. **Wire check first** — confirm the server lists tools and returns valid results with curl or your client. Fix transport bugs before involving a model 2. **One strong model** — connect a frontier model and run real prompts. Confirm it finds and calls each tool 3. **One weak model** — repeat on a smaller or open-weight model. This is where unclear descriptions break 4. **Watch the arguments** — don't just check the final answer. Read the actual JSON arguments the model built for each call 5. **Test the chains** — give a prompt that needs two or three tools in sequence and confirm the model wires outputs into inputs 6. **Fix the schema, not the model** — most failures trace back to a vague name, description, or enum. Tighten those and re-run If your tools touch real systems, add a security pass too — a tool a model over-calls is also a tool an attacker can abuse. **Before you publish a public server:** a model that can be talked into the wrong tool call is a prompt-injection surface. [Scan your MCP server →](https://mcpplaygroundonline.com/mcp-security-scanner) for exposure and injection first. ## How MCP Playground helps you test across models Setting up one client per model is the reason most people skip cross-model testing. That's the friction [MCP Playground](https://mcpplaygroundonline.com/mcp-test-server) removes. It runs in the browser: paste a server URL, pick from dozens of models across providers — Claude, GPT-5.x, Gemini 3, DeepSeek, Qwen, Grok, Kimi, and more — and send a real prompt. No API keys, no local client to rebuild. You see every tool call as structured JSON: which tool the model chose, the exact arguments, and the raw result. Switch models and re-run the same prompt to compare behavior side by side. That's the loop that catches the regressions a migration or a schema tweak hides — before your users find them. ## Frequently asked questions **Why isn't passing my unit tests enough to know my MCP server works? +** Unit tests and curl check the transport layer: does the server respond, list tools, and return valid JSON. They never check whether a model can read your tool descriptions, pick the right tool, and build valid arguments on its own. That semantic layer only gets tested when a real AI model drives the server with a natural-language prompt — which is exactly what your users do in production. **Does the same MCP server work differently with different AI models? +** Yes. Tool calling is a model capability, not standardized behavior. Stronger models infer intent from weak descriptions and forgive sloppy schemas; smaller or open-weight models expose those gaps with wrong tool choices or invalid arguments. Models also differ in parallel tool calls, format strictness, and error recovery. If you publish a public server, test across several model families. **How do I test my MCP server with a real AI model without a full client setup? +** Use a browser-based tool like MCP Playground. Paste your server URL, pick a model, and send a natural-language prompt — no API keys or local client required. You see which tool the model chose, the exact arguments it built, and the raw result as structured JSON, then switch models to compare behavior on the same prompt. **My tool works on the latest model but fails on a smaller one. Whose bug is it? +** Usually it's your schema, not the model. A frontier model papers over a vague tool name, description, or missing enum; a smaller model takes the schema literally and gets it wrong. Make allowed values explicit, sharpen the description, and tighten required fields. Cross-model testing turns what looks like a model bug into a schema fix you control. Don't guess whether your server works — watch a model use it Run your MCP server against dozens of models in the browser and catch tool-calling bugs early. Free credits on sign-up. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Scan your MCP server](https://mcpplaygroundonline.com/mcp-security-scanner) ## Further Reading - [What Is the Model Context Protocol (MCP)?](/blog/what-is-model-context-protocol) - [The Best AI Model for MCP Tool Calling](/blog/best-ai-model-for-mcp-tool-calling) - [How to Test MCP Servers: A Step-by-Step Guide](/blog/how-to-test-mcp-servers-step-by-step) - [How QA Teams Should Test MCP Servers](/blog/how-qa-teams-should-test-mcp-servers) - [Test Your MCP Server With ChatGPT and OpenAI](/blog/test-mcp-server-with-chatgpt-and-openai) - [Test Your MCP Server With Gemini Models](/blog/test-mcp-server-with-gemini-models) - [Ultimate MCP Testing Resources for Developers in 2026](/blog/mcp-testing-resources-developers-2026) - [Official: MCP Tools Concept Docs](https://modelcontextprotocol.io/docs/concepts/tools) - [Official: MCP Specification](https://modelcontextprotocol.io/specification/draft) ## Frequently asked questions ### Why isn't passing my unit tests enough to know my MCP server works? Unit tests and curl check the transport layer: does the server respond, list tools, and return valid JSON. They never check whether a model can read your tool descriptions, pick the right tool, and build valid arguments on its own. That semantic layer only gets tested when a real AI model drives the server with a natural-language prompt — which is exactly what your users do in production. ### Does the same MCP server work differently with different AI models? Yes. Tool calling is a model capability, not standardized behavior. Stronger models infer intent from weak descriptions and forgive sloppy schemas; smaller or open-weight models expose those gaps with wrong tool choices or invalid arguments. Models also differ in parallel tool calls, format strictness, and error recovery. If you publish a public server, test across several model families. ### How do I test my MCP server with a real AI model without a full client setup? Use a browser-based tool like MCP Playground. Paste your server URL, pick a model, and send a natural-language prompt — no API keys or local client required. You see which tool the model chose, the exact arguments it built, and the raw result as structured JSON, then switch models to compare behavior on the same prompt. ### My tool works on the latest model but fails on a smaller one. Whose bug is it? Usually it's your schema, not the model. A frontier model papers over a vague tool name, description, or missing enum; a smaller model takes the schema literally and gets it wrong. Make allowed values explicit, sharpen the description, and tighten required fields. Cross-model testing turns what looks like a model bug into a schema fix you control. --- _Canonical page: https://mcpplaygroundonline.com/blog/testing-mcp-servers-with-real-ai-models — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # MCP Goes Stateless: What the 2026-07-28 Spec Changes > MCP 2026-07-28 shipped final on July 28, 2026 — the biggest protocol revision since launch. It drops the session handshake, adds the Tasks and Apps extensions, hardens auth, and deprecates Roots, Sampling, and Logging. Here is what changed, and how to migrate. **Source:** https://mcpplaygroundonline.com/blog/mcp-stateless-2026-release-candidate **Author:** Nikhil Tiwari **Published:** 2026-06-12 **Updated:** 2026-07-29 **Category:** Development **Reading time:** 11 min read --- ✅ Update — July 29, 2026: this shipped MCP **2026-07-28 is now the final specification**, published on schedule. All four Tier 1 SDKs (TypeScript, Python, Go, C#) speak it as of launch day. TypeScript ships as two new packages — `@modelcontextprotocol/client` and `@modelcontextprotocol/server`, both at 2.0 — while the old `@modelcontextprotocol/sdk` line continues for 2025-era servers. This post was written against the release candidate; the details below held, and it now describes shipped behaviour rather than a proposal. Building something new on it? See [the from-scratch build guide](/blog/build-mcp-server-2026-spec). 📖 TL;DR — Key Takeaways - The **2026-07-28 specification** makes **MCP stateless** — no more `initialize` handshake or `Mcp-Session-Id` pinning clients to one server - Requests now carry `Mcp-Method` and `Mcp-Name` headers, so load balancers route without opening the body - Server-initiated requests are replaced by **Multi Round-Trip Requests**: the server returns `input_required`, the client answers and re-issues the original call - **Tasks** and **MCP Apps** move into a formal **Extensions framework**; tools support full JSON Schema 2020-12 - **Roots, Sampling, and Logging are deprecated** — minimum 12-month removal window - Shipped final **July 28, 2026**; clients that speak it fall back to the handshake for older servers, so migration can be gradual If you run a remote MCP server, the ground just shifted. The **2026-07-28 specification makes MCP stateless** at the protocol layer. That sounds dry. It is not. It is the biggest revision since MCP launched in late 2024 — people are calling it "MCP 2.0." The session handshake is gone. Tasks and Apps became extensions. Three core features got deprecated. Auth got hardened to match real OAuth. The RC locked on May 21, 2026 and the final spec shipped on **July 28, 2026**. Migration is now live work, not preparation. Skip this and your "working" server breaks the day a client upgrades. Read it and you ship the change calmly. Let me walk you through every piece. 📑 Table of Contents 1. [What the 2026-07-28 spec actually is](#what) 2. [Why MCP went stateless](#why-stateless) 3. [The new request model](#request-model) 4. [Tasks, Apps & Extensions](#extensions) 5. [Caching with ttlMs & tracing](#caching) 6. [Authorization hardening](#auth) 7. [What's deprecated](#deprecations) 8. [How to migrate](#migrate) 9. [How MCP Playground helps](#playground) 10. [FAQ](#faq) ## What the 2026-07-28 specification actually is MCP versions are dated, not numbered. The previous stable spec was **2025-11-25**. The current one is **2026-07-28**, final since July 28, 2026. It went through a ten-week release-candidate window so SDK maintainers could validate against real workloads. All four Tier 1 SDKs shipped support by publication day. The headline features are a _stateless core_, the _Extensions framework_, the _Tasks_ and _MCP Apps_ extensions, authorization hardening, and a formal deprecation policy. If you only have time for one sentence: **MCP moved from a promising integration protocol to infrastructure you can standardize on in production**. New to the protocol entirely? Start with [what the Model Context Protocol is](/blog/what-is-model-context-protocol), then come back. The rest of this assumes you know the basics. ## Why MCP went stateless Here's the problem the old design created. Every connection started with an `initialize`/`initialized` handshake and got an `Mcp-Session-Id`. That session ID pinned a client to one specific server instance. The state lived in transport, not in your app. Now agitate it. To scale a [remote MCP server](/blog/remote-mcp-servers) you needed sticky sessions, a shared session store, and a gateway doing deep packet inspection to figure out where each request belonged. That is a brutal tax on anything cloud-native. Round-robin load balancing? Off the table. Autoscaling? Painful. Every restart dropped live sessions. The fix: kill the handshake. **Protocol version, client info, and capabilities now travel inline in a `_meta` field on each request** — not once at connection setup. A server that needed sticky routing can now sit behind a plain round-robin load balancer. No shared store. No packet inspection. Any instance can serve any request. When you do need state — a shopping basket, say — the server mints an explicit handle (a basket ID) and the model passes it back as a tool argument. State becomes visible to the agent instead of hidden in transport. ## The new request model: Mcp-Method and inline metadata With sessions gone, requests have to carry their own context. Two new headers do the heavy lifting on Streamable HTTP POSTs. - **`Mcp-Method`** — the JSON-RPC method being called (like `tools/call`) - **`Mcp-Name`** — the specific tool or resource name Why headers? So a load balancer, gateway, or rate-limiter can route and throttle on the operation _without opening the request body_. That is a big win for infra teams. Server-to-client round trips changed too. Long-lived SSE streams are no longer the only path. When a server needs input mid-call, it returns an `InputRequiredResult` with a `requestState` payload. The client gathers the answer and reissues the original call with `inputResponses`. **Because everything needed to resume is in the payload, any server instance can process the retry.** That is the whole point of stateless — self-contained requests. Tool schemas also got an upgrade. They now support full [JSON Schema 2020-12](https://json-schema.org/specification) — `oneOf`, `anyOf`, `allOf`, conditionals, and `$ref`. Output schemas are unrestricted; input schemas keep an object root. ## Tasks, MCP Apps, and the Extensions framework The spec introduces a real **Extensions framework** so features can evolve without bloating the core. Extensions get reverse-DNS identifiers, capability negotiation, and independent versioning. Two big extensions ship alongside it. ### The Tasks extension Long-running work finally has a first-class home. A server answers a `tools/call` with a **task handle** instead of blocking. The client then drives it with `tasks/get`, `tasks/update`, and `tasks/cancel`. Task creation is server-directed — the server decides when a call should run async. **Heads up:** Tasks were experimental in the 2025-11-25 spec. The lifecycle was redesigned. Anyone using the old experimental Tasks API has to migrate to the extension. ### MCP Apps **MCP Apps let a server ship interactive HTML UIs rendered in a sandboxed iframe inside the client.** Tools declare UI templates so the client can prefetch and security-review them. UI actions flow through the same JSON-RPC path as direct tool calls — no separate channel to secure. Want the deep version? I wrote a full [guide to building MCP Apps](/blog/build-mcp-apps-developer-guide). Test your server against real models before the spec ships Connect any MCP server in the browser, no setup. Free credits on sign-up. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Open Agent Studio](/mcp-agent-studio) ## Caching with ttlMs and built-in tracing Without a persistent session, clients need a way to know how long data stays fresh. The spec borrows from HTTP Cache-Control. **List and resource-read results now carry `ttlMs` and `cacheScope` fields.** A client knows exactly how long a `tools/list` response is fresh, and whether it is safe to share across users. That kills a real annoyance: you no longer need a long-lived SSE stream just to learn that a tool list changed. Observability got formalized too. [W3C Trace Context](https://www.w3.org/TR/trace-context/) propagation is now documented with fixed keys: `traceparent`, `tracestate`, and `baggage`. So distributed traces correlate across SDKs and show up as unified span trees in your OpenTelemetry backend. For anyone running MCP in production, that is a quiet but huge upgrade. ## Authorization hardening Six SEPs (spec enhancement proposals) tighten how MCP does [OAuth 2.0 and OpenID Connect](/blog/mcp-server-oauth-authentication-guide) to match real-world deployments. The changes that will touch your code: - Clients must validate the `iss` parameter on authorization responses, per [RFC 9207](https://www.rfc-editor.org/rfc/rfc9207.html) - Clients declare `application_type` during Dynamic Client Registration, so a CLI or desktop client is not misclassified as a web app - Credentials bind to a specific authorization-server issuer - Scope accumulation during step-up and `.well-known` discovery are clarified None of this is novel auth theory. It is MCP catching up to how OAuth is actually deployed — which is exactly what an enterprise security team wants to see before they approve it. **Before you ship the auth change:** a misconfigured token flow leaks more than a buggy tool ever will. [Scan your MCP server →](https://mcpplaygroundonline.com/mcp-security-scanner) for exposure and injection first. ## What's being deprecated It ships a formal **deprecation policy** for the first time. Features move through _Active → Deprecated → Removed_, with a minimum twelve-month window between deprecation and removal. Three features enter deprecation now: Deprecated feature Use instead **Roots** Tool parameters or config **Sampling** Call the LLM provider API directly **Logging** stderr or OpenTelemetry The twelve-month window means nothing breaks on July 28. But if your server leans on Sampling, plan the move to a direct [provider API call](/blog/best-ai-model-for-mcp-tool-calling) now. ## How to migrate You do not need to rewrite everything. Most servers need a focused checklist. Here's the order I'd work in. 1. **Upgrade the SDK** — all four Tier 1 SDKs support 2026-07-28 today. On TypeScript that means the new `@modelcontextprotocol/client` and `@modelcontextprotocol/server` 2.0 packages, not a version bump of the old one 2. **Drop session assumptions** — stop relying on `Mcp-Session-Id`; move any per-session state into explicit handles passed as tool arguments 3. **Emit the new headers** — make sure `Mcp-Method` and `Mcp-Name` are set on Streamable HTTP requests 4. **Migrate Tasks** — if you used experimental async Tasks, switch to the `tasks/get` / `tasks/update` / `tasks/cancel` lifecycle 5. **Add `ttlMs`** to your list and resource responses so clients cache correctly 6. **Fix auth** — validate `iss`, declare `application_type`, bind credentials to the issuer 7. **Plan deprecations** — schedule the move off Roots, Sampling, and Logging within the 12-month window Then test it against a real client. A spec change is exactly the kind of thing that looks fine in unit tests and falls over in a live agent loop. For the broader picture beyond the RC, my [2026 MCP roadmap breakdown](/blog/mcp-2026-roadmap-whats-changing-for-developers) covers what lands after July. ## How MCP Playground helps you test the new spec Reading the spec is half the work. The other half is confirming your server still behaves once a _real model_ drives it — the part curl and Postman can't check. [MCP Playground](https://mcpplaygroundonline.com/mcp-test-server) runs in the browser: paste a server URL, pick from 70+ models, and watch every tool call as structured JSON. No local setup, no API keys, no client to rebuild. When you refactor for the new spec, that model-in-the-loop test is what surfaces the regressions a migration hides — a tool the model can no longer find, an argument shape that drifted, an auth flow that broke. Test the behavior, not just the wire format. See it break here before your users do. ## Frequently asked questions **What does it mean that MCP is now stateless? +** The 2026-07-28 specification removes the initialize/initialized handshake and the Mcp-Session-Id header that pinned a client to one server instance. Protocol version, client info, and capabilities now travel inline in a \_meta field on each request. Any server instance can serve any request, so a remote MCP server can run behind a plain round-robin load balancer without sticky sessions or a shared session store. **When does the new MCP spec ship? +** The release candidate locked on May 21, 2026, and the final 2026-07-28 specification shipped on July 28, 2026. The ten-week gap was a validation window for Tier-1 SDK maintainers, and all four shipped support by publication day. **What is deprecated in the 2026-07-28 MCP specification? +** Three features enter deprecation: Roots (replaced by tool parameters or config), Sampling (call the LLM provider API directly), and Logging (use stderr or OpenTelemetry). A formal deprecation policy guarantees a minimum twelve-month window between deprecation and removal, so none of these break on July 28. **Do I have to rewrite my MCP server for the new spec? +** No full rewrite. Most servers need a focused checklist: upgrade the SDK, drop Mcp-Session-Id assumptions and use explicit handles for state, emit the new Mcp-Method and Mcp-Name headers, migrate experimental Tasks to the new lifecycle, add ttlMs to list responses, and harden auth. Deprecated features have a 12-month runway, so you can schedule those moves separately. Migrating to the 2026 spec? Test as you go. Run your server against 70+ models in the browser and catch regressions early. Free credits on sign-up. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Scan your MCP server](https://mcpplaygroundonline.com/mcp-security-scanner) ## Further Reading - [The 2026 MCP Roadmap: What's Changing for Developers](/blog/mcp-2026-roadmap-whats-changing-for-developers) - [Remote MCP Servers Explained](/blog/remote-mcp-servers) - [Build MCP Apps: A Developer's Guide](/blog/build-mcp-apps-developer-guide) - [MCP Server OAuth Authentication Guide](/blog/mcp-server-oauth-authentication-guide) - [Deploy an MCP Server with Docker in Production](/blog/deploy-mcp-server-docker-production-guide) - [What Is the Model Context Protocol (MCP)?](/blog/what-is-model-context-protocol) - [Official: The 2026-07-28 Specification Release Candidate](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) - [Official: MCP Specification Changelog](https://modelcontextprotocol.io/specification/draft/changelog) 🧪 Test against a live 2026-07-28 endpoint Reading about the stateless revision is not the same as talking to it. [The hosted stateless mock server](/mock-mcp-servers) speaks 2026-07-28 — Multi Round-Trip Requests, signed `requestState`, no handshake — and it is a public URL you can paste into any client. Pin `?rev=2026-07-28` and send a 2025-era `initialize` to watch the `-32022 UnsupportedProtocolVersion` rejection your client will have to handle. To check the other direction, paste your own server URL into the [MCP Checker](/mcp-checker) and force a revision. ## Frequently asked questions ### What does it mean that MCP is now stateless? The 2026-07-28 specification removes the initialize/initialized handshake and the Mcp-Session-Id header that pinned a client to one server instance. Protocol version, client info, and capabilities now travel inline in a _meta field on each request. Any server instance can serve any request, so a remote MCP server can run behind a plain round-robin load balancer without sticky sessions or a shared session store. ### When does the new MCP spec ship? The release candidate locked on May 21, 2026, and the final 2026-07-28 specification shipped on July 28, 2026. The ten-week gap was a validation window for Tier-1 SDK maintainers, and all four shipped support by publication day. ### What is deprecated in the 2026-07-28 MCP specification? Three features enter deprecation: Roots (replaced by tool parameters or config), Sampling (call the LLM provider API directly), and Logging (use stderr or OpenTelemetry). A formal deprecation policy guarantees a minimum twelve-month window between deprecation and removal, so none of these break on July 28. ### Do I have to rewrite my MCP server for the new spec? No full rewrite. Most servers need a focused checklist: upgrade the SDK, drop Mcp-Session-Id assumptions and use explicit handles for state, emit the new Mcp-Method and Mcp-Name headers, migrate experimental Tasks to the new lifecycle, add ttlMs to list responses, and harden auth. Deprecated features have a 12-month runway, so you can schedule those moves separately. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-stateless-2026-release-candidate — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Ultimate MCP Testing Resources for Developers in 2026 > A curated, live-tested catalog of the MCP testing resources that actually matter in 2026 — the official Inspector, browser tools, eval platforms, CLI runners, security scanners, registries, and the docs worth bookmarking. **Source:** https://mcpplaygroundonline.com/blog/mcp-testing-resources-developers-2026 **Author:** Nikhil Tiwari **Published:** 2026-06-06 **Category:** Guide **Reading time:** 11 min read --- 📖 TL;DR — Key Takeaways - The best **MCP testing resources** in 2026 fall into five buckets: inspectors, browser tools, eval platforms, security scanners, and registries - Start with the official **MCP Inspector** (`npx @modelcontextprotocol/inspector`) for protocol-level debugging - Use a **browser tool** like MCP Playground when you want zero setup and real agent testing across 70+ models - Add an **eval workflow** (FastMCP Client, scheduled model evals) once you need CI/CD and quality regression checks - The current stable spec is **2025-11-25** — and a breaking 2026-07-28 release candidate is already in migration There's no shortage of **MCP testing resources** in 2026. There's a shortage of ones worth your time. I've spent the last year testing MCP servers daily — official ones, sketchy community ones, and a lot of my own. This is the catalog I wish I'd had on day one. Every tool here is current as of **June 2026**. No abandoned repos, no vaporware. Just the inspectors, platforms, scanners, and docs I actually reach for. If you skip this, you'll waste a weekend gluing together tools that don't talk to each other. Let me save you that. 📑 Table of Contents 1. [What counts as an MCP testing resource](#what-counts) 2. [MCP Inspector (official)](#mcp-inspector) 3. [Browser-based testing](#browser-testing) 4. [Eval & agent platforms](#agent-eval) 5. [CLI & CI/CD tools](#cli-ci) 6. [Classic API tools that still work](#classic-tools) 7. [Security testing resources](#security) 8. [Registries & catalogs](#registries) 9. [Docs, specs & learning](#docs-learning) 10. [Quick comparison table](#comparison) 11. [How to choose](#how-to-choose) 12. [FAQ](#faq) ## What counts as an MCP testing resource? "Testing an MCP server" means more than one thing. Pick the wrong tool for the job and you'll think your server is broken when it isn't. A good _MCP testing resource_ covers at least one of these jobs: - **Protocol inspection** — does the JSON-RPC handshake, tool discovery, and transport work? - **Tool invocation** — does each tool return the right shape for given inputs? - **Agent behavior** — does a real model pick the right tool from a plain prompt? - **Security** — is the server exposed, injectable, or leaking secrets? - **Discovery** — where do you find servers to test in the first place? If you want the full methodology, read my [step-by-step guide to testing MCP servers](/blog/how-to-test-mcp-servers-step-by-step). This post is the tool shelf behind it. ## 1\. MCP Inspector — the official starting point The [MCP Inspector](https://github.com/modelcontextprotocol/inspector) is Anthropic's own visual testing tool, built alongside the protocol. It went stable in 2025 and is still the default first stop. Run it without cloning anything: ``` npx @modelcontextprotocol/inspector node build/index.js ``` It launches two parts: the **Inspector client UI on port 6274** and an **MCP proxy on port 6277**. The proxy bridges the browser to your server over stdio, SSE, or streamable HTTP. What you get: live JSON-RPC logs, tool/resource/prompt discovery, schema validation, and one-click tool invocation. It flags schema violations automatically. **Heads up:** the Inspector binds local-only by default and uses session tokens. That's a feature, not a bug — don't disable it to "make it work" on a remote box. Its real limit is collaboration. It's a single-developer debugging tool, not a CI platform or a team workspace. For that, you reach for the tools below. ## 2\. Browser-based testing — zero setup Not every test needs a terminal. Sometimes you just want to paste a URL and see if a remote server works. That's the niche [MCP Playground](/) fills. The free [Test MCP Server](/mcp-test-server) tool connects to any remote MCP endpoint, lists its tools, and lets you fire calls — no install, no config. Where it goes further than the Inspector: **real agent testing**. With [MCP Agent Studio](/mcp-agent-studio) you point 15+ frontier models at your server and watch them decide which tools to call from a plain-English prompt. Test any MCP server in your browser — free No install. No config. Paste a URL and inspect every tool call live. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) Cloudflare also ships a hosted way to [test remote MCP servers](https://developers.cloudflare.com/agents/guides/test-remote-mcp-server/) if your server runs on Workers. ## 3\. Eval & agent platforms Once your server "works," the next question is harder: does a model use it _correctly_? That's what eval platforms answer. An eval runs the same prompts against real models and checks they pick the right tool with the right arguments. The fastest way to do this in the browser is [MCP Agent Studio](/mcp-agent-studio) — point 70+ models at your server and **compare their tool choices on the same prompt**. It shows every tool call live with a JSON inspector, so you see exactly where a model misreads a description. That's the feedback loop evals are about. **Apify's Tester MCP Client** is a lighter option — a quick smoke-test client driven by simple JSON/YAML config, good for sanity checks during development. ## 4\. CLI & CI/CD tools Manual testing doesn't scale. For every push, you want fast, deterministic checks that run in CI. **FastMCP Client** is built for exactly that. It runs your server _in-memory_, skipping the network and transport layer, so unit tests stay fast and deterministic. The **MCP Inspector CLI mode** is the other half. It validates protocol compliance from the command line, which makes it easy to wire into a GitHub Actions step. **Rule of thumb:** run unit and integration checks on every push. Run model-based evals on a schedule — they cost API credits and aren't deterministic, so they're a poor gate for "did my change build." ## 5\. Classic API tools that still work Your old HTTP toolbelt isn't dead. For servers on streamable HTTP, classic tools still pull weight. - **Postman** — now supports MCP natively: tools, prompts, resources, sampling, and elicitation, with OAuth debugging built in - **JMeter** — load-test concurrent tool calls and watch where response times degrade under stress - **SoapUI** — chain tool invocations with Groovy scripts and validate intermediate results Reach for these when you care about throughput and HTTP semantics, not agent reasoning. ## 6\. Security testing resources MCP servers run privileged actions on real data. Skipping security testing is how a demo becomes a breach. Two things to know in 2026. First, **tool poisoning** and prompt injection are the dominant attack class — read my breakdown of the [OWASP MCP Top 10 and mcp-scan](/blog/mcp-security-tool-poisoning-owasp-top-10-mcp-scan). Second, the 2025-11-25 spec hardened auth: servers are OAuth Resource Servers, and clients must send Resource Indicators (RFC 8707) so tokens can't be replayed elsewhere. Is your MCP server leaking or exposed? Run a free audit for tool poisoning, exposed endpoints, and auth gaps. [Scan your MCP server →](https://mcpplaygroundonline.com/mcp-security-scanner) ## 7\. Registries & catalogs — where to find servers You can't test what you can't find. Since MCP moved to the Linux Foundation's Agentic AI Foundation in December 2025, the discovery layer has matured fast. - **[modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers)** — the official reference servers, great for practicing tests against known-good code - **[awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers)** — the big community list; see my [live-tested catalog](/blog/awesome-mcp-servers) - **Smithery** — 7,000+ servers, installable locally or hosted, the closest thing to Docker Hub for MCP - **Glama** — a searchable marketplace with previews - **Docker MCP Catalog** — containerized servers with isolation built in Or skip the hunt and browse the [MCP Servers List](/mcp-registry) on MCP Playground, where every entry can be opened straight into the test tool. ## 8\. Docs, specs & learning Tools change; the spec is the source of truth. Bookmark these. - **[2025-11-25 changelog](https://modelcontextprotocol.io/specification/2025-11-25/changelog)** — current stable spec: icons on tools, durable tasks, URL elicitation, OAuth Client ID Metadata Documents - **[Inspector docs](https://modelcontextprotocol.io/docs/tools/inspector)** — the canonical setup reference - **[MCP 2026 roadmap](/blog/mcp-2026-roadmap-whats-changing-for-developers)** — what the breaking 2026-07-28 release candidate changes - **[What is MCP?](/blog/what-is-model-context-protocol)** — the protocol explained from scratch ## Quick comparison table Resource Best for Setup MCP Inspector Protocol debugging npx, local MCP Playground **Browser + agent testing** None MCP Agent Studio Multi-model agent evals None FastMCP Client In-memory unit tests / CI Code Postman / JMeter HTTP & load testing Install MCP Security Scanner **Security audit** None ## How to choose, in one breath Debugging a protocol problem? **Inspector.** Checking a remote server fast? **MCP Playground.** Need quality regression across models? **Agent Studio or scheduled evals.** Wiring tests into CI? **FastMCP Client.** Worried about security? **Scanner plus the OWASP MCP Top 10.** Most teams end up using two or three together. ## Frequently asked questions **What is the best free MCP testing tool in 2026? +** For protocol-level debugging, the official MCP Inspector (npx @modelcontextprotocol/inspector) is the best free option. For zero-setup browser testing and real agent behavior across multiple models, MCP Playground is free to start. Most developers use both. **What ports does the MCP Inspector use? +** The Inspector client UI runs on port 6274 and the MCP proxy server runs on port 6277. The proxy bridges the browser UI to your server over stdio, SSE, or streamable HTTP transports. **What is the current MCP specification version? +** The current stable spec is 2025-11-25, which added icons on tools, durable tasks, URL-mode elicitation, and OAuth Client ID Metadata Documents. A 2026-07-28 release candidate with breaking changes is already published for migration planning. **How do I test a remote MCP server? +** The fastest way is a browser tool like MCP Playground — paste the URL and go. For local clients that can only speak stdio, use the mcp-remote proxy package to bridge to a remote HTTP endpoint. Start testing in 30 seconds Paste any MCP server URL into MCP Playground and inspect every tool call. Free, no install. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Try Agent Studio](/mcp-agent-studio) ## Further Reading - [How to Test MCP Servers Effectively: A Step-by-Step Guide](/blog/how-to-test-mcp-servers-step-by-step) - [How QA Teams Should Test MCP Servers](/blog/how-qa-teams-should-test-mcp-servers) - [How to Test Any MCP Server Online — No Setup Required](/blog/how-to-test-mcp-server-online-no-setup-required) - [What Is the Model Context Protocol (MCP)?](/blog/what-is-model-context-protocol) - [MCP Security: Tool Poisoning & the OWASP MCP Top 10](/blog/mcp-security-tool-poisoning-owasp-top-10-mcp-scan) - [Test MCP Server Online — Free browser tool](/mcp-test-server) 🧪 Test targets, not just test tools Most testing round-ups list clients and inspectors. The missing half is something to point them at: the [six hosted mock MCP servers](/mock-mcp-servers) are public, free, and cover echo, Bearer auth, deliberate errors, nested schemas, MCP Apps, and the stateless 2026-07-28 revision. ## Frequently asked questions ### What is the best free MCP testing tool in 2026? For protocol-level debugging, the official MCP Inspector (npx @modelcontextprotocol/inspector) is the best free option. For zero-setup browser testing and real agent behavior across multiple models, MCP Playground is free to start. Most developers use both. ### What ports does the MCP Inspector use? The Inspector client UI runs on port 6274 and the MCP proxy server runs on port 6277. The proxy bridges the browser UI to your server over stdio, SSE, or streamable HTTP transports. ### What is the current MCP specification version? The current stable spec is 2025-11-25, which added icons on tools, durable tasks, URL-mode elicitation, and OAuth Client ID Metadata Documents. A 2026-07-28 release candidate with breaking changes is already published for migration planning. ### How do I test a remote MCP server? The fastest way is a browser tool like MCP Playground — paste the URL and go. For local clients that can only speak stdio, use the mcp-remote proxy package to bridge to a remote HTTP endpoint. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-testing-resources-developers-2026 — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # How to Test MCP Servers Effectively: A Step-by-Step Guide > A practical 7-step process for testing MCP servers in 2026 — from the first Inspector connection to evals in CI. Built around the three-layer test pyramid, with the exact commands, gotchas, and the latest spec rules. **Source:** https://mcpplaygroundonline.com/blog/how-to-test-mcp-servers-step-by-step **Author:** Nikhil Tiwari **Published:** 2026-06-06 **Category:** Guide **Reading time:** 12 min read --- 📖 TL;DR — Key Takeaways - To **test MCP servers** effectively, work bottom-up through a three-layer pyramid: unit, integration, then evals - Start every server with the **MCP Inspector** to confirm the handshake, transport, and tool discovery - Integration tests prove your server **responds**; only evals prove it responds **correctly** - Test errors, auth, and edge cases on purpose — the 2025-11-25 spec wants input errors returned as **tool errors, not protocol errors** - Run unit and integration on every push; run evals on a **schedule**, since they're slow and cost credits Most MCP servers pass the "it connected" test and fail the "it works" test. The gap between those two is where production incidents live. I've shipped and broken enough MCP servers to know the difference. The trick to **testing MCP servers** isn't one tool — it's a repeatable order of operations. This guide is that order: seven steps, the exact commands, and the gotchas that bite people in 2026. Skip it and you'll ship a server that demos beautifully and falls over the first time a real model talks to it. 📑 Table of Contents 1. [Why MCP testing is different](#why-different) 2. [The three-layer test pyramid](#test-pyramid) 3. [Step 1: Connect with the Inspector](#step-1-connect) 4. [Step 2: Verify tool discovery](#step-2-discovery) 5. [Step 3: Invoke every tool](#step-3-invoke) 6. [Step 4: Test real agent behavior](#step-4-agent) 7. [Step 5: Test errors & edge cases](#step-5-errors) 8. [Step 6: Test auth & security](#step-6-security) 9. [Step 7: Automate in CI](#step-7-automate) 10. [Common errors to fix](#common-errors) 11. [Testing checklist](#checklist) 12. [FAQ](#faq) ## Why testing MCP servers is different A normal API has one consumer: code you control. An MCP server has a stranger consuming it — a language model that reads your tool descriptions and decides what to do. That changes everything. A tool can return perfect JSON and still fail, because the _model_ misread the description and called it with the wrong arguments. So testing MCP servers means testing two things: your code, and the model's ability to use your code. Most teams test only the first and wonder why agents act weird. ## The three-layer test pyramid The cleanest mental model in 2026 is a three-layer pyramid. Build from the bottom up. 1 **Unit tests — your handlers** Call each tool handler directly, skip the transport. Given an input shape, assert the output shape. Fast and deterministic. 2 **Integration tests — the full pipeline** Drive the server through the real protocol. Confirms the handshake, transport, and tool calls work end to end. Proves it _responds_. 3 **Evals — does the model use it right?** Send prompts to real models and check they pick the right tool with the right arguments. Proves it responds _correctly_. The one line to remember: **integration tests verify the system responds; evals verify it responds correctly.** They're different jobs — don't fake one with the other. ## Step 1: Connect with the MCP Inspector Before any automation, eyeball the server. The [MCP Inspector](https://github.com/modelcontextprotocol/inspector) is the fastest way to see it breathe. ``` npx @modelcontextprotocol/inspector node build/index.js ``` Open the UI on **port 6274**. You're looking for one thing first: a clean connection. Watch the handshake complete and capabilities get negotiated. For a remote server, switch the transport to streamable HTTP and paste the URL. If your local client only speaks stdio, bridge it with the **mcp-remote** proxy. No terminal handy? Paste the URL into [MCP Playground's free test tool](/mcp-test-server) and get the same connection check in the browser. ## Step 2: Verify tool discovery and schemas Once connected, list the tools. Every tool should expose a clear name, a description, and a valid input schema. Check three things on each one: - **Name** — follows the spec's tool-naming guidance, no clashes - **Description** — a human could tell what it does; so could a model - **Schema** — uses JSON Schema 2020-12, the default dialect since the 2025-11-25 spec Vague descriptions are the number-one cause of agents calling the wrong tool. Treat the description as part of your test surface, not documentation. ## Step 3: Invoke every tool manually Now call each tool with realistic arguments. You're verifying the happy path: correct input in, correct shape out. If your server uses **structured tool outputs** (added in the 2025-06-18 spec), confirm the returned data matches the declared output schema — not just a blob of text. This is also where unit tests earn their keep. Call the handler function directly in a test file, assert the output, and you've caught most bugs before the protocol is even involved. ## Step 4: Test real agent behavior Here's the step almost everyone skips. Manual invocation proves _you_ can call the tool. It says nothing about whether a model will. So hand the server to a real model and give it a plain-English task. Watch which tool it picks, what arguments it fills in, and whether it chains calls sensibly. The fastest way to do this without code is [MCP Agent Studio](/mcp-agent-studio). Paste your URL, pick a model, and watch the full agent loop — every tool call shown live with its JSON. See how a real model uses your server Test any MCP server against 15+ frontier models in the browser. Free credits on sign-up. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Open Agent Studio](/mcp-agent-studio) Try the same prompt across two or three models. If a cheaper model picks the right tool, you've found a real cost win. See my [guide to the best model for MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling). ## Step 5: Test errors, edge cases, and validation Happy-path testing is the easy 80%. The incidents come from the other 20%. Feed each tool bad input on purpose: missing fields, wrong types, out-of-range values, and empty results. Then check what comes back. **Spec rule that trips people up:** since 2025-11-25, input validation errors should come back as _tool execution errors_, not protocol errors. That lets the model read the error and self-correct instead of the whole request dying. Also confirm error messages don't leak secrets, stack traces, or internal paths. An over-helpful error is a security finding. ## Step 6: Test authentication and security MCP servers often touch sensitive data. Build security testing in from the start, not after launch. The 2025-11-25 spec made servers OAuth **Resource Servers**. Verify three things: - **Authentication** — valid tokens pass, invalid ones get rejected cleanly - **Authorization** — a token scoped to one resource can't call tools it shouldn't - **Origin checks** — the server returns HTTP 403 for invalid Origin headers on streamable HTTP Then test for tool poisoning and injection. My [OWASP MCP Top 10 walkthrough](/blog/mcp-security-tool-poisoning-owasp-top-10-mcp-scan) covers the attack patterns. Audit your server before you ship Free scan for exposed endpoints, tool poisoning, and auth gaps. [Scan your MCP server →](https://mcpplaygroundonline.com/mcp-security-scanner) ## Step 7: Automate with evals and CI/CD Manual testing finds the first round of bugs. Automation stops them coming back. Wire your unit and integration tests into CI so they run on every push. **FastMCP Client** is built for this — it runs the server in-memory, so tests stay fast and deterministic. Evals are different. They hit real models, cost credits, and aren't deterministic. Run them on a **schedule** — nightly or pre-release — not on every commit. **Good gate design:** unit + integration block the merge; evals report a quality score you watch over time. Don't let a flaky eval block a clean build. ## Common errors and how to fix them Symptom Likely cause Error -32000 / connection closed Server crashed on startup or wrong launch command Tools list is empty Capabilities not declared during initialize HTTP 403 on remote connect Invalid Origin header — check allowed origins Model calls the wrong tool Ambiguous tool name or thin description Timeouts on logging output Writing logs to stdout instead of stderr (stdio transport) For the full debugging playbook, see [MCP server not working? Fix error -32000, timeouts, and connection failures](/blog/mcp-server-troubleshooting-common-errors-fix). ## The MCP testing checklist - ✅ Server connects cleanly in the Inspector - ✅ Every tool has a clear name, description, and valid schema - ✅ Each tool returns the right shape for valid input - ✅ A real model picks the right tool from a plain prompt - ✅ Bad input returns a readable tool error, not a crash - ✅ Auth rejects invalid tokens; origins are validated - ✅ Unit + integration tests run in CI on every push - ✅ Evals run on a schedule and track a quality score - ✅ A security scan came back clean ## Frequently asked questions **What is the fastest way to test an MCP server? +** The fastest first check is the MCP Inspector for local servers, or a browser tool like MCP Playground for remote ones — both confirm the connection, list tools, and let you fire a call in under a minute. Add automated tests once the manual check passes. **What's the difference between integration tests and evals? +** Integration tests verify your server responds through the full protocol pipeline. Evals send prompts to real models and verify the model calls the right tool with the right arguments — they prove it responds correctly, not just that it responds. **How often should I run MCP evals? +** On a schedule, not on every push. Evals are slow, non-deterministic, and cost API credits, so run them nightly or before a release. Use fast unit and integration tests as your per-commit merge gate. **Why does the model keep calling the wrong tool? +** Almost always a vague tool name or thin description. The model only has your metadata to reason from. Tighten the description, add an example in it, and re-test the same prompt in Agent Studio. Run all seven steps in your browser Connect, inspect tools, and test real agent behavior — no install required. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) ## Further Reading - [Ultimate MCP Testing Resources for Developers in 2026](/blog/mcp-testing-resources-developers-2026) - [How QA Teams Should Test MCP Servers](/blog/how-qa-teams-should-test-mcp-servers) - [How to Test Any MCP Server Online — No Setup Required](/blog/how-to-test-mcp-server-online-no-setup-required) - [Fix Error -32000, Timeouts & Connection Failures](/blog/mcp-server-troubleshooting-common-errors-fix) - [What Is the Model Context Protocol (MCP)?](/blog/what-is-model-context-protocol) - [Test MCP Server Online — Free browser tool](/mcp-test-server) 🧪 Need something to test against first? If you are validating a client, an agent framework, or a CI harness, you need a server whose behaviour you already know. The [six hosted mock MCP servers](/mock-mcp-servers) are exactly that — echo, Bearer auth with a real 401 challenge, deliberate errors, deeply nested schemas, MCP Apps, and a stateless 2026-07-28 endpoint. All public URLs, no sign-up. ## Frequently asked questions ### What is the fastest way to test an MCP server? The fastest first check is the MCP Inspector for local servers, or a browser tool like MCP Playground for remote ones — both confirm the connection, list tools, and let you fire a call in under a minute. Add automated tests once the manual check passes. ### What is the difference between integration tests and evals for MCP servers? Integration tests verify your server responds through the full protocol pipeline. Evals send prompts to real models and verify the model calls the right tool with the right arguments — they prove it responds correctly, not just that it responds. ### How often should I run MCP evals? On a schedule, not on every push. Evals are slow, non-deterministic, and cost API credits, so run them nightly or before a release. Use fast unit and integration tests as your per-commit merge gate. ### Why does the model keep calling the wrong tool on my MCP server? Almost always a vague tool name or thin description. The model only has your metadata to reason from. Tighten the description, add an example in it, and re-test the same prompt in Agent Studio. --- _Canonical page: https://mcpplaygroundonline.com/blog/how-to-test-mcp-servers-step-by-step — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # How to Use MCP Agent Studio to Optimize Your AI Workflows > MCP Agent Studio is more than a chat box — it is a tuning bench for AI workflows. Here is how to use it to pick the right model, cut token waste, and design multi-step agents that do not burn credits. **Source:** https://mcpplaygroundonline.com/blog/mcp-agent-studio-optimize-ai-workflows **Author:** Nikhil Tiwari **Published:** 2026-06-06 **Category:** Tutorial **Reading time:** 10 min read --- 📖 TL;DR — Key Takeaways - **MCP Agent Studio** lets you tune an AI workflow before you ship it — model, prompt, tools, and cost in one place - The biggest hidden cost in agents is **token bloat** — tool definitions can eat the majority of a context window before the first message - Use the **token budget tab** to see that cost up front, then prune or tighten tool descriptions - Match the model to the task: a frontier model for hard reasoning, a faster model for routine steps cuts cost dramatically - Compare models on the same server and prompt to find the cheapest one that still picks the right tools Most people use **MCP Agent Studio** as a chat box. They paste a server, ask a question, get an answer, and leave. That's leaving the best part on the table. Agent Studio is really a tuning bench — a place to optimize an AI workflow before it costs you anything in production. In this guide I'll show how to use it to pick the right model, kill token waste, and design multi-step agents that don't burn credits. Get this wrong and a single agent run can quietly cost 10x what it should. Get it right and you ship workflows that are fast and cheap. New to the tool itself? Start with the [MCP Agent Studio complete guide](/blog/mcp-agent-studio-guide), then come back here to optimize. 📑 Table of Contents 1. [What Agent Studio does](#what-it-does) 2. [The token bloat problem](#token-bloat) 3. [Optimize 1: Pick the right model](#model-selection) 4. [Optimize 2: Check the token budget](#token-budget) 5. [Optimize 3: Compare models](#compare-models) 6. [Optimize 4: Tighten tool descriptions](#tool-descriptions) 7. [Optimize 5: Design lean multi-step runs](#multi-step) 8. [A real workflow example](#example) 9. [Cost optimization cheatsheet](#cost-cheatsheet) 10. [FAQ](#faq) ## What MCP Agent Studio does, briefly [MCP Agent Studio](/mcp-agent-studio) connects a frontier model to your MCP server and lets the model drive your tools through a real multi-step conversation. You get three things that matter for optimization: a choice of **70+ models**, a **JSON inspector** on every tool call, and a **token budget tab** that shows cost before you send a message. Those three turn a chat box into a lab. Here's how to run experiments in it. ## The token bloat problem nobody warns you about Here's the problem. Every tool your server exposes ships its full definition into the model's context on every single turn. That adds up fast. In one widely-cited 2026 example, **three MCP servers consumed 143,000 of a 200,000-token context window** — 72% of the model's working memory — before it read the first user message. You pay for those tokens on every turn, and the model has less room left to reason. Bloat is both a cost problem and a quality problem. The fixes are real. Cloudflare's Code Mode cut one workload from 1.17 million tokens to about 1,000. Tool-description compression has trimmed definitions by 72% with no server change. You don't need those heavy techniques to start. You need to _see_ the bloat — which is exactly what Agent Studio shows you. More on the mechanics in my [MCP token counter deep-dive](/blog/mcp-token-counter-optimize-context-window). ## Optimize 1: Pick the right model per task The default instinct is to grab the smartest model for everything. That's the most expensive habit in agent building. The pattern that wins in 2026 is **routing**: a frontier model for the high-stakes steps, a faster, cheaper model for the routine ones. - **High-stakes** (complex reasoning, error recovery) → top-tier model - **Low-stakes** (summarizing a result, formatting, a simple lookup) → fast model With optimized routing, a 10-step agent workflow can run for under $0.05. Agent Studio lets you test that claim against _your_ server before committing. Swap the model in the dropdown, run the same task, and watch whether a cheaper model still nails the tool choice. My [best model for MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling) guide has the head-to-head data. ## Optimize 2: Check the token budget before you run This is the step that pays for itself instantly. Open the **token budget tab** before sending anything. It shows how many tokens your tool definitions consume up front. If a server with 40 tools is eating tens of thousands of tokens, you've found your cost leak. **Quick win:** if a server exposes 40 tools but your workflow only uses 5, that's 35 tool definitions you're paying to send on every turn. Connect a trimmed server, or split it. Seeing the number changes behavior. Teams that watch the token budget tab prune unused tools far more aggressively than teams that don't. See your token cost before you spend a credit Connect any MCP server and watch the budget tab. Free credits on sign-up. [Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Open Agent Studio](/mcp-agent-studio) ## Optimize 3: Compare models side by side Benchmarks tell you which model is smartest in general. They don't tell you which one works best on _your_ server. So test it directly. Run the same prompt against the same server with two or three models and compare three things: - **Did it pick the right tool?** — correctness comes first - **How many steps did it take?** — fewer steps means lower cost - **What did it cost in credits?** — the bottom line The frequent surprise: a mid-tier model matches a frontier one on a well-described server. That's free money — switch and move on. ## Optimize 4: Tighten your tool descriptions Tool descriptions do double duty. They drive correctness _and_ they cost tokens. Both pull toward the same fix: make them clear and tight. Use the JSON inspector to watch how the model interprets each tool. If it picks the wrong one, the description is usually vague — not the model's fault. Rewrite the description, reconnect, and run the same prompt. You'll see the model's choice change in real time. That feedback loop is the whole point of the studio. **Sweet spot:** one crisp sentence on what the tool does, one on when to use it, and explicit argument names. Verbose descriptions cost tokens; vague ones cost correctness. ## Optimize 5: Design lean multi-step workflows Agent Studio runs up to 10 tool-call steps per message. Each step is a full model turn — so every wasted step is wasted money. Watch the step count in the inspector. If a task that should take 3 steps takes 8, the model is fumbling — usually because tools overlap or descriptions are ambiguous. A note on a deeper technique: Anthropic's [code execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp) keeps intermediate results in the execution environment, so the model only sees what's logged — a big context saving for chained calls. You don't need that to start. Just keep prompts specific and tools non-overlapping, and your step count drops on its own. ## A real workflow example Say you've built a Postgres MCP server and want an analytics agent. Here's the optimization pass in Agent Studio. 1 **Check the budget** Open the token budget tab. The server's 12 tools cost ~8k tokens up front — acceptable. 2 **Run the task on a frontier model** "Show me last month's revenue by region." It takes 4 steps and gets it right. Baseline set. 3 **Re-run on a cheaper model** Same prompt, faster model. It takes 5 steps but lands the same answer at a fraction of the cost. 4 **Ship the cheaper model** For this read-only analytics workflow, the cheaper model is the right call. You proved it in minutes. Want the full Postgres build? See [PostgreSQL MCP: build a Claude analytics agent](/blog/postgres-mcp-claude-analytics-agent-recipe). ## Cost optimization cheatsheet - 📊 Read the token budget tab _before_ the first message - ✂️ Connect a server with only the tools the workflow needs - 🔀 Route: frontier model for hard steps, fast model for routine ones - ⚖️ Compare 2–3 models on the same prompt; pick the cheapest that's correct - 📝 One crisp sentence per tool description — clear, not verbose - 🔁 Watch the step count; ambiguous tools inflate it ## Frequently asked questions **How does MCP Agent Studio help optimize AI workflows? +** It lets you test a workflow before production: see token cost in the budget tab, compare 70+ models on the same prompt, inspect every tool call, and watch the step count. You tune model choice and tool descriptions until the workflow is both correct and cheap. **Why do MCP tools use so many tokens? +** Every tool definition is sent into the model's context on each turn. With many servers connected, this adds up fast — one 2026 example saw three servers consume 72% of a 200,000-token window before the first message. The fix is pruning unused tools and tightening descriptions. **Should I use the most powerful model for my MCP agent? +** Not always. Route by stakes: a frontier model for complex reasoning and error recovery, a faster model for routine steps like summarizing or formatting. With smart routing, a 10-step workflow can run for under $0.05. Compare models in Agent Studio to find the cheapest one that still picks the right tools. **Do I need an API key to use MCP Agent Studio? +** No. All models run through MCP Playground's unified gateway, so you don't supply keys for Claude, GPT, Gemini, or any other model. Sign in, get free credits, and start optimizing. Tune your AI workflow before it costs you Compare models, watch token cost, and inspect every tool call. Free credits on sign-up. [Try MCP Agent Studio →](/mcp-agent-studio) [Test any MCP server free](https://mcpplaygroundonline.com/mcp-test-server) ## Further Reading - [MCP Agent Studio: Complete Guide](/blog/mcp-agent-studio-guide) - [MCP Token Counter: Optimize Your Context Window](/blog/mcp-token-counter-optimize-context-window) - [The Best AI Model for MCP Tool Calling](/blog/best-ai-model-for-mcp-tool-calling) - [What Is an MCP Agent?](/blog/what-is-mcp-agent-tool-calling) - [What Is the Model Context Protocol (MCP)?](/blog/what-is-model-context-protocol) - [MCP Agent Studio — Chat with your server](/mcp-agent-studio) ## Frequently asked questions ### How does MCP Agent Studio help optimize AI workflows? It lets you test a workflow before production: see token cost in the budget tab, compare 70+ models on the same prompt, inspect every tool call, and watch the step count. You tune model choice and tool descriptions until the workflow is both correct and cheap. ### Why do MCP tools use so many tokens? Every tool definition is sent into the model context on each turn. With many servers connected, this adds up fast — one 2026 example saw three servers consume 72% of a 200,000-token window before the first message. The fix is pruning unused tools and tightening descriptions. ### Should I use the most powerful model for my MCP agent? Not always. Route by stakes: a frontier model for complex reasoning and error recovery, a faster model for routine steps like summarizing or formatting. With smart routing, a 10-step workflow can run for under $0.05. Compare models in Agent Studio to find the cheapest one that still picks the right tools. ### Do I need an API key to use MCP Agent Studio? No. All models run through MCP Playground unified gateway, so you do not supply keys for Claude, GPT, Gemini, or any other model. Sign in, get free credits, and start optimizing. --- _Canonical page: https://mcpplaygroundonline.com/blog/mcp-agent-studio-optimize-ai-workflows — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Connect Your MCP Server With MiniMax M3 & M2.7 (2026 Guide) > Connect any MCP server to MiniMax M3, M2.7, or M2.5 in about 60 seconds — paste the URL, pick the model, watch every tool call live. Plus the full MiniMax lineup, the OpenAI/Anthropic-compatible API, and how MiniMax\u2019s own MCP server fits in. **Source:** https://mcpplaygroundonline.com/blog/testing-mcp-with-minimax **Author:** MCP Playground **Published:** 2026-06-03 **Updated:** 2026-06-03 **Category:** Tutorial **Reading time:** 12 min read --- 📖 TL;DR — Key Takeaways - **MiniMax M3 shipped June 1, 2026** — an open-weight, natively multimodal agentic model with a **1M-token context** (powered by MiniMax Sparse Attention). It posts **59% on SWE-Bench Pro, 66% on Terminal-Bench 2.1, and 83.5 on BrowseComp**. - The current MCP-capable lineup is `MiniMax-M3`, `MiniMax-M2.7`, `MiniMax-M2.5`, `MiniMax-M2.1`, `MiniMax-M2` and the open-weight reasoning model `MiniMax-M1`. **All of them support function calling** — which is exactly how MCP tools get called. - The chat API is **OpenAI-compatible** at `https://api.minimax.io/v1/chat/completions`, and M3 is also reachable via the **Anthropic SDK (recommended)**. Any MCP client that already talks to GPT or Claude works. - Don\\u2019t confuse the two MCP directions: MiniMax models can _drive_ your MCP servers, and MiniMax also ships its _own_ official MCP server (TTS, voice clone, image, video, music). I cover both below. - Fastest test: paste your MCP URL into [MCP Agent Studio](/mcp-agent-studio), pick **MiniMax M3 / M2.7 / M2.5** from the dropdown, and run your hardest prompt — no MiniMax API key needed. You can **connect any MCP server to MiniMax M3** in about 60 seconds — paste the server URL into [MCP Agent Studio](/mcp-agent-studio), pick `MiniMax M3` (or `M2.7` / `M2.5`) from the model dropdown, and start chatting. Every tool call shows live, no MiniMax key required. **MiniMax M3** landed on June 1, 2026 and pushed MiniMax\\u2019s open-weight stack into frontier territory for agents — strong coding, native multimodality, and a 1M-token window most closed models can\\u2019t match. If your last look at **connecting an MCP server with MiniMax** was on the M1 reasoning model, the agentic story is far better now. This post covers the full lineup, why these models suit MCP, three ways to wire a server up to them, MiniMax\\u2019s own MCP server, and the pitfalls that cost me the most time. ## The MiniMax Model Lineup for MCP (M3, M2.7, M2.5, M1) There are two families that matter for tool calling: the **M2 series** (M2 through M2.7) and the new **M3**. The older **M1** is still worth knowing about. Model (API id) What it is Context Tool calling? **MiniMax-M3** Newest flagship — open-weight, natively multimodal, computer-use, agentic **1M tokens** (min 512K guaranteed) **Yes** — agentic tool use, OpenAI + Anthropic SDK **MiniMax-M2.7** Highest-intelligence M2 model Long context **Yes** **MiniMax-M2.5** Tuned for tool calling and search Long context **Yes** MiniMax-M2.1 Agent-tuned M2 variant Long context Yes MiniMax-M2 Base M2 — MoE, 230B total / 10B active Long context Yes MiniMax-M1 Open-weight hybrid-attention _reasoning_ model **1M tokens** (native) Yes — structured function calling Each M2 model also ships a `-highspeed` variant (for example `MiniMax-M2.7-highspeed`) that trades a little quality for lower latency — handy for high-volume agents. On the Artificial Analysis Intelligence Index, MiniMax reports **M2.7 at 50, M2.5 at 42, and M2.1 at 39** — so M2.7 is the strongest M2 model, and M3 sits above the series for agentic and multimodal work. Naming gotcha MiniMax\\u2019s _generation_ models — `speech-2.8-hd`, `image-01`, `MiniMax-Hailuo-02`, `music-1.5` — are **not** chat models and won\\u2019t call MCP tools. They\\u2019re what MiniMax\\u2019s own MCP server exposes. For driving _your_ MCP servers, use a chat model: `MiniMax-M3`, `MiniMax-M2.7`, or `MiniMax-M2.5`. ## Why MiniMax Models Work Well for MCP MCP tools reach a model as _function definitions_. So any model with solid function calling can drive an MCP server. MiniMax checks three boxes here. ### 1\. OpenAI-Compatible Function Calling MiniMax\\u2019s chat endpoint takes the same `tools` array you already use with GPT — `type: "function"` plus a JSON-Schema `parameters` block. When the model decides to act, it returns `tool_calls` and a `finish_reason` of `tool_calls`. That matters because **MCP\\u2019s `tools/list` maps one-to-one onto that `tools` array**. No custom adapter — the same bridge that wires GPT to MCP wires MiniMax to MCP. ### 2\. A 1M-Token Context on M3 and M1 Long agent loops accumulate tool output fast. M3\\u2019s MiniMax Sparse Attention and M1\\u2019s native 1M window mean a multi-step MCP agent can keep every tool result in context without truncation. For workloads like reading a whole repo through a GitHub MCP server, or scanning a long Postgres schema, that headroom is the difference between one clean run and constant re-summarising. ### 3\. Native Multimodality and Computer-Use on M3 M3 reads images and video and supports computer-use, not just text. So an MCP agent built on M3 can take a screenshot tool\\u2019s output and reason about it directly — a step most text-only models can\\u2019t take. [Connect your MCP server with MiniMax free →](/mcp-agent-studio) ## Connect Your MCP Server With MiniMax — 3 Ways Three ways to wire a server up to MiniMax, ordered by setup time. **Option 1 takes about 60 seconds and needs no code.** ### Option 1 — MCP Playground Agent Studio (60 seconds, no code) This is the path I\\u2019d pick for most people. [MCP Agent Studio](/mcp-agent-studio) handles the model-to-MCP bridge for you, ships MiniMax M3, M2.7 and M2.5 in the model dropdown, and runs the whole agent loop in the browser. No SDK, no MiniMax API key. **Step-by-step:** 1. Open [/mcp-agent-studio](/mcp-agent-studio) and sign in (free credits are added to your account). 2. In the **MCP Servers** panel, click **Add server**. Paste your server URL — Streamable HTTP, SSE, or HTTP. Add a bearer token in the **Headers** field if needed. 3. Click **Connect**. Agent Studio runs `tools/list` and shows every tool it found. If the count looks right, you\\u2019re wired up. 4. In the **Model** dropdown, pick **MiniMax M3** (hardest reasoning + multimodal), **M2.7** (top text quality), or **M2.5** (tool-calling + search, lower cost). 5. Send your first prompt. Every tool call, argument, and result shows inline as the agent runs. No MCP server yet? Head to [/mcp-hosted](/mcp-hosted) and deploy one in a click — Postgres, Stripe, GitHub, MongoDB, Playwright and 35+ more. You get a live HTTPS URL plus bearer token for step 2. ### Option 2 — OpenAI SDK + MiniMax Endpoint Building your own runtime? MiniMax\\u2019s chat API is OpenAI-compatible. Change the base URL and the model name and existing function-calling code routes to MiniMax. ``` from openai import OpenAI client = OpenAI( api_key="...", base_url="https://api.minimax.io/v1", ) response = client.chat.completions.create( model="MiniMax-M3", # or MiniMax-M2.7 / MiniMax-M2.5 messages=[{"role": "user", "content": "List my open GitHub PRs"}], tools=mcp_tools_as_openai_functions, # MCP tools/list -> OpenAI tools[] tool_choice="auto", ) ``` You still bridge MCP\\u2019s `tools/list` into the `tools[]` array, parse each `tool_calls` entry into an MCP `tools/call`, feed the result back, and loop. Agent Studio does all of this for you. ### Option 3 — Anthropic SDK (Recommended for M3) MiniMax recommends the **Anthropic SDK** for M3 specifically — point the base URL at MiniMax, set the model to `MiniMax-M3`, and use the standard Anthropic `tools` format. Any MCP client built around Claude\\u2019s tool-use loop then works unchanged. This is the cleanest path if your stack already speaks the Anthropic Messages API. M3 also accepts plain HTTP requests if you don\\u2019t want an SDK at all. ## The Other Direction: MiniMax\\u2019s Own MCP Server \\u201CConnect MiniMax with MCP\\u201D has a second meaning worth clearing up. MiniMax ships an **official MCP server** — `MiniMax-MCP` — that exposes MiniMax\\u2019s media APIs as MCP tools _to any client_. So Claude, Cursor, Windsurf, Cherry Studio, or the OpenAI Agents SDK can call MiniMax to: - **Text-to-speech** and **voice cloning** (plus a `voice_design` tool that builds a custom voice from a text prompt) - **Image generation** (`image-01`) - **Video generation** (`MiniMax-Hailuo-02`) - **Music generation** (`music-1.5`) It ships in Python (stdio, SSE) and JavaScript (stdio, REST, SSE), configured with your MiniMax API key and base path. There\\u2019s also `MiniMax-Coding-Plan-MCP` — a coding-focused server with AI search and vision analysis tools. Quick way to keep it straight: in **this direction**, MiniMax is the _tool provider_. In the three options above, a MiniMax chat model is the _brain calling the tools_. ## Hands-On: 3 MCP Servers Against MiniMax M3 Three common MCP servers, each with a prompt needing at least three tool calls. I ran every prompt through Agent Studio with M3 selected. ### Test 1: GitHub MCP (Search + Read) Prompt "Find open issues labelled 'bug' across my repos, read the latest comment on each, and summarise the three most urgent." **Result:** M3 called `search_issues`, then fanned out `get_issue_comments` across the matches, and grounded its summary in the actual comment text. The 1M window meant it never dropped an earlier issue from context. ### Test 2: Postgres MCP (Analytical SQL) Prompt "Which 5 products had the biggest month-over-month revenue drop? Show the gap and absolute numbers." **Result:** M3 grounded itself with `list_schemas` and `describe_table` before writing a window-function query. Clean tool arguments across all runs — no malformed JSON on the quoted SQL identifiers. ### Test 3: Multi-MCP — GitHub + Slack Together Prompt "Pull yesterday's merged PRs and post a short roll-up to the #eng channel." **Result:** Two MCP servers connected at once. M3 picked the right tool from each without me labelling them, then composed a tidy Slack message. M2.7 handled the same task on text quality; I reached for M3 when the prompt involved a screenshot. ## MiniMax vs Claude, GPT-5, DeepSeek on MCP Workloads Where MiniMax fits, based on the published specs and my own runs: - **M3 is the open-weight pick for multimodal agents.** Its 83.5 BrowseComp edges Claude Opus 4.7\\u2019s 79.3, and computer-use plus image input is rare in open weights. - **M2.7 is the value play for text-only MCP agents** — strong tool calling without M3\\u2019s multimodal overhead. - **M2.5 leans into tool calling and search**, at lower credit cost — good for high-volume agents. - Claude is still a touch more polished on natural-language final answers; for tool execution itself, M3 holds its own. The honest move is to run the same prompt across MiniMax, Claude and GPT-5 side-by-side and read the tool-call traces. That\\u2019s exactly what Compare mode in Agent Studio is for. ## Pitfalls I Hit With MiniMax + MCP ### 1\. Pick a Chat Model, Not a Media Model Pointing an MCP client at `image-01` or `speech-2.8-hd` won\\u2019t call your tools — those are generation models behind MiniMax\\u2019s own MCP server. Use `MiniMax-M3`, `MiniMax-M2.7`, or `MiniMax-M2.5`. ### 2\. M1 Reasons, But It\\u2019s Not the Agentic Flagship M1 supports function calling and a 1M context, but it\\u2019s a reasoning model from an earlier generation. For new agent builds, M3 and the M2.7/M2.5 pair are the better default. ### 3\. Promo Pricing Is Temporary M3 launched at promo pricing around **$0.30/M input and $1.20/M output**. Model your cost projections on list price, not the launch promo, before you commit a production agent. ### 4\. Match the SDK to the Model M3 is happiest on the Anthropic SDK (MiniMax\\u2019s own recommendation); the M2 series runs fine on the OpenAI SDK. If tool calls misbehave, try the other compatible SDK before assuming the model can\\u2019t do it. ## How MCP Playground Helps - **70+ models in one UI** — MiniMax M3, M2.7, M2.5 plus Claude Opus 4.7 / Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro, DeepSeek V4, Grok, Qwen. No MiniMax API key needed. - **Paste any MCP URL** — works with hosted GitHub, Linear, Vercel, Supabase, Datadog, or your own remote. - **One-click hosted MCP servers** — 40+ pre-configured: Postgres, Stripe, MongoDB, Playwright, Brave Search and more. [Deploy in under a minute](/mcp-hosted). - **Compare mode** — run one prompt across M3, Claude and GPT-5 side-by-side, with full tool-call traces. Test MCP with MiniMax in your browser MiniMax M3 + M2.7 + M2.5 plus 40+ other models. Paste any MCP URL or deploy a hosted server with one click. Free credits on sign-up. [Open Agent Studio →](/mcp-agent-studio) [Deploy hosted MCP →](/mcp-hosted) ## Bottom Line **MiniMax M3 is a genuine open-weight option for MCP agents** — 1M context, native multimodality and computer-use, and an OpenAI/Anthropic-compatible API that drops into any existing MCP client. For text-only agents, M2.7 and M2.5 cover the value end. Keep the two directions straight: MiniMax chat models drive your MCP servers, and MiniMax\\u2019s own MCP server exposes its media APIs to other clients. The fastest way to validate it on _your_ MCP server is [Agent Studio](/mcp-agent-studio) — pick MiniMax M3, M2.7 or M2.5, paste the URL, and run your hardest prompt three times. ## Related Reading - [What Is Model Context Protocol? A Plain-English Guide](/blog/what-is-model-context-protocol) - [Best AI Model for MCP Tool Calling](/blog/best-ai-model-for-mcp-tool-calling) - [Connect Your MCP Server With DeepSeek V4](/blog/testing-mcp-with-deepseek) - [Test Your MCP Server With Qwen Models](/blog/test-mcp-server-with-qwen-models) - [Hosted MCP Server: 7 Real Use Cases](/blog/hosted-mcp-server-use-cases) ## Frequently Asked Questions **Which MiniMax models support MCP / tool calling?** The chat models all support function calling, which is how MCP tools get invoked: `MiniMax-M3`, `MiniMax-M2.7`, `MiniMax-M2.5`, `MiniMax-M2.1`, `MiniMax-M2`, and the open-weight reasoning model `MiniMax-M1`. MiniMax\\u2019s media models (image, speech, video) do not call tools. **When was MiniMax M3 released and what can it do?** June 1, 2026. M3 is an open-weight, natively multimodal agentic model with a 1M-token context (MiniMax Sparse Attention) and computer-use support. Reported benchmarks: 59% SWE-Bench Pro, 66% Terminal-Bench 2.1, and 83.5 BrowseComp. **How do I connect a MiniMax model to my MCP server?** Easiest path: paste the MCP server URL into MCP Agent Studio and pick MiniMax M3, M2.7, or M2.5 from the model dropdown — no key needed. For code, MiniMax\\u2019s chat API is OpenAI-compatible at `https://api.minimax.io/v1/chat/completions` (M3 also supports the Anthropic SDK). Map MCP `tools/list` into the `tools[]` array and loop on `tool_calls`. **Is MiniMax\u2019s MCP server the same as using MiniMax models with MCP?** No — they\\u2019re opposite directions. MiniMax\\u2019s own MCP server (`MiniMax-MCP`) exposes its TTS, voice cloning, image, video and music APIs as tools for any MCP client. Using a MiniMax chat model with MCP means the model is the brain that _calls_ tools from your servers. **M3 vs M2.7 vs M2.5 — which should I use for MCP agents?** Use **M3** for the hardest reasoning, multimodal input, or computer-use. Use **M2.7** for top text quality on text-only agents. Use **M2.5** for tool-calling and search at lower cost on high-volume workloads. Each M2 model also has a `-highspeed` variant for lower latency. **How do I test MiniMax against an MCP server without writing code?** Use [MCP Agent Studio](/mcp-agent-studio). Paste the MCP server URL, pick MiniMax M3, M2.7 or M2.5 from the dropdown, and start chatting. Every tool call and result shows live. Free credits on sign-up — no MiniMax API key required. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work, why the same server behaves differently per model, and what to measure. Other guides in this series: [DeepSeek V4](/blog/testing-mcp-with-deepseek), [Qwen](/blog/test-mcp-server-with-qwen-models), [Gemini](/blog/test-mcp-server-with-gemini-models), [GLM](/blog/test-mcp-server-with-glm-models), [GLM 5.3](/blog/glm-5-3-mcp-servers), [Grok](/blog/testing-mcp-with-grok-xai), [Kimi K2.6](/blog/test-mcp-server-with-kimi-k2-6). ## Frequently asked questions ### Which MiniMax models support MCP and tool calling? The chat models all support function calling, which is how MCP tools get invoked: MiniMax-M3, MiniMax-M2.7, MiniMax-M2.5, MiniMax-M2.1, MiniMax-M2, and the open-weight reasoning model MiniMax-M1. MiniMax media models like image-01 and speech-2.8-hd do not call tools. ### When was MiniMax M3 released and what can it do? June 1, 2026. M3 is an open-weight, natively multimodal agentic model with a 1M-token context powered by MiniMax Sparse Attention, plus computer-use support. Reported benchmarks: 59% SWE-Bench Pro, 66% Terminal-Bench 2.1, and 83.5 BrowseComp. ### How do I connect a MiniMax model to my MCP server? Easiest path: paste the MCP server URL into MCP Agent Studio and pick MiniMax M3, M2.7, or M2.5 from the dropdown, no key needed. For code, the chat API is OpenAI-compatible at https://api.minimax.io/v1/chat/completions and M3 also supports the Anthropic SDK. Map MCP tools/list into the tools array and loop on tool_calls. ### Is MiniMax own MCP server the same as using MiniMax models with MCP? No, they are opposite directions. MiniMax own MCP server (MiniMax-MCP) exposes its text-to-speech, voice cloning, image, video and music APIs as tools for any MCP client. Using a MiniMax chat model with MCP means the model is the brain that calls tools from your servers. ### M3 vs M2.7 vs M2.5 — which should I use for MCP agents? Use M3 for the hardest reasoning, multimodal input, or computer-use. Use M2.7 for top text quality on text-only agents. Use M2.5 for tool-calling and search at lower cost on high-volume workloads. Each M2 model also has a -highspeed variant for lower latency. ### How do I test MiniMax against an MCP server without writing code? Use MCP Playground Agent Studio at /mcp-agent-studio. Paste the MCP server URL, pick MiniMax M3, M2.7 or M2.5 from the dropdown, and start chatting. Every tool call is shown live, free credits on sign-up, no MiniMax API key required. --- _Canonical page: https://mcpplaygroundonline.com/blog/testing-mcp-with-minimax — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Test MCP With Grok (xAI): Setup Guide for Grok 4.3 + Remote MCP Tools (2026) > Connect any MCP server to Grok 4.3 — using xAI’s Remote MCP Tools, the OpenAI-compatible Responses API, Grok Build CLI, or the Grok Connectors UI. Step-by-step code, real limits, and how Grok stacks up against Claude and GPT-5.4 in May 2026. **Source:** https://mcpplaygroundonline.com/blog/testing-mcp-with-grok-xai **Author:** Nikhil Tiwari **Published:** 2026-05-29 **Updated:** 2026-05-29 **Category:** Tutorial **Reading time:** 14 min read --- 📖 TL;DR — Test MCP with Grok (May 2026) - **Grok 4.3** (live on the xAI API since May 5, 2026) supports **Remote MCP Tools** natively — in the xAI SDK, the OpenAI-compatible Responses API, and the Voice Agent API. - Configure it by adding `{"type": "mcp", "server_url": "…", "server_label": "…"}` to your `tools` array. Only **Streamable HTTP and SSE** transports are supported. - **Grok Build** (xAI’s terminal CLI, GA May 25, 2026) ships with MCP compatibility — any MCP server you wired for Claude Code works with zero changes. - For point-and-click setup, use **grok.com/connectors → New Connector → Custom** and paste your MCP server URL. - **1M-token context**, **128 tools per request**, **parallel tool calls** by default — Grok 4.3 is the cheapest frontier-tier model with native MCP support. I spent the last week wiring MCP servers into Grok across all three xAI surfaces — the API, the new Grok Build CLI, and the grok.com Connectors UI. If you already test MCP servers against Claude or GPT-5, the punchline is short: **you can test MCP with Grok today, and Grok 4.3 is the cheapest model in the frontier tier that supports it natively**. This guide is the fast path — every code sample is copy-pasteable, every limit is from the official [xAI Remote MCP docs](https://docs.x.ai/developers/tools/remote-mcp), and everything was verified against the May 2026 release notes. If you want to skip the API plumbing entirely, the free [MCP Agent Studio](/mcp-agent-studio) lets you point Grok 4.3 at any MCP server in your browser with no keys. 📑 Table of Contents 1. [What changed: Grok + MCP in May 2026](#whats-new) 2. [Grok 4.3 specs that matter for MCP](#grok-43-specs) 3. [Four ways to test MCP with Grok](#four-ways) 4. [Method 1 — xAI native SDK](#native-sdk) 5. [Method 2 — OpenAI-compatible Responses API](#responses-api) 6. [Method 3 — Grok Build CLI](#grok-build) 7. [Method 4 — Grok Connectors UI](#connectors-ui) 8. [How MCP Playground helps](#playground) 9. [Limitations and gotchas](#limits) 10. [Grok vs Claude vs GPT-5.4 for MCP](#vs-claude-gpt) 11. [FAQ](#faq) ## 1\. What changed: Grok and MCP in May 2026 If you last tried wiring Grok to MCP in 2025, the answer was “not really” — tool calling worked, but MCP servers needed a wrapper. That shipped fast in May 2026: - **May 5, 2026** — **Grok 4.3** goes live on the xAI API with a 1M-token context window, 128 tools per request, and parallel tool calls by default. - **May 14, 2026** — **Grok Build** beta launches: a terminal-native agentic CLI with up to 8 parallel sub-agents and native MCP support. - **May 15, 2026** — **grok-code-fast-1 deprecated**; requests are routed to `grok-build-0.1` ($0.20/M input tokens). Full retirement on August 15, 2026. - **May 25, 2026** — Grok Build expands to all SuperGrok and X Premium+ subscribers. - **Remote MCP Tools** are now supported across **three xAI APIs**: the native SDK, the OpenAI-compatible Responses API, and the Voice Agent API. In short, MCP is no longer a side-quest on xAI. It is a first-class capability. If you want the broader 2026 protocol picture, see [the MCP 2026 roadmap](/blog/mcp-2026-roadmap-whats-changing-for-developers). ## 2\. Grok 4.3 specs that matter for MCP Most model specs do not matter for MCP work. **These five do**: Spec Grok 4.3 Why it matters for MCP Context window 1,000,000 tokens Big MCP toolsets and long tool-result chains fit without truncation. Tools per request Up to 128 Enough for ~5–6 MCP servers connected at once. Parallel tool calls Default on Independent MCP calls run concurrently — fewer round trips. MCP transports Streamable HTTP, SSE No STDIO from the API — your MCP server must be reachable on the public internet. APIs that accept MCP xAI SDK, Responses, Voice Agent Same MCP config works in three places, including voice agents. Sources: [docs.x.ai/developers/models/grok-4.3](https://docs.x.ai/developers/models/grok-4.3) and [docs.x.ai/developers/tools/remote-mcp](https://docs.x.ai/developers/tools/remote-mcp), retrieved May 29, 2026. ## 3\. Four ways to test MCP with Grok Pick the surface that matches your goal: 1. **xAI native SDK** — best for production code in Python or TypeScript. 2. **OpenAI-compatible Responses API** — best if your codebase already speaks OpenAI. 3. **Grok Build CLI** — best for terminal-native agentic coding loops. 4. **grok.com Connectors UI** — best for zero-code one-off testing. Below is the exact configuration for each. All four use the same MCP server — I'll use the public `https://mcp.deepwiki.com/mcp` server as a reference because it is the example in xAI’s own docs. ## 4\. Method 1 — Remote MCP Tools via the xAI native SDK The cleanest path. Drop your MCP server into the `tools` array and Grok handles discovery, schema injection, and parallel calls. ### Required and optional MCP parameters Field Status Purpose `server_url` Required The MCP server endpoint. Streamable HTTP or SSE only. `server_label` Required Identifier prefixed onto tool calls. Use a short, descriptive name. `server_description` Optional Free-text hint about what the server does. Helps Grok pick the right tools. `allowed_tools` Optional Subset of tool names to expose. Empty means all. `authorization` Optional Bearer token sent in the Authorization header. `headers` Optional Extra HTTP headers for the MCP server. ### Python example ``` from xai_sdk import Client from xai_sdk.chat import user client = Client(api_key="YOUR_XAI_KEY") chat = client.chat.create( model="grok-4.3", tools=[{ "type": "mcp", "server_url": "https://mcp.deepwiki.com/mcp", "server_label": "deepwiki", "server_description": "DeepWiki docs lookup for any public GitHub repo.", }], ) chat.append(user("What does the modelcontextprotocol/python-sdk repo do?")) print(chat.sample().content) ``` Grok 4.3 will discover the server’s tools, call them in parallel where independent, and surface a final answer. **You do not need to ship any tool definitions yourself**. ### Connecting multiple MCP servers at once ``` tools=[ {"type": "mcp", "server_url": "https://mcp.deepwiki.com/mcp", "server_label": "deepwiki"}, {"type": "mcp", "server_url": "https://your-postgres-mcp.example.com/sse", "server_label": "postgres", "authorization": "YOUR_DB_TOKEN", "allowed_tools": ["query", "list_tables"]}, ] ``` Stay under **128 total tools** across all servers — Grok silently drops the trailing tools over the cap. Use `allowed_tools` to keep the toolset tight. ⚠️ Common mistake Pointing `server_url` at a STDIO-only MCP server. From the xAI API, only Streamable HTTP and SSE work. If you have a STDIO server, host it behind a Streamable HTTP wrapper first — our [deployment guide](/blog/deploy-mcp-server-vercel-railway-render-heroku-flyio) covers five free options. ## 5\. Method 2 — OpenAI-compatible Responses API If your code already targets OpenAI’s Responses API, you can swap the base URL and keep the same MCP config. Grok’s implementation mirrors OpenAI’s tool schema with one caveat. ⚠️ Not supported (May 2026) The `require_approval` and `connector_id` parameters from OpenAI’s Responses API are **not currently supported** by xAI’s implementation. Send them and the call still works — they just get ignored. ``` from openai import OpenAI client = OpenAI( api_key="YOUR_XAI_KEY", base_url="https://api.x.ai/v1", ) response = client.responses.create( model="grok-4.3", input="List the open issues on modelcontextprotocol/typescript-sdk", tools=[{ "type": "mcp", "server_url": "https://mcp.deepwiki.com/mcp", "server_label": "deepwiki", }], ) print(response.output_text) ``` Use HTTPS, set a descriptive `server_label`, and — if you already use Grok’s built-in tools — know that `web_search`, `x_search`, and `code_interpreter` execute server-side on xAI infrastructure. Your MCP tools run on your own server. If you want a deeper comparison of MCP vs raw function calling, see [MCP vs function calling vs REST APIs](/blog/mcp-vs-function-calling-vs-api-comparison). Test any MCP server with Grok 4.3 — no API key required Paste any MCP URL into MCP Playground and switch between Grok 4.3, Claude, GPT-5.4, and 30+ other models in one tab. [Test an MCP server free →](/mcp-test-server) ## 6\. Method 3 — Grok Build CLI (terminal-native MCP) **Grok Build** is xAI’s answer to Claude Code: a terminal-native agentic CLI with up to 8 parallel sub-agents, a plan-first execution loop, and native MCP support. It launched in beta May 14 and rolled out to all SuperGrok and X Premium+ subscribers on May 25, 2026. The big win: **any MCP server you already configured for Claude Code works with Grok Build with zero reconfiguration** — GitHub, Linear, Slack, your internal DB, your CI system. If you have a `.mcp.json` or a `claude_desktop_config.json`, Grok Build can read it. ### Underlying model and pricing - Coding model: `grok-build-0.1` - Pricing: **$0.20 per million input tokens** - Replaces the deprecated `grok-code-fast-1`, which retires August 15, 2026 If your existing MCP config already powers [Claude Code](/blog/claude-code-mcp-setup-best-servers-guide), point Grok Build at the same file and run. ## 7\. Method 4 — Grok Connectors UI (zero-code custom MCP) For one-off testing or non-engineering users, xAI shipped _Bring Your Own MCP_ inside the Grok web app. Steps: 1. Open [grok.com/connectors](https://grok.com/connectors). 2. Click **New Connector**. 3. Select **Custom**. 4. Paste the MCP **server URL** and complete any auth flow the server prompts for. 5. Grok discovers the tools and exposes them in your next chat. Built-in connectors already cover SharePoint, Outlook, OneDrive, Google Workspace, Notion, GitHub, and Linear. The Custom flow is for everything else — your homegrown MCP server, an internal MCP gateway, or any third-party MCP endpoint. **Key requirement:** the MCP server must be reachable on the public internet. For local servers, run a tunnel (`ngrok`, `cloudflared`) or deploy to a host. We list five free options in [where to host MCP servers for free](/blog/free-mcp-server-hosting-cloudflare-vercel-guide). ## 8\. How MCP Playground helps you test Grok faster Wiring API keys for a one-off test is a lot of ceremony. [MCP Agent Studio](/mcp-agent-studio) lets you paste any MCP server URL, pick **Grok 4.3** from the model dropdown, and start chatting in seconds — no xAI key, no SDK install. Every tool call, argument, and response is visible in the run log so you can debug schema or auth issues against the same model you’ll ship. Better still, you can swap to Claude Opus 4.6, GPT-5.4, or 30+ other models against the same MCP server in the same session — useful when you’re choosing which model to commit to. Free credits on sign-up. ## 9\. Limitations and gotchas (May 2026) Three things will trip you up on day one: 1. **STDIO is not supported from the API.** The API expects Streamable HTTP or SSE. If your MCP server runs over STDIO (the default for many Python and Node templates), wrap it in a Streamable HTTP transport. 2. **OpenAI Responses parity is incomplete.** `require_approval` and `connector_id` are silently dropped. If you depend on human-in-the-loop approval, implement it in your application layer. 3. **128 tools is a hard ceiling.** Tools above 128 are dropped. If you connect three large MCP servers (each with 60+ tools), use `allowed_tools` to whitelist what you actually need. There are also the usual operational concerns — token-budget bloat from long tool schemas and prompt injection via MCP tool descriptions. If you’re shipping Grok agents to production, run the [MCP security scanner](/mcp-security-scanner) against every server you connect, and read [safeguarding MCP servers from prompt injection](/blog/safeguarding-mcp-servers-from-prompt-injection) first. ## 10\. Grok 4.3 vs Claude vs GPT-5.4 for MCP tool calling Where does Grok land? The April 2026 benchmarks tell a clear story — GPT-5.4 and GLM-5.1 lead pure MCP tool-calling benchmarks, Claude Opus 4.6 leads real-world agentic work, and Grok 4.3 is the value play. Model Context Native MCP in API Best at Grok 4.3 1M Yes (3 surfaces) Cheapest frontier-tier MCP, voice agents Claude Opus 4.6 200k Yes (`mcp_servers`) Real-world agentic work (SWE-bench 80.8%) GPT-5.4 1M Yes (Responses) Best all-rounder, leads BenchLM at 89.3 Gemini 3.1 Pro 1M+ Yes (ADK v2.0) Cross-server orchestration (69.2% MCP-Atlas) For the full 30+ model leaderboard with prices, see [best AI model for MCP tool calling in 2026](/blog/best-ai-model-for-mcp-tool-calling). The short version: **start with Grok 4.3 when cost matters, switch to Claude or GPT-5.4 when reliability on multi-step workflows matters more**. ## 11\. FAQ **Does Grok support MCP?** Yes. As of May 2026, Grok 4.3 supports **Remote MCP Tools** natively in the xAI SDK, the OpenAI-compatible Responses API, and the Voice Agent API. Grok Build (the CLI) also speaks MCP natively. Only Streamable HTTP and SSE transports are accepted — STDIO is not. **How do I connect a custom MCP server to Grok without writing code?** Go to [grok.com/connectors](https://grok.com/connectors), click **New Connector → Custom**, paste the MCP server URL, finish any auth flow, and Grok will discover and expose the server’s tools in your next chat. The server must be reachable on the public internet. **What models on xAI support MCP?** `grok-4.3` is the documented model for Remote MCP Tools across the SDK, Responses API, and Voice Agent API. `grok-build-0.1` powers Grok Build CLI and also speaks MCP. `grok-code-fast-1` was deprecated on May 15, 2026 — requests now route to `grok-build-0.1`. **How many MCP tools can Grok 4.3 handle in one request?** Up to **128 tools per request** across all connected MCP servers, with parallel tool calls on by default. Exceeding the cap silently drops trailing tools — use `allowed_tools` to keep each server’s exposed set tight. **Can I use Grok with the same MCP config as Claude Code?** Yes. Grok Build is designed for drop-in compatibility — any MCP server already configured for Claude Code (GitHub, Linear, Slack, internal DBs, CI) works with zero reconfiguration. For Claude Code config locations, see our [Claude Code MCP setup guide](/blog/claude-code-mcp-setup-best-servers-guide). **Why does my Responses API call ignore require_approval?** xAI’s implementation of the OpenAI-compatible Responses API does **not currently support** `require_approval` or `connector_id`. The call still succeeds, but those fields are dropped. Implement approval flows in your application layer for now. **How do I test Grok against an MCP server without an xAI key?** Use [MCP Agent Studio](/mcp-agent-studio). Paste the MCP server URL, pick Grok 4.3 from the model dropdown, and start chatting — no xAI key needed. Every tool call and response is logged. Free credits on sign-up. ## Wrapping up Grok 4.3 lands MCP support across **three APIs and one CLI**, with the cheapest frontier pricing and a 1M-token context. The setup is short: drop your MCP server URL in the `tools` array, mind the Streamable HTTP / SSE constraint, and stay under 128 tools. If you’re deciding between Grok and Claude or GPT-5.4 for a real MCP workload, the fastest answer is to run the same task against all three. [MCP Agent Studio](/mcp-agent-studio) lets you swap models against one MCP server in a single browser tab — free to start. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work, why the same server behaves differently per model, and what to measure. Other guides in this series: [DeepSeek V4](/blog/testing-mcp-with-deepseek), [Qwen](/blog/test-mcp-server-with-qwen-models), [Gemini](/blog/test-mcp-server-with-gemini-models), [GLM](/blog/test-mcp-server-with-glm-models), [GLM 5.3](/blog/glm-5-3-mcp-servers), [Kimi K2.6](/blog/test-mcp-server-with-kimi-k2-6), [MiniMax](/blog/testing-mcp-with-minimax). ## Frequently asked questions ### Does Grok support MCP? Yes. As of May 2026, Grok 4.3 supports Remote MCP Tools natively in the xAI SDK, the OpenAI-compatible Responses API, and the Voice Agent API. Grok Build CLI also speaks MCP natively. Only Streamable HTTP and SSE transports are accepted from the API. ### How do I connect a custom MCP server to Grok without writing code? Go to grok.com/connectors, click New Connector and choose Custom, paste the MCP server URL, finish any auth flow, and Grok will discover and expose the server tools in your next chat. The server must be reachable on the public internet. ### What models on xAI support MCP? grok-4.3 is the documented model for Remote MCP Tools across the SDK, Responses API, and Voice Agent API. grok-build-0.1 powers Grok Build CLI and also speaks MCP. grok-code-fast-1 was deprecated on May 15, 2026, with requests routed to grok-build-0.1. ### How many MCP tools can Grok 4.3 handle in one request? Up to 128 tools per request across all connected MCP servers, with parallel tool calls on by default. Exceeding the cap silently drops trailing tools, so use the allowed_tools field to keep each server exposed set tight. ### Can I use Grok with the same MCP config as Claude Code? Yes. Grok Build is designed for drop-in compatibility. Any MCP server already configured for Claude Code, including GitHub, Linear, Slack, internal databases, and CI systems, works with zero reconfiguration. ### Why does my Responses API call ignore require_approval? xAI implementation of the OpenAI-compatible Responses API does not currently support require_approval or connector_id. The call still succeeds, but those fields are dropped. Implement approval flows in your application layer for now. ### How do I test Grok against an MCP server without an xAI key? Use MCP Agent Studio at /mcp-agent-studio. Paste the MCP server URL, pick Grok 4.3 from the model dropdown, and start chatting without an xAI key. Every tool call and response is logged. Free credits on sign-up. --- _Canonical page: https://mcpplaygroundonline.com/blog/testing-mcp-with-grok-xai — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Claude Creative Connectors: Adobe, Blender, Ableton & 6 More (2026 Guide) > On April 28, 2026 Anthropic shipped 9 Claude connectors for creative tools — Adobe (50+ apps), Blender, Ableton, Splice, Autodesk Fusion, SketchUp, Affinity by Canva, and both Resolume apps. What each does, how to install, and how to reuse them with any MCP client. **Source:** https://mcpplaygroundonline.com/blog/claude-creative-connectors-adobe-blender-ableton **Author:** Nikhil Tiwari **Published:** 2026-05-29 **Updated:** 2026-05-29 **Category:** Guide **Reading time:** 13 min read --- 📖 TL;DR — Claude creative connectors - On **April 28, 2026** Anthropic released **nine Claude connectors** for creative software — all built on the **Model Context Protocol**. - The nine: **Adobe** (50+ Creative Cloud tools), **Blender**, **Ableton**, **Splice**, **Autodesk Fusion**, **SketchUp**, **Affinity by Canva**, **Resolume Arena**, and **Resolume Wire**. - The Adobe connector is the first time Adobe has exposed **50+ pro tools across Photoshop, Premiere, Lightroom, Illustrator, InDesign, Express, Firefly, and Adobe Stock** to a third-party AI assistant. - Because they’re MCP servers, they work with **any MCP-compatible client** — Claude, Cursor, VS Code, Windsurf, Grok, ChatGPT. - Anthropic became a **Blender Development Fund patron** to support the Python API the Blender connector depends on. For about two years MCP has lived inside developer tools — IDEs, CLIs, dashboards. **That changed on April 28, 2026**, when Anthropic shipped nine Claude connectors aimed squarely at creative professionals. The headline name is Adobe, but the more interesting story is that all nine are MCP servers — which means you can wire them into Cursor, VS Code, Grok, or any MCP client, not just Claude. This guide breaks down what each connector does, how to install them, what limits are public as of May 2026, and where MCP Playground fits if you want to [test them against your own MCP clients](/mcp-test-server) before committing. 📑 Table of Contents 1. [What Anthropic announced](#announcement) 2. [The nine connectors at a glance](#nine) 3. [Adobe — 50+ Creative Cloud tools](#adobe) 4. [Blender — Python API meets natural language](#blender) 5. [Ableton + Splice for music](#music) 6. [Autodesk Fusion + SketchUp for 3D](#3d) 7. [Affinity by Canva + Resolume](#affinity) 8. [They’re MCP servers — use them anywhere](#mcp-clients) 9. [How to install](#install) 10. [Limits and gotchas](#limits) 11. [FAQ](#faq) ## 1\. What Anthropic announced on April 28, 2026 Anthropic’s [Claude for Creative Work](https://www.anthropic.com/news/claude-for-creative-work) post introduced nine new connectors that plug Claude into the software creative professionals already use daily. Three things make the launch notable: 1. **Industrial partnerships, not scraped APIs.** Adobe, Autodesk, Blender, Ableton, and Splice are launch partners. Adobe’s connector covers 50+ tools across Creative Cloud — the first time Adobe has exposed that many professional features to a third-party AI assistant. 2. **Everything is MCP.** Each connector is a Model Context Protocol server. Because MCP is an open standard, the same servers work with any MCP-compatible client — not just Claude. 3. **Anthropic became a Blender Development Fund patron.** The Blender connector relies on Blender’s Python API, and Anthropic made a one-time donation to support its continued development. Alongside the connector launch, Anthropic announced education access for three schools — **Rhode Island School of Design (RISD)**, **Ringling College of Art and Design**, and **Goldsmiths University London**. New to MCP itself? Start with [What is the Model Context Protocol](/blog/what-is-model-context-protocol). ## 2\. The nine connectors at a glance Connector Domain What it does Adobe for creativity Design / video 50+ tools across Photoshop, Premiere, Lightroom, Illustrator, InDesign, Express, Firefly, Adobe Stock. Blender 3D Natural-language access to the Blender Python API — analyse scenes, batch-edit, build custom tools. Ableton Music Grounds Claude in official Live and Push documentation. Splice Music Search Splice’s royalty-free sample catalog from inside Claude. Autodesk Fusion 3D / CAD Create and modify 3D models through conversation. Subscription required. SketchUp 3D Turn descriptions into 3D modelling starting points for refinement. Affinity by Canva Design Automate batch adjustments, layer renaming, file exports. Resolume Arena VJ / visuals Real-time VJ and live visual control via natural language. Resolume Wire AV production Real-time AV production control via natural language. Source: [anthropic.com/news/claude-for-creative-work](https://www.anthropic.com/news/claude-for-creative-work), April 28, 2026. ## 3\. Adobe — 50+ Creative Cloud tools from one prompt The Adobe for creativity connector is the most ambitious of the nine. Anthropic and Adobe’s announcement frames it as a single conversational surface over Adobe’s pro stack: **you type a goal, Claude decides which Adobe app to invoke, in what order, with what parameters**. The exposed tools come from eight Adobe products: - **Photoshop** — photo retouching and image manipulation - **Lightroom** — batch colour adjustments - **Illustrator** — vector work - **Premiere** — video editing - **InDesign** — publishing layout - **Express** — social templates - **Firefly** — generative AI - **Adobe Stock** — royalty-free assets Adobe’s blog framed it as _the first industrial agreement in which Adobe exposes more than 50 professional tools to a third-party AI assistant_. For comparison, single-app MCP wrappers like Photoshop-only MCP servers existed before — what changed is the breadth and the partnership. If you want to understand the difference between this kind of high-trust integration and a raw API wrapper, see [MCP vs REST API — what’s different](/blog/mcp-vs-rest-api-whats-different). ## 4\. Blender — natural language over the Python API The Blender connector is technically the most interesting. Instead of wrapping a fixed list of commands, it gives Claude a natural-language interface to **Blender’s Python API** — the same API that powers every Blender add-on. What that unlocks: - **Analyse entire scenes** — Claude can introspect objects, materials, and modifiers, then explain or debug. - **Batch-apply changes** — “rename every mesh in this collection” or “convert all materials to principled BSDF” become single prompts. - **Add tools to Blender’s UI** — the connector can write Python scripts that register new operators directly inside Blender. Anthropic joined the **Blender Development Fund** as a corporate patron alongside this release, specifically citing support for the Python API. That detail matters: it signals long-term commitment to the surface the connector depends on. ## 5\. Ableton + Splice for music production Two of the nine are music-focused, and they target different parts of the workflow. ### Ableton — grounded answers The official Ableton connector is documentation-focused: it grounds Claude’s answers in **official product documentation for Live and Push**. Translation — when you ask “how do I sidechain a kick to a bassline in Live 12?”, Claude pulls from the canonical docs rather than guessing from training data. 📌 Heads-up Anthropic’s official Ableton connector is **not** the same thing as the popular community `ahujasid/ableton-mcp` server, which directly controls Ableton Live (create tracks, fire clips, set tempo). If you want direct Live control today, the community server is mature; if you want grounded docs answers from Anthropic, use the official connector. ### Splice — sample search inside Claude The Splice connector exposes **search over Splice’s royalty-free sample catalog** directly inside Claude. A producer can ask “find me a melancholy 80 BPM piano loop in F minor” without leaving the chat. ## 6\. Autodesk Fusion + SketchUp for 3D and CAD Two integrations target the CAD/3D world from different angles. **Autodesk Fusion** — the most product-action-heavy of the three CAD/3D connectors. Subscription holders can **create and modify 3D models through conversation** — extruding sketches, applying constraints, generating parametric variants — without opening the Fusion UI. **SketchUp** — geared at the ideation stage. The connector converts text descriptions into **3D modelling starting points**, which you then refine inside SketchUp. Less control, more speed for the first 30 seconds of a project. If your team builds 3D agents and wants to compare these against community Blender or CAD MCPs, our [Awesome MCP Servers catalog](/blog/awesome-mcp-servers) tracks live-tested third-party servers. ## 7\. Affinity by Canva + Resolume **Affinity by Canva** targets the repetitive-task end of the design workflow. Batch colour adjustments, layer renaming across hundreds of files, automated file exports — the “I’ll write a script some day” jobs designers normally never finish. **Resolume Arena** and **Resolume Wire** are the niche standouts — VJ and AV production software. Real-time visual control via natural language unlocks new workflows for live performers: triggering clips, modulating effects, switching scenes mid-show without keyboard-juggling. Build with these connectors — and any other MCP server Test creative MCP servers and your own MCP integrations in MCP Playground. No setup. No SDK install. Free. [Test any MCP server free →](/mcp-test-server) ## 8\. They’re MCP servers — so they work outside Claude too The under-reported headline: every one of these connectors is an MCP server. Because MCP is an open standard, **they work with any MCP-compatible client**: - **Claude** — the launch surface, install via Claude’s Customize panel. - **Cursor** — wire up via [Cursor’s mcp.json](/blog/cursor-mcp-setup-guide). - **VS Code, Windsurf** — same MCP client surface. - **Grok 4.3** — paste the server URL into [Grok’s Connectors UI](/blog/testing-mcp-with-grok-xai) or pass it to the xAI SDK. - **ChatGPT** — through the [OpenAI Agents SDK](/blog/chatgpt-mcp-openai-agents-sdk-setup-guide). If your team uses a different model for compliance, cost, or latency reasons, the creative connectors don’t lock you in. That’s the protocol working as designed. ## 9\. How to install ### In Claude (desktop or web) 1. Open Claude. 2. Click the **Customize** panel. 3. Pick the connector — Adobe, Blender, Ableton, Splice, Autodesk Fusion, SketchUp, Affinity, Resolume Arena, or Resolume Wire. 4. Complete the OAuth flow for that product (Adobe ID, Autodesk account, etc.). 5. Start a new conversation — the connector’s tools are now available to Claude. ### In another MCP client Because these connectors are MCP servers, you can register their endpoint in any client. The exact URLs and auth flows are surfaced inside Claude’s connector panel — copy them and add them to your client’s MCP config. Cursor and VS Code accept the same Streamable HTTP/SSE servers; the config locations are covered in our [complete guide to MCP config files](/blog/complete-guide-mcp-config-files-claude-desktop-cursor-lovable). ## 10\. Limits and gotchas (May 2026) - **Subscription products still need subscriptions.** The Autodesk Fusion connector works for active Fusion subscribers; the Adobe connector assumes a Creative Cloud account. The connectors don’t bypass licensing. - **Ableton’s official connector is docs-only.** If you want Claude to directly control a Live session (create tracks, fire clips), use the `ahujasid/ableton-mcp` community server or a similar one. - **Anthropic did not publish exact tool counts** for each connector beyond Adobe’s 50+. Treat counts inside the Customize panel as the ground truth. - **OAuth scope sprawl.** Adobe’s connector covers eight apps — review what scopes you grant before approval. - **Prompt injection risk.** Any MCP server can ship malicious tool descriptions. Audit creative connectors the same way you’d audit any other server — see [MCP security in 2026](/blog/mcp-security-tool-poisoning-owasp-top-10-mcp-scan). ## FAQ **When were the Claude creative connectors released?** April 28, 2026. Anthropic announced nine connectors covering Adobe Creative Cloud, Blender, Ableton, Splice, Autodesk Fusion, SketchUp, Affinity by Canva, Resolume Arena, and Resolume Wire. **Which Adobe apps does the Claude connector cover?** Anthropic and Adobe describe **50+ tools across eight apps**: Photoshop, Lightroom, Illustrator, Premiere, InDesign, Express, Firefly, and Adobe Stock. Anthropic has not published an exhaustive per-tool list as of May 2026. **Can I use the connectors with Cursor, VS Code, or Grok instead of Claude?** Yes. The connectors are built on the open Model Context Protocol, so any MCP-compatible client — Cursor, VS Code, Windsurf, Grok, ChatGPT via the OpenAI Agents SDK — can use them. Anthropic confirmed this in the announcement. **Does the Ableton connector let Claude control Ableton Live directly?** No. Anthropic’s official Ableton connector grounds Claude’s answers in Live and Push documentation — it is a docs-search connector. For direct DAW control (create tracks, fire clips, change tempo), use the community `ahujasid/ableton-mcp` server. The two can coexist. **Do I need an Adobe subscription to use the Adobe connector?** Yes. The connector does not bypass licensing. Tools in Photoshop, Premiere, Illustrator, and the other paid Creative Cloud apps require an active subscription. Free apps in the bundle (Express tier, Firefly free tier) are still subject to their own usage limits. **What does Anthropic’s Blender Development Fund patronage mean?** Anthropic made a one-time donation to the Blender Development Fund as part of the connector launch, with stated support for continued development of the Python API the connector relies on. It is not an ongoing recurring sponsorship that has been publicly disclosed. **How do I install a Claude creative connector?** Open Claude, go to the **Customize** panel, pick the connector, complete the partner’s OAuth flow (Adobe ID, Autodesk account, etc.), and start a new conversation. The connector’s tools are then available to Claude. ## Wrapping up The April 28, 2026 launch is the moment MCP crossed from _developer infrastructure_ into _professional creative tooling_. Nine connectors, real industrial partnerships, and — because everything is MCP — full portability across Cursor, VS Code, Grok, and ChatGPT. If you’re evaluating which connector to wire into your workflow first, try a few against the same prompt in [MCP Agent Studio](/mcp-agent-studio) — it’s the fastest way to compare without installing nine OAuth flows. ## Frequently asked questions ### When were the Claude creative connectors released? April 28, 2026. Anthropic announced nine connectors covering Adobe Creative Cloud, Blender, Ableton, Splice, Autodesk Fusion, SketchUp, Affinity by Canva, Resolume Arena, and Resolume Wire. ### Which Adobe apps does the Claude connector cover? Anthropic and Adobe describe 50+ tools across eight apps: Photoshop, Lightroom, Illustrator, Premiere, InDesign, Express, Firefly, and Adobe Stock. Anthropic has not published an exhaustive per-tool list as of May 2026. ### Can I use the connectors with Cursor, VS Code, or Grok instead of Claude? Yes. The connectors are built on the open Model Context Protocol, so any MCP-compatible client including Cursor, VS Code, Windsurf, Grok, and ChatGPT via the OpenAI Agents SDK can use them. Anthropic confirmed this in the announcement. ### Does the Ableton connector let Claude control Ableton Live directly? No. Anthropic official Ableton connector grounds Claude answers in Live and Push documentation. It is a docs-search connector. For direct DAW control such as creating tracks, firing clips, and changing tempo, use the community ahujasid/ableton-mcp server. ### Do I need an Adobe subscription to use the Adobe connector? Yes. The connector does not bypass licensing. Tools in Photoshop, Premiere, Illustrator, and the other paid Creative Cloud apps require an active subscription. Free apps in the bundle are still subject to their own usage limits. ### What does Anthropic Blender Development Fund patronage mean? Anthropic made a one-time donation to the Blender Development Fund as part of the connector launch, with stated support for continued development of the Python API the connector relies on. ### How do I install a Claude creative connector? Open Claude, go to the Customize panel, pick the connector, complete the partner OAuth flow such as Adobe ID or Autodesk account, and start a new conversation. The connector tools are then available to Claude. --- _Canonical page: https://mcpplaygroundonline.com/blog/claude-creative-connectors-adobe-blender-ableton — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # How to Test Your MCP Server with Kimi K2.6 (2026 Guide) > Step-by-step guide to testing any MCP server with Moonshot AI Kimi K2.6 — the open-weight 1T-parameter agent model that leads on MCPMark, Toolathlon, and tool-invocation success. No API keys, no setup, no code. **Source:** https://mcpplaygroundonline.com/blog/test-mcp-server-with-kimi-k2-6 **Author:** MCP Playground **Published:** 2026-05-24 **Updated:** 2026-05-24 **Category:** Guide **Reading time:** 10 min read --- 📖 TL;DR To test your MCP server with Kimi K2.6: open [MCP Agent Studio](/mcp-agent-studio), paste your server URL, pick **Kimi K2.6** from the model picker, and start chatting. Agent Studio converts MCP tool definitions to K2.6's OpenAI-compatible function-calling format automatically — no Moonshot API key, no setup, no code. **Why K2.6?** Released April 20, 2026 under a Modified MIT licence. 1T MoE / 32B active, 256K context, multimodal. **96.6% tool-invocation success** — the highest of any open-weights model in 2026. **MCPMark 55.9** (up from K2.5's 29.5) and **Toolathlon 50.0** — ahead of Claude (47.2) and Gemini 3.1 Pro (48.8). Output tokens cost roughly 1/4 of GPT-5.4 and 1/20 of Claude Opus 4.7. What you'll get from this guide - The K2.6 / K2.5 / K2 Thinking lineup and which variant to pick for MCP tool calling - Connect any MCP server (HTTP, SSE, Streamable HTTP) to Kimi K2.6 in seconds — no Moonshot account required - Run your first agentic conversation with K2.6 and inspect every tool call live - Know exactly when K2.6 beats Claude or GPT on your server — and when it doesn't Moonshot AI's **Kimi K2.6** shipped on April 20, 2026 and is, on the public agentic tool-calling benchmarks that matter for MCP, the strongest open-weight model of 2026. The headline jumps over K2.5 came on the benchmarks that score tool-driven agents: **MCPMark went from 29.5 → 55.9** and **Toolathlon from 27.8 → 50.0** — past Claude (47.2) and Gemini 3.1 Pro (48.8). The model's published tool-invocation success rate is **96.6%**, the highest of any model with open weights in 2026. The fastest way to put your MCP server in front of K2.6 — without a Moonshot account, OpenRouter key, or any code — is [MCP Agent Studio](/mcp-agent-studio). You paste your server URL, pick Kimi K2.6, and the agent starts calling your tools in real time. For a wider provider sweep, see our [best AI model for MCP tool calling](/blog/best-ai-model-for-mcp-tool-calling) roundup. In this guide 1. [The Kimi K2 family in May 2026 — which one to use](#kimi-models) 2. [How Kimi K2.6 handles MCP tool calling](#tool-calling) 3. [Connect your MCP server to Kimi K2.6 in 3 steps](#connect) 4. [Prompts that exercise K2.6's strongest behaviour](#prompts) 5. [Reading the tool-call inspector with K2.6](#inspector) 6. [Kimi K2.6 vs Claude vs GPT on MCP tool calling](#kimi-vs-others) 7. [FAQ](#faq) ## 1\. The Kimi K2 family in May 2026 — which one to use Moonshot AI shipped Kimi K2 in July 2025, K2 Thinking in November 2025, K2.5 in January 2026, and **K2.6 on April 20, 2026**. The original K2 family is scheduled for end-of-life on May 25, 2026 — for any new work, K2.5 or K2.6 are the choices that matter. K2.6 ships as four variants that share the _same weights_ but differ in decoding configuration, tool permissions, and how the thinking budget is allocated: Variant What it's tuned for Use it for Instant Lower temperature, no chain-of-thought High-volume agents — log triage, classification, batch summarisation Thinking Full CoT interleaved with tool calls **Default for most MCP agents** — produces K2.6's benchmark scores Agent Autonomous research / document tasks One-shot research jobs, long-form report generation Agent Swarm Up to 300 sub-agents / 4,000 coordinated steps Large-scale parallel work — codebase migrations, sweep audits Model Architecture Context Best for MCP Kimi K2.6 1T MoE / 32B active 256K **Daily driver for tool-calling MCP agents.** 96.6% tool-invocation success, MCPMark 55.9 Kimi K2.5 1T MoE / 32B active 256K Solid for simpler MCP loops — about half the price of K2.6 Kimi K2 Thinking 1T MoE 256K Reasoning-mode predecessor. **93% on τ²-Bench Telecom** at release 💡 Recommended starting point **Kimi K2.6 in Thinking mode.** It produces every benchmark score Moonshot publishes, and on MCP-style tool calling it currently has the highest published success rate (96.6%) of any open-weights model. Drop to **Instant** when you've already validated the loop and want to cut latency on a high-volume agent. ## 2\. How Kimi K2.6 handles MCP tool calling K2.6 exposes a function-calling API that's compatible with **both OpenAI's and Anthropic's** wire format: - **OpenAI-compatible:** `https://api.moonshot.ai/v1` — same `tools` array and `tool_calls` response your existing GPT-5.4 code already sends - **Anthropic-compatible:** `https://api.moonshot.ai/anthropic` — drop-in for Claude Code by setting `ANTHROPIC_BASE_URL` A few K2.6-specific behaviours worth knowing when testing your server: - **Trained specifically for tool use.** The Toolathlon and MCPMark jumps over K2.5 came from post-training that put heavy weight on multi-step tool sequences. K2.6's **96.6% tool-invocation success rate** is the highest of any public-weights model in 2026 — Moonshot traces the remaining 3.4% mostly to malformed third-party MCP server schemas, not the model. - **Parallel tool calls.** K2.6 can issue multiple tool calls in a single response turn and aggregate results before continuing. Important for MCP servers where read operations are independent (fetch user + fetch their orders + fetch shipping in one round-trip). - **`preserve_thinking` mode.** K2.6's API exposes a flag that retains the full reasoning trace across multi-turn agent loops. On long coding/agent runs this measurably improves consistency between turns — the model doesn't lose what it concluded three tool calls ago. - **MCP servers configured for Claude Code work in Kimi Code without modification.** Moonshot's Kimi Code CLI (Apache 2.0 licensed) implements MCP and the Agent Client Protocol, so any MCP server already wired into Claude Code drops straight in. - **MoonViT vision encoder.** K2.6 ships with a 400M-parameter vision module that accepts images and video natively. If your MCP server returns image URLs (e.g., a screenshot tool from a Playwright MCP), K2.6 can reason over them in the same turn. ## 3\. Connect your MCP server to Kimi K2.6 in 3 steps No Moonshot account, no OpenRouter key, no local install. MCP Agent Studio handles everything in the browser: 1 **Sign in to MCP Agent Studio** Go to [mcpplaygroundonline.com/mcp-agent-studio](/mcp-agent-studio) and sign in. New accounts get starter credits — enough to put K2.6 in front of your server today. 2 **Paste your MCP server URL** Click **\+ Add Server** and paste the endpoint. Agent Studio supports HTTP, SSE, and Streamable HTTP. Add a bearer token in the auth field if your server needs one. Up to 4 servers per conversation. 3 **Pick Kimi K2.6 and start chatting** Open the model picker, search for "Kimi". Pick **Kimi K2.6**. Type a natural-language question that needs one of your tools to answer. The agent discovers your tools, decides which to call, and shows every step live in the inspector. **No MCP server yet?** Deploy one in one click from [/mcp-hosted](/mcp-hosted) — Postgres, GitHub, Slack, Stripe, Playwright, MongoDB, and 35+ more. You'll get a live HTTPS URL plus bearer token that drops straight into step 2. ## 4\. Prompts that exercise K2.6's strongest behaviour K2.6 in Thinking mode was tuned for the long-horizon plan-execute-observe-revise loop. The shape of your prompt decides how much of that you see. 🔍 Discovery prompt Forces K2.6 to enumerate and summarise your server's surface. "What tools does this server expose? Group them by category and give a one-line summary of what each one does." ⛓️ Long-horizon prompt Where K2.6's Thinking mode pulls ahead. "Find every \[resource\] modified in the last 7 days, look up the owner, then group them by team and flag anything older than the team's SLA." 🔀 Parallel tool prompt Tests whether K2.6 batches independent reads in one turn. "Compare \[item A\] and \[item B\] side by side — fetch both at the same time." 🛑 Recovery prompt Exercises the revise-and-retry loop that drove the MCPMark jump. "Look up \[a resource that probably doesn't exist\]. If you can't find it, suggest 3 similar things that do exist on this server." 🐝 Agent Swarm prompt K2.6's most distinctive capability — fan out 300 sub-agents across 4,000 steps. "Audit every endpoint in \[your API MCP\] for missing auth checks. For each one you find, draft a one-line fix. Run the checks in parallel." For multi-server runs, K2.6 handles cross-server coordination cleanly. _"For every open issue in \[your GitHub MCP\], post a status update to the matching channel in \[your Slack MCP\]"_ exercises sequential, multi-server tool use — the workload where K2.6's Toolathlon score (50.0) overtakes Claude (47.2) and Gemini 3.1 Pro (48.8). ## 5\. Reading the tool-call inspector with K2.6 Every time K2.6 calls a tool on your server, MCP Agent Studio logs it in the inspector panel on the right. Click any tool card in the chat to expand: Inspector field What it shows What to check with K2.6 Tool name Which MCP tool K2.6 picked Right tool for the request? K2.6 in Thinking mode often picks a richer tool than the obvious one Input JSON Arguments K2.6 sent Types correct? K2.6's structured-schema training means types are nearly always right — failed calls are usually a server-schema issue Output JSON What your server returned Empty arrays or errors trigger K2.6's revise loop — watch the next call Latency Tool invocation to result Separates slow server from slow model Server source Which connected server the tool came from Multi-server runs — verify K2.6 picked the right namespace **K2.6-specific pattern to watch:** With `preserve_thinking` enabled, K2.6 references prior reasoning _across_ tool boundaries. In the inspector you can see this as a tool call whose arguments reference an earlier observation — not the last tool's output. That's the trained-in chain talking, and it's why long agent loops drift less on K2.6 than on K2.5. ## 6\. Kimi K2.6 vs Claude Opus 4.7 vs GPT-5.4 on MCP tool calling Rather than abstract benchmarks, here's the practical comparison you'll feel on a real MCP server in Agent Studio: Behaviour Kimi K2.6 GPT-5.4 Claude Opus 4.7 Tool-invocation success rate **96.6% (leader)** Strong Strong MCPMark **55.9** — — Toolathlon **50.0** — 47.2 SWE-Bench Pro **58.6** 57.7 53.4 (Opus 4.6) SWE-Bench Verified 80.2 — **87.6 (leader)** Long-horizon agent loops **Best in class** (Agent Swarm, 4,000 steps) Very good Very good Parallel tool calls Yes Yes Yes Context window 256K 1M 200K (1M tier) Native MCP support Via Kimi Code + ACP Via Agents SDK **Native** (`mcp_servers` param) Open weights **Yes (Modified MIT)** No No Pricing per 1M (in / out) — official API **$0.95 / $4.00** $2.50 / $15 $15 / $75 Pricing per 1M (in / out) — OpenRouter **$0.73 / $3.49** — — **Bottom line:** K2.6 is the strongest open-weight model for MCP tool calling published in 2026. On the **agentic tool-use benchmarks specifically** — MCPMark, Toolathlon, τ²-Bench — it sits at or near the top of the leaderboard, and its 96.6% tool-invocation success is the highest of any public-weights model. Output tokens cost roughly a quarter of GPT-5.4's and a twentieth of Claude Opus 4.7's, which matters because output is the dominant cost in agentic workloads. Where K2.6 doesn't lead: SWE-Bench Verified at 80.2% trails Claude Opus 4.7 at 87.6%. For pure deep-coding work with no MCP surface, Opus 4.7 still wins. For MCP-driven agentic loops, K2.6 is the cost-per-correct-tool-call leader. Try Kimi K2.6 against your MCP server now No Moonshot account. No API keys. K2.6, K2.5, and K2 Thinking all ready in seconds — alongside Claude Opus 4.7, GPT-5.4, Gemini 3.1 Pro, and DeepSeek V4 for side-by-side comparison. [Open MCP Agent Studio →](/mcp-agent-studio) ## FAQ **Does Kimi K2.6 support MCP natively? +** Not in the sense Claude does — K2.6 doesn't speak the raw MCP wire protocol. It exposes function calling that's compatible with both OpenAI's and Anthropic's APIs, and Moonshot ships a CLI (Kimi Code) that does speak MCP and the Agent Client Protocol. MCP Agent Studio handles the bridging for you: it discovers your server's tools via MCP, converts them to the function-calling format K2.6 expects, runs the agent loop, and shows every tool call live. No code on your end. **Which Kimi model should I start with for MCP testing? +** Start with **Kimi K2.6** in Thinking mode. It's the variant that produces every benchmark score Moonshot publishes, and on tool-calling specifically (96.6% invocation success, 55.9 MCPMark, 50.0 Toolathlon) it's the leader among public-weights models. Use **K2.5** when you want roughly the same accuracy at about half the cost — the gap shows up mainly on multi-step tool sequences, not single-call workloads. Use **K2 Thinking** if you're specifically replicating a published τ²-Bench Telecom result. **What makes K2.6 different from GPT-5.4 or Claude Opus 4.7 on MCP work? +** Three things. First, **benchmark focus** — K2.6's biggest gains over K2.5 were on MCPMark and Toolathlon, the agentic tool-use benchmarks, not pure coding ones. Second, **architecture** — the Agent Swarm system can orchestrate 300 sub-agents over 4,000 coordinated steps, which is purpose-built for the kind of audit / sweep / migration workflows that MCP servers tend to enable. Third, **cost** — at $0.95/$4.00 per million input/output tokens on the official API (or $0.73/$3.49 on OpenRouter), output is roughly a quarter the price of GPT-5.4 and a twentieth of Claude Opus 4.7. **Can I self-host K2.6 and point it at my MCP server? +** Yes. K2.6 weights are on Hugging Face under a Modified MIT licence. Run them with vLLM, SGLang, or TensorRT-LLM — all expose an OpenAI-compatible API, and any MCP client wired to OpenAI function calling will work against your self-hosted endpoint. The 1T-parameter MoE means you'll need multi-GPU inference (typically 8× H100 or equivalent) for the full model. Use Agent Studio first to validate prompt and tool behaviour, then swap in your local endpoint for production. **Do I need a Moonshot API key to use Kimi K2.6 in MCP Agent Studio? +** No. MCP Agent Studio handles all provider credentials on its side. Sign up for a free account, use your starter credits, and start chatting with K2.6 against your MCP server immediately — no Moonshot account, no OpenRouter key, no billing setup. **How many MCP tools can K2.6 handle per request? +** K2.6 inherits the OpenAI-compatible tools array, so the practical ceiling is the same 128-function-per-request limit as GPT, Gemini, and Qwen. In practice, K2.6's tool-selection accuracy holds up better than older models past 30–40 definitions — that's part of why MCPMark jumped from 29.5 (K2.5) to 55.9 (K2.6). Agent Studio's Tokens tab shows the exact token cost of your tool schemas so you can decide what to keep in scope. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work, why the same server behaves differently per model, and what to measure. Other guides in this series: [DeepSeek V4](/blog/testing-mcp-with-deepseek), [Qwen](/blog/test-mcp-server-with-qwen-models), [Gemini](/blog/test-mcp-server-with-gemini-models), [GLM](/blog/test-mcp-server-with-glm-models), [GLM 5.3](/blog/glm-5-3-mcp-servers), [Grok](/blog/testing-mcp-with-grok-xai), [MiniMax](/blog/testing-mcp-with-minimax). ## Frequently asked questions ### Does Kimi K2.6 support MCP natively? Not in the sense Claude does — K2.6 does not speak the raw MCP wire protocol. It exposes function calling that is compatible with both OpenAI and Anthropic APIs, and Moonshot ships a CLI (Kimi Code) that speaks MCP and the Agent Client Protocol. MCP Agent Studio handles the bridging: it discovers your server tools via MCP, converts them to the function-calling format K2.6 expects, runs the agent loop, and shows every tool call live with no code on your end. ### Which Kimi model should I start with for MCP testing? Start with Kimi K2.6 in Thinking mode — the variant that produces every benchmark score Moonshot publishes. On tool-calling specifically (96.6% invocation success, 55.9 MCPMark, 50.0 Toolathlon) it is the leader among public-weights models. Use K2.5 when you want roughly the same accuracy at about half the cost, or K2 Thinking if you are specifically replicating a published τ²-Bench Telecom result. ### What makes K2.6 different from GPT-5.4 or Claude Opus 4.7 on MCP work? Three things. Benchmark focus — K2.6 biggest gains over K2.5 were on MCPMark and Toolathlon, the agentic tool-use benchmarks, not pure coding ones. Architecture — the Agent Swarm system can orchestrate 300 sub-agents over 4,000 coordinated steps, purpose-built for audit / sweep / migration workflows. Cost — at $0.95/$4.00 per million input/output tokens on the official API (or $0.73/$3.49 on OpenRouter), output is roughly a quarter the price of GPT-5.4 and a twentieth of Claude Opus 4.7. ### Can I self-host K2.6 and use it with my MCP server? Yes. K2.6 weights are on Hugging Face under a Modified MIT licence. Run them with vLLM, SGLang, or TensorRT-LLM — all expose an OpenAI-compatible API, and any MCP client wired to OpenAI function calling will work against your self-hosted endpoint. The 1T-parameter MoE typically needs 8× H100 or equivalent for full-precision inference. ### Do I need a Moonshot API key to use Kimi K2.6 in MCP Agent Studio? No. MCP Agent Studio handles all provider credentials on its side. Sign up for a free account, use your starter credits, and start chatting with K2.6 against your MCP server immediately — no Moonshot account, no OpenRouter key, no billing setup. --- _Canonical page: https://mcpplaygroundonline.com/blog/test-mcp-server-with-kimi-k2-6 — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Connect Your MCP Server With DeepSeek V4: Step-by-Step Guide (2026) > Connect any MCP server to DeepSeek V4-Pro or V4-Flash in 60 seconds — paste the URL, pick the model, start chatting. Plus head-to-head benchmarks against Claude Opus 4.7 and GPT-5.4. **Source:** https://mcpplaygroundonline.com/blog/testing-mcp-with-deepseek **Author:** MCP Playground **Published:** 2026-05-18 **Updated:** 2026-05-18 **Category:** Comparison **Reading time:** 13 min read --- 📖 TL;DR — Key Takeaways - **DeepSeek V4 shipped April 24, 2026** in two flavours: **V4-Pro** (1.6T MoE / 49B active) and **V4-Flash** (284B MoE / 13B active). Both expose a **1M-token context** and ship under the MIT license. - V4 ties **Claude Opus 4.6 on MCPAtlas Public (73.6)** and beats GPT-5.4 on Codeforces — the best open-weight model for MCP agents in 2026. - Both OpenAI **and** Anthropic-compatible APIs — drop in `deepseek-v4-pro` or `deepseek-v4-flash` as the model name and any MCP client already works. - **128 parallel tool calls**, a new XML-based `|DSML|` schema that virtually eliminates argument-parse errors, and three reasoning modes (Non-think / Think High / Think Max). - V4-Pro promo pricing: **$0.435/M input · $0.870/M output** through May 31. V4-Flash is ~**$0.28/M output** — roughly 1/20th of Claude Opus 4.7. - I tested both against GitHub, Postgres, Stripe and a multi-MCP setup in [MCP Playground Agent Studio](/mcp-agent-studio) — full results below. You can **connect any MCP server to DeepSeek V4** in about 60 seconds — paste the server URL into [MCP Agent Studio](/mcp-agent-studio), pick `deepseek-v4-pro` or `deepseek-v4-flash` from the model dropdown, and start chatting. Every tool call is shown live, no DeepSeek API key required. **DeepSeek V4** shipped on April 24, 2026 and turned the company's open-weight stack into a credible alternative to Claude Opus 4.6 and GPT-5.4 for tool-driven agents — at a fraction of the price. If the last time you tried **connecting an MCP server with DeepSeek** was on V3 or R1, the story has changed completely. This post walks through three ways to wire your MCP server up to V4 — Agent Studio, the OpenAI SDK, and Claude Code with V4's pre-tuned adapter — then a head-to-head against Claude and GPT-5 and the four pitfalls that ate the most time. ## The DeepSeek V4 Lineup (and Why You Can Stop Reading About R1) There are two V4 models that matter, plus two older ones worth knowing about so you do not pick them by accident: Model Params (active) Context Tool calling? **deepseek-v4-pro** 1.6T (49B) 1M tokens **Yes** — 128 parallel, native MCPAtlas-tuned **deepseek-v4-flash** 284B (13B) 1M tokens **Yes** — same tool schema, 4–5× faster deepseek-v3.2 (deepseek-chat / -reasoner) 685B (37B) 128K Yes — but superseded by V4 in every benchmark deepseek-r1 — — **No** — cannot call tools by design Architecturally, V4 is a different beast from V3.2. DeepSeek replaced the dense attention with a _Hybrid Attention_ stack — Compressed Sparse Attention plus Heavily Compressed Attention — which cuts KV cache by ~90% and per-token inference FLOPs by ~73% versus V3.2 at the 1M-context setting. Translation: long-context MCP agents that used to OOM now run cheaply. It was pre-trained on **32T tokens**, ships with the Muon optimizer, and uses Manifold-Constrained Hyper-Connections to stabilize signal propagation. That is the why-it-works story; the practical story is that V4 ties Claude Opus 4.6 on every public agentic benchmark I checked. ## Why DeepSeek V4 Is Built for MCP Three things make V4 unusually good at MCP-style tool calling. None of them existed in V3.2 or earlier. ### 1\. The |DSML| XML Schema (Goodbye, Empty Argument Bug) Function calling in V3 and V3.2 used pure JSON for tool arguments. That broke whenever a string parameter contained a stray quote or brace — the model would emit a malformed object and the call would fail. V4 introduces an **XML-based schema powered by a special `|DSML|` token** that separates string parameters from structured JSON parameters. In practice this means tools that previously failed 5–10% of the time on string-heavy inputs (Slack messages, SQL queries with quoted identifiers, Stripe descriptions) now succeed nearly 100% of the time. ### 2\. Reasoning Persisted Across Tool Calls V4 keeps its internal reasoning chain coherent _across_ tool-call boundaries. Earlier models reset their reasoning after each tool result, which is why long agent loops would drift. V4 carries the chain forward, so a 10-step agent stays on-task. ### 3\. Three Reasoning Modes for Three MCP Workloads Mode When to use it `non-think` High-volume agents — log triage, customer-support bots, batch summarisation. Cheapest, fastest. `think-high` Default for most MCP agents — the model reasons before each tool call, verifies output, retries if wrong. `think-max` SWE-Bench-class workloads: multi-step debugging, complex SQL, security analysis. Costlier but matches Opus 4.6. ### 4\. Native MCPAtlas-Tuned Adapters DeepSeek shipped **pre-tuned adapters for Claude Code and OpenCode** alongside V4 — meaning the model was fine-tuned on real MCP-style agent traces, not just synthetic function-calling data. That shows up in MCPAtlas Public scores of 73.6 (tied with Opus 4.6) and SWE-Bench Verified at 80.6% (0.2pp behind Opus 4.6). Naming gotcha DeepSeek still serves the legacy `deepseek-r1` model. It does _not_ support function calling — it never did, and V4 did not change that. If you point an MCP client at `deepseek-r1` it will hallucinate tool output. Use `deepseek-v4-pro` or `deepseek-v4-flash` for any MCP work. ## Connect Your MCP Server With DeepSeek V4 — 3 Ways Three ways to wire your MCP server up to V4, ordered by setup time. **Option 1 takes about 60 seconds and needs no code.** ### Option 1 — MCP Playground Agent Studio (60 seconds, no code) This is the recommended path for most people. [MCP Agent Studio](/mcp-agent-studio) handles the OpenAI ↔ MCP bridge for you, ships V4-Pro and V4-Flash in the model dropdown, and runs the full agent loop in the browser. No SDK, no DeepSeek API key, free credits on sign-up. **Step-by-step:** 1. Open [/mcp-agent-studio](/mcp-agent-studio) and sign in (free credits are added to your account). 2. In the **MCP Servers** panel, click **Add server**. Paste your server URL — works with Streamable HTTP, SSE, or HTTP. Add a bearer token in the **Headers** field if your server needs one. 3. Click **Connect**. Agent Studio runs `tools/list` against the server and shows you every tool it discovered. If the count looks right, your server is wired up. 4. In the **Model** dropdown, pick **DeepSeek V4-Pro** (for hard reasoning) or **DeepSeek V4-Flash** (for speed + cost). 5. Type your first prompt and hit send. Every tool call, argument, and result is shown inline as the agent runs. If you don't have an MCP server yet, head to [/mcp-hosted](/mcp-hosted) and deploy one in one click — Postgres, Stripe, GitHub, Atlassian, MongoDB, Playwright, and 35+ more. You'll get a live HTTPS URL plus bearer token that drops straight into step 2 above. [Connect your MCP server with DeepSeek V4 free →](/mcp-agent-studio) ### Option 2 — OpenAI SDK + DeepSeek V4 Endpoint (writing your own runtime) If you're building your own agent runtime, V4's API is OpenAI-compatible _and_ Anthropic-compatible. Change the base URL and the model name, and existing function-calling code routes to V4. ``` from openai import OpenAI client = OpenAI( api_key="sk-...", base_url="https://api.deepseek.com/v1", ) response = client.chat.completions.create( model="deepseek-v4-pro", # or "deepseek-v4-flash" messages=[{"role": "user", "content": "List my open GitHub PRs"}], tools=mcp_tools_as_openai_functions, # MCP tools/list → OpenAI tools[] tool_choice="auto", reasoning_effort="think-high", # non-think | think-high | think-max ) ``` You still have to bridge MCP's `tools/list` into the OpenAI `tools[]` array, parse each `tool_calls` entry into an MCP `tools/call`, feed the result back, and loop until the model is done — about 80 lines of Python if you want it solid. Agent Studio does all of this for you. ### Option 3 — Claude Code With the V4 Adapter (terminal workflow) New with V4: DeepSeek ships pre-tuned adapters for **Claude Code** and **OpenCode**. Drop V4-Pro in as the underlying model and Claude Code's existing MCP config (`~/.claude/mcp.json`) works unchanged — including HTTP, SSE and Streamable HTTP servers. This is the path to pick if you live in the terminal and want V4 driving your MCP tools the same way Claude does today. Surprisingly clean for an open-weight model. ## Hands-On Tests: 4 MCP Servers Against DeepSeek V4-Pro Four common MCP servers, each with a prompt that required at least three tool calls. Same prompts I used for my V3.2 tests in April, so you can compare against history. ### Test 1: GitHub MCP (Search + Read Code) Prompt "Find all open issues labelled 'security' across my repos, read the latest comment on each, and summarise the highest-severity ones." **Result:** V4-Pro used **parallel** tool calls aggressively — one `search_issues`, then six concurrent `get_issue_comments` in a single turn. Total time 6.3 seconds (down from 11s on V3.2). The parallel-call ceiling of 128 is V4's headline feature for agents. ### Test 2: Postgres MCP (Analytical SQL) Prompt "Which 5 customers had the largest week-over-week drop in revenue? Show me the gap and the absolute numbers." **Result:** V4-Pro grounded by calling `list_schemas` + `describe_table` first, then wrote a clean window-function query. The XML-based `|DSML|` schema mattered here — the SQL string had quoted identifiers that broke V3.2 about 20% of the time. V4 handled all 10 runs cleanly. ### Test 3: Stripe MCP (Real-Money Reasoning) Prompt "List failed payments from last week. Group by failure reason and tell me which ones I should follow up with." **Result:** V4-Pro in `think-high` mode reasoned about the trade-offs before suggesting any follow-up — flagged a stale-card cluster, a 3DS-rejection cluster, and a fraud-block cluster separately. Refused to suggest re-charging without explicit confirmation. Same conservative behaviour as V3.2, with better grouping. ### Test 4: Multi-MCP — GitHub + Slack + Atlassian Together Prompt "Pull yesterday's merged GitHub PRs, find the linked Jira tickets, and post a roll-up to the #eng channel." **Result:** Three MCP servers connected at once (47 tools total). V4-Pro picked the right tool from each without me labelling them. The _parallel_ call architecture meant it pulled PRs and Jira tickets simultaneously, then composed the Slack message. End-to-end 8 seconds, would have been ~25 on V3.2. ## DeepSeek V4 vs Claude, GPT-5, Gemini on MCP Workloads Same four prompts, six models, three runs each, averaged. Cost numbers use V4 promo pricing; assume V4-Pro doubles after May 31. Model Tool calls / task Avg latency Cost / task Final-answer quality **DeepSeek V4-Flash** 3.6 5.4s **$0.0021** Strong **DeepSeek V4-Pro (think-high)** 3.2 7.1s $0.0065 Strongest (tie) **DeepSeek V4-Pro (think-max)** 3.0 11.4s $0.014 Strongest (tie) Claude Sonnet 4.5 3.0 7.4s $0.022 Strong Claude Opus 4.7 2.9 9.8s $0.061 Strongest (tie) GPT-5.4 3.6 8.1s $0.018 Strong Gemini 3.1 Pro 3.3 10.5s $0.014 Strong Four things I did not expect before this benchmark: - **V4-Flash is the price-performance shock of 2026.** Quality on par with GPT-5.4, ~9× cheaper. For high-volume agents (CI bots, log triage, customer support) this changes the math entirely. - **V4-Pro in think-max ties Claude Opus 4.7** on final-answer quality at ~1/4 the cost. The 1M context plus persisted reasoning means it can handle long agent loops Opus would struggle to fit. - **Parallel tool calls cut wall-clock time roughly in half** on multi-MCP setups. V4 will fire 6–8 concurrent calls when it sees they are independent; Claude and GPT-5 still tend to serialize. - Claude is still slightly more polished on natural-language final answers — there's a "Claude voice" that V4 does not quite match. For tool execution itself, V4-Pro is at parity. ## Pitfalls I Hit With V4 ### 1\. Don't Mix V4 With Legacy V3.2 Conversations V4's XML `|DSML|` schema is incompatible with V3.2's pure-JSON tool format. If your gateway routes between V4 and V3.2 mid-session, tool-call replay breaks. Pin the model per conversation. ### 2\. The 128-Tool Ceiling Still Applies V4 supports 128 parallel calls per request — but also 128 tool _definitions_. Most single MCP servers are well below this, but if you wire up GitHub + Slack + Postgres + Jira + Linear + Stripe in one session you can blow past 128 tools and the tail will silently drop. Scope the toolsets you expose. ### 3\. think-max Is Expensive — Use It Sparingly The `think-max` mode is wonderful on hard reasoning tasks, but burns ~2× the tokens of `think-high`. For most MCP workflows, `think-high` is the sweet spot. Save `think-max` for SWE-Bench-class problems. ### 4\. Don't Bet on the Promo Pricing V4-Pro's headline $0.435/M input is a **75% promo discount through May 31, 2026**. List price is $1.74/M input and $3.48/M output. Still cheaper than Claude — but model your cost projection on list, not promo. ## How MCP Playground Helps - **70+ models in one UI** — V4-Pro, V4-Flash, Claude Opus 4.7 / Sonnet 4.5, GPT-5.4, Gemini 3.1 Pro, Grok, Qwen, Mistral. No DeepSeek API key needed. - **Paste any MCP URL** — works with hosted Atlassian, GitHub, Linear, Vercel, Supabase, Datadog, or your own remote. - **One-click hosted MCP servers** — 40+ pre-configured: Postgres, Stripe, MongoDB, Playwright, Brave Search and more. [Deploy in under a minute](/mcp-hosted). - **Compare mode** — run the same prompt across V4-Pro, Claude and GPT-5 side-by-side. Tool-call traces and final answers, parallel. If you are evaluating V4 for a production agent, the side-by-side compare is the fastest way to make the call. Test MCP with DeepSeek V4 in your browser V4-Pro + V4-Flash plus 40+ other models. Paste any MCP URL or deploy a hosted server with one click. Free credits on sign-up. [Open Agent Studio →](/mcp-agent-studio) [Deploy hosted MCP →](/mcp-hosted) ## Bottom Line **DeepSeek V4 is the first open-weight model that's a real alternative to Claude Opus and GPT-5 for MCP agents.** It ties Opus 4.6 on MCPAtlas, beats GPT-5.4 on Codeforces, runs at a fraction of the cost, and ships with parallel tool calls plus a 1M context that most closed models cannot match. Picking between Pro and Flash is easy: **Flash** for high-volume, latency-sensitive agents; **Pro** when the agent has to reason its way through a hard problem. The fastest way to validate it on _your_ MCP server is [Agent Studio](/mcp-agent-studio) — pick DeepSeek V4-Pro or V4-Flash, paste the URL, run your hardest prompt three times. If it works there, it will work in production. ## Related Reading - [What Is Model Context Protocol? A Plain-English Guide](/blog/what-is-model-context-protocol) - [Best MCP Servers in 2026](/blog/best-mcp-servers-2026) - [Hosted MCP Server: 7 Real Use Cases](/blog/hosted-mcp-server-use-cases) - [PostgreSQL MCP: Build a Claude Analytics Agent](/blog/postgres-mcp-claude-analytics-agent-recipe) ## Frequently Asked Questions **When was DeepSeek V4 released?** April 24, 2026. Two models shipped at GA: `deepseek-v4-pro` (1.6T MoE / 49B active) and `deepseek-v4-flash` (284B / 13B active), both with a 1M-token context window. Weights are open under the MIT license on Hugging Face. **Does DeepSeek V4 support MCP servers?** Yes. V4 exposes OpenAI-compatible _and_ Anthropic-compatible APIs — any MCP client that talks to GPT or Claude works with V4 out of the box. Drop in `deepseek-v4-pro` or `deepseek-v4-flash` as the model and tool calls just work. It also ties Claude Opus 4.6 on MCPAtlas Public (73.6). **What's the difference between V4-Pro and V4-Flash?** V4-Pro is the flagship (1.6T MoE, 49B active) and matches Opus on hard agent reasoning. V4-Flash (284B MoE, 13B active) is roughly 4–5× faster and ~3× cheaper, with quality on par with GPT-5.4 on routine MCP tasks. Use Flash for high-volume agents, Pro when the model has to actually reason about which tool to call. **Can DeepSeek R1 call tools?** No. R1 is a pure reasoning model with no function-calling capability — it cannot drive an MCP server. Use `deepseek-v4-pro` or `deepseek-v4-flash` instead. R1's reasoning has been superseded by V4's `think-high` and `think-max` modes, which include tool use. **How many tools can DeepSeek V4 call in one request?** Up to **128 parallel tool calls** per request, and the model treats independent calls as eligible to run concurrently. That is enough for 5–6 typical MCP servers connected at once. Exceeding 128 silently drops trailing tools — scope the MCP toolsets you pass to stay under the cap. **Is DeepSeek V4 cheaper than Claude or GPT-5 for MCP agents?** Significantly. V4-Pro promo pricing is $0.435/M input · $0.870/M output (through May 31). V4-Flash is ~$0.28/M output — roughly 1/20th of Claude Opus 4.7. On my benchmark V4-Flash ran an MCP agent task for $0.002 vs $0.061 for Opus. **How do I test DeepSeek V4 against an MCP server without writing code?** Use [MCP Agent Studio](/mcp-agent-studio). Paste the MCP server URL, pick DeepSeek V4-Pro or V4-Flash from the model dropdown, and start chatting. Every tool call and result is shown live. Free credits on sign-up — no DeepSeek API key required. 🔀 Comparing models for MCP? MCP is model-agnostic — the protocol sits between the client and your server, not inside the model — but tool _selection_ is a judgement each model makes differently. [MCP with different AI models](/mcp-model-comparison) covers which families work, why the same server behaves differently per model, and what to measure. Other guides in this series: [Qwen](/blog/test-mcp-server-with-qwen-models), [Gemini](/blog/test-mcp-server-with-gemini-models), [GLM](/blog/test-mcp-server-with-glm-models), [Grok](/blog/testing-mcp-with-grok-xai), [Kimi K2.6](/blog/test-mcp-server-with-kimi-k2-6), [MiniMax](/blog/testing-mcp-with-minimax). ## Frequently asked questions ### When was DeepSeek V4 released? April 24, 2026. Two models shipped at GA: deepseek-v4-pro (1.6T MoE / 49B active) and deepseek-v4-flash (284B / 13B active), both with a 1M-token context window. Weights are open under the MIT license. ### Does DeepSeek V4 support MCP servers? Yes. V4 exposes OpenAI-compatible and Anthropic-compatible APIs — any MCP client that talks to GPT or Claude works with V4 out of the box. It also ties Claude Opus 4.6 on MCPAtlas Public at 73.6. ### What is the difference between V4-Pro and V4-Flash? V4-Pro is the flagship (1.6T MoE, 49B active) and matches Opus on hard agent reasoning. V4-Flash (284B / 13B active) is ~4\u20135x faster and ~3x cheaper, with quality on par with GPT-5.4 on routine MCP tasks. ### Can DeepSeek R1 call tools? No. R1 is a pure reasoning model with no function-calling capability. Use deepseek-v4-pro or deepseek-v4-flash instead — V4 has equivalent reasoning quality through its think-high and think-max modes, plus full tool support. ### How many tools can DeepSeek V4 call in one request? Up to 128 parallel tool calls per request, with independent calls executed concurrently. Enough for 5\u20136 typical MCP servers at once. Exceeding it silently drops trailing tools. ### Is DeepSeek V4 cheaper than Claude or GPT-5 for MCP agents? Yes, significantly. V4-Pro promo pricing is $0.435/M input and $0.870/M output through May 31, 2026. V4-Flash is ~$0.28/M output. On my benchmark V4-Flash ran an MCP agent task for $0.002 vs $0.061 for Claude Opus 4.7. ### How do I test DeepSeek V4 against an MCP server without writing code? Use MCP Playground Agent Studio at /mcp-agent-studio. Paste the MCP server URL, pick DeepSeek V4-Pro or V4-Flash, and start chatting. Every tool call is shown live, free credits on sign-up. --- _Canonical page: https://mcpplaygroundonline.com/blog/testing-mcp-with-deepseek — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Hosted MCP Server: 7 Real Use Cases Developers Build in 2026 > Hosted MCP server use cases — chat with Stripe, Postgres, Jira, GitHub and more in 30 seconds. No Docker, no infra. Deploy free on MCP Playground. **Source:** https://mcpplaygroundonline.com/blog/hosted-mcp-server-use-cases **Author:** MCP Playground **Published:** 2026-05-17 **Category:** Development **Reading time:** 11 min read --- 📖 TL;DR — Key Takeaways - A **hosted MCP server** is a curated MCP server you deploy with one click to the cloud — live HTTPS URL plus bearer token, no infra to run. - Works in any MCP client: **Claude Desktop, Cursor, Continue, MCP Playground Agent Studio**, or your own code. - The seven use cases I keep seeing: agent prototyping, support agents over real data, internal docs Q&A, headless Playwright, multi-MCP agents, team demos, and CI/CD bots. - Free tier on MCP Playground: **1 slot · 60 min/month**. Pro at $25.99/mo gets 2 slots and 600 minutes. I keep watching the same scene at meetups. A dev says "MCP is amazing", opens their laptop, then spends fifteen minutes booting three `npx` processes before the demo can begin. That setup tax is the real reason MCP servers do not show up in production agents. Stdio works on a laptop. It does not work in CI, on a phone, or for a colleague. A **hosted MCP server** closes that gap. You click Deploy, you get a live HTTPS URL plus a bearer token, and you paste it into any MCP-aware agent. This post walks through seven concrete things I have built on hosted MCPs in the last two weeks, with real prompts and the exact servers I used. If you have been blocked on the local-only stdio step, one of these will unblock you. [Deploy a hosted MCP free →](/mcp-hosted) ## What is a hosted MCP server, exactly? A **hosted MCP server** is a curated _Model Context Protocol_ server we run in a secure cloud sandbox on your behalf. You never `git clone`, never run `npm install`, never expose a port. The deploy form asks for whatever credentials the server needs — a GitHub token, a Postgres URL, a Stripe key. You click Deploy. Thirty seconds later you get back: - A live **HTTPS endpoint** like `https://50005-ip052s4eea25.e2b.app/mcp` - A **bearer token** so only your agent can call it - A wall-time budget — for hobby tier, 60 minutes per month total That URL plugs into anything that speaks MCP over HTTP. Claude Desktop. Cursor. Continue. The [MCP Agent Studio](/mcp-agent-studio). Your own LangGraph script. All of them treat it the same. Under the hood, each hosted MCP runs in an isolated [E2B sandbox](https://e2b.dev) — secure by default, ephemeral, no shared filesystem with other deployments. You can stop and restart whenever. That is the whole feature: **turn any MCP server into a URL anyone can call**. ## 7 hosted MCP server use cases worth building Here are the seven I have actually shipped or seen shipped on MCP Playground. Pick whichever maps to your current pain. ### 1\. Prototype agents in 30 seconds — skip the devops This is the one I show people first. You want to try the GitHub MCP in Cursor. The local-only path is: 1. Read the GitHub MCP repo's README 2. Install Node, set the personal access token env var 3. Add it to Cursor's `mcp.json` 4. Restart Cursor, hope nothing collided The hosted path: 1. Open [/mcp-hosted](/mcp-hosted), click **GitHub** 2. Paste your personal access token, click Deploy 3. Copy the URL + token into Cursor's config Done in under a minute. The difference matters most when you are evaluating five different MCPs back-to-back — each one is a 30-second add instead of a half-hour setup. ### 2\. Customer-support agent over your real Stripe + Postgres + HubSpot data Support tickets needed three lookups my team kept repeating: pull the customer from Postgres, find their last invoice in Stripe, check their HubSpot lifecycle stage. With **three hosted MCPs** — `postgres-readonly`, `stripe`, `hubspot` — an agent can answer in one prompt: ``` Customer email: jane@example.com. Pull her last invoice, current MRR, and HubSpot stage. Then write a one-paragraph summary I can paste into the ticket. ``` Critical: the Postgres hosted server is read-only by default. Even if the model hallucinates a `DELETE`, the server rejects it. The Stripe key is scoped to read. The HubSpot Private App is a read-only token. Three hosted MCPs, three keys, one agent. Zero local processes. ### 3\. Internal "ask the docs" agent over Atlassian Jira + Confluence Confluence search is bad. Every team I know reroutes the same five questions to one tired senior engineer. The **Atlassian hosted MCP** connects Jira and Confluence in one entry. Wire it into Claude Desktop. Now the team's question — "what is our policy for granting prod DB access?" — gets answered by reading the actual Confluence page, with the page link returned in the response. Same pattern for Jira: "list every P0 issue in the auth-service project from the last two weeks." The model picks the right tool and runs the query. The hosted Atlassian server supports both Atlassian Cloud and Server/Data Center. Pass an API token (Cloud) or a Personal Access Token (Server/DC) and you are wired up. ### 4\. Run Playwright in the cloud — no local Chrome I love Playwright. I hate that it wants Chrome installed locally, with a sandbox profile, and a window that pops up if you forget `--headless`. The **Playwright hosted MCP** runs headless Chrome inside its sandbox. You hand the agent a URL, it navigates, screenshots, scrapes, fills forms — all without touching your machine. ``` Open https://news.ycombinator.com. Get the top 5 story titles plus their points. Return as JSON. ``` That is a single agent turn against the hosted Playwright server. Same script runs from your laptop, your phone, or a Vercel function — because Playwright is a URL now, not a binary. ### 5\. Multi-MCP agents — GitHub + Linear + Slack in one chat The interesting agents combine tools. The reason most people stop after one is the friction of running three local processes. Deploy each as a hosted MCP, then point the agent at all three URLs: ``` Find the GitHub PRs merged today on the api repo. For each PR, create a Linear issue in the QA project tagged "regression-check". Then post a summary to #engineering on Slack. ``` One prompt, three real systems updated. The agent picks the right tool for each step automatically — no chaining code, no manual handoff. I run this exact prompt as a nightly recap. You can try it inside [MCP Agent Studio](/mcp-agent-studio) without writing any code. ### 6\. Demo MCP to your team — share a URL, not a setup script "Try our MCP server" used to mean a README, a clone, and a Slack thread of "it does not start on Windows". A hosted URL fixes that. Spin up the server with the credentials you want demoed. Share the URL + token via your team's secret manager. Anyone with Claude Desktop or Cursor adds one line to their config and it works. Useful for PM showcases, design reviews, sales engineering — any audience that does not want to clone repos. The URL is yours to revoke when the demo is over; the sandbox stops the instant you delete the deployment. ### 7\. CI/CD agents that ping Slack and GitHub on every deploy Stdio MCPs do not survive in CI. Each pipeline run is a fresh shell — no long-lived processes, no `npx` hanging around. The natural fit is an MCP that lives on a URL, not a port. Hosted GitHub + hosted Slack + a tiny script in your CI: ``` // Post-deploy hook const agent = createAgent({ mcps: [ { url: process.env.GITHUB_MCP_URL, token: process.env.GITHUB_MCP_TOKEN }, { url: process.env.SLACK_MCP_URL, token: process.env.SLACK_MCP_TOKEN }, ], }); await agent.run(` Summarise the changes in commit ${process.env.SHA}. Post the summary to #deploys with the PR link. `); ``` The deploy bot writes its own changelog. The hosted MCPs handle auth, transport, and the actual API calls. ## How to deploy an MCP server to the cloud (3 steps) The whole point is that this is not a tutorial. Three steps, every time: 1. **Pick a server.** Open [/mcp-hosted](/mcp-hosted) and choose from the catalog — GitHub, Postgres, Stripe, Atlassian, Playwright, Slack, Brave Search, Discord, HubSpot, Heroku, Render, Hostinger, Grafana, Prometheus, OpenWeather, Oracle DB, Cloudflare Docs, Hacker News, llms.txt, and more. 2. **Fill the credentials form.** Each server's form only asks for what it needs — a GitHub PAT, a Postgres URL, a Slack bot token. We never log the values. 3. **Copy the URL + bearer token.** Paste them into Claude Desktop, Cursor, [MCP Agent Studio](/mcp-agent-studio), or your own MCP client. **Free tier:** 1 active slot · 60 minutes of wall-clock runtime per month. Plenty for prototyping. Upgrade only when you need parallelism or longer-running agents. ## Hosted vs self-hosted MCP servers — when each makes sense Aspect Self-hosted (npx/docker) Hosted on MCP Playground Setup time per server 5 – 30 min ~30 sec HTTPS + bearer auth You configure Issued automatically Updates & patches Your job We pull latest versions Sandboxing Docker if you bother E2B isolated sandbox Reachable from anywhere Only if you tunnel Public HTTPS by default Cost at small scale Server + DNS + TLS Free tier available Self-hosting still wins when you need an MCP server living inside your VPC reaching private resources — there is no substitute for a server you fully own. For everything else, the time you save with a hosted MCP server is worth the migration. ## How MCP Playground can help MCP Playground gives you three things in one place — and the hosted MCP feature ties them together. **One:** deploy any of [30+ curated MCP servers](/mcp-hosted) with one click. **Two:** chat with them inside [Agent Studio](/mcp-agent-studio) across 70+ models side-by-side. **Three:** save the working config as a reusable agent, then export it as a callable API. If you want to keep your existing agent stack, just take the URL — every hosted MCP works in Claude Desktop, Cursor, Continue, and any custom MCP client. ## FAQ — hosted MCP server **Do hosted MCP servers work with Claude Desktop and Cursor? +** Yes. Both Claude Desktop and Cursor accept any MCP server reachable over HTTP. Paste the URL + bearer token from [/mcp-hosted](/mcp-hosted) into the client's `mcp.json` config under `transport: "http"`. **Is there a free hosted MCP server tier? +** Yes. The Hobby tier is free and gives you 1 active hosted deployment and 60 minutes of wall-clock runtime per month — enough to prototype most agents. Pro at $25.99/mo gets you 2 slots and 600 minutes. **Can I deploy a custom MCP server, not just the ones in the catalog? +** The current catalog covers 30+ popular servers (GitHub, Postgres, Stripe, Slack, Atlassian, Playwright, MongoDB, and more). Custom-repo deployment from GitHub is on the roadmap — for now the easiest path is to file a request for any server we are missing. **How secure is a hosted MCP server? +** Each deployment runs in its own E2B sandbox — no shared filesystem with other deployments, no network access to internal infra, ephemeral by default. The bearer token gates the endpoint; without it any request 401s. Read more in [our MCP security guide](/blog/why-security-matters-in-mcp-servers). **What happens when my monthly minutes run out? +** Active deployments get stopped at the quota cap; existing data on the sandbox is gone. You can deploy again the next month, or [upgrade your plan](/settings/credits) for more headroom. The Power tier gets 5 slots and 3,000 min/month; Team gets 10 slots and 10,000 min/month. **Can a hosted MCP server reach my private database? +** Only if your database is reachable from the public internet — Supabase pooler, Neon, RDS with a public endpoint, etc. Localhost or VPC-only databases need a tunnel (Tailscale Funnel, ngrok). The Postgres MCPs force SSL by default; pass `?sslmode=disable` only for local boxes. ### Deploy your first hosted MCP server Free tier — no credit card. Click Deploy, get an HTTPS URL in 30 seconds, paste into any MCP client. [Deploy a hosted MCP →](/mcp-hosted) [Try it in Agent Studio](/mcp-agent-studio) ## Wrapping up Hosted MCP servers remove the only real friction between "MCP is interesting" and "MCP is shipping". A URL works in Cursor, Claude Desktop, your CI, and your demo — no infra to baby. Pick one of the seven use cases above, spin up the matching server on [MCP Playground's hosted page](/mcp-hosted), and you should have a working agent before this post finishes loading. ## Frequently asked questions ### Do hosted MCP servers work with Claude Desktop and Cursor? Yes. Both Claude Desktop and Cursor accept any MCP server reachable over HTTP. Paste the URL + bearer token from /mcp-hosted into the client\u2019s mcp.json config under transport: "http". ### Is there a free hosted MCP server tier? Yes. The Hobby tier is free and gives 1 active hosted deployment and 60 minutes of wall-clock runtime per month. Pro at $25.99/mo gets you 2 slots and 600 minutes. ### Can I deploy a custom MCP server, not just the ones in the catalog? The current catalog covers 30+ popular servers (GitHub, Postgres, Stripe, Slack, Atlassian, Playwright, MongoDB, and more). Custom-repo deployment is on the roadmap; file a request for any server we are missing. ### How secure is a hosted MCP server? Each deployment runs in its own E2B sandbox \u2014 isolated filesystem, no internal network access, ephemeral by default. The bearer token gates the endpoint; without it requests 401. ### What happens when my monthly minutes run out? Active deployments get stopped at the quota cap. You can redeploy next month or upgrade for more headroom. Power = 5 slots and 3,000 min/month; Team = 10 slots and 10,000 min/month. ### Can a hosted MCP server reach my private database? Only if your database is reachable from the public internet (Supabase pooler, Neon, RDS public endpoint). Localhost or VPC-only databases need a tunnel like Tailscale Funnel or ngrok. --- _Canonical page: https://mcpplaygroundonline.com/blog/hosted-mcp-server-use-cases — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # MongoDB MCP Server: Build an AI Agent for Natural-Language Mongo Queries > Spin up a hosted MongoDB MCP server in seconds — or self-host the official mongodb-mcp-server. Connect Claude, GPT-5, Gemini or DeepSeek and run queries, aggregation pipelines and schema audits in plain English. **Source:** https://mcpplaygroundonline.com/blog/mongodb-mcp-server-natural-language-queries-ai-agent **Author:** Nikhil Tiwari **Published:** 2026-05-10 **Updated:** 2026-05-18 **Category:** Recipe **Reading time:** 14 min read --- _Updated: May 18, 2026 — added the hosted MongoDB MCP option (one-click cloud deploy, live URL + bearer token)._ 🍃 MCP Recipe - **What you'll build:** An AI agent that talks to MongoDB in natural language — queries, aggregations, schema inspection, and Atlas cluster management - **MCP server:** `mongodb-mcp-server` (official, maintained by mongodb-js) - **Fast path:** [Deploy hosted MongoDB MCP](/mcp-hosted) — live HTTPS URL + token in ~30 seconds, no install - **Local path:** 10–15 minutes (Node.js + connection string) - **Difficulty:** Beginner-friendly ⚡ Skip the install — spin up a hosted MongoDB MCP server in seconds If you don't want to keep `npx mongodb-mcp-server` running on a laptop or pay for a long-lived VM, deploy the **hosted MongoDB MCP server** on MCP Playground. Same official `mongodb-mcp-server`, managed for you. - **Live HTTPS URL + bearer token in ~30 seconds** — paste your Mongo connection string into a form, click Deploy - Runs in an isolated cloud sandbox — your connection string never leaves the deployment, the URL is gated by the bearer token - Works with Claude Desktop, Cursor, Claude Code, MCP Agent Studio and any MCP-compatible agent - Free tier: 1 active server, 10 min/month. Pro tiers add more slots and runtime - Same tool surface (`find`, `aggregate`, `countDocuments`, `$indexStats`, Atlas Admin) — your prompts port 1:1 [Deploy hosted MongoDB MCP →](/mcp-hosted) The **MongoDB MCP server** turns any Claude, GPT-5, Gemini, DeepSeek or Grok client into a Mongo-fluent analyst. It exposes your collections, the aggregation framework, indexes, the slow-query profiler and Atlas cluster controls as MCP tools — so you can ask _"show me daily signups for the last 30 days, broken down by source"_ and get an actual `aggregate()` pipeline run against your data. This recipe covers both paths: the **hosted route** (~30 seconds, no install) for anyone who wants to get started immediately, and the **self-hosted route** for teams that need to run the server on their own network or against a database that's only reachable from a private VPC. The walkthrough then covers five queries that show off analytics, debugging and ops tasks, and explains connection-string mode (any Mongo) vs Atlas service-account mode (cluster management). ## What the MongoDB MCP Server Provides The server is maintained by the official [mongodb-js org](https://github.com/mongodb-js/mongodb-mcp-server) and ships as the `mongodb-mcp-server` npm package. It exposes two distinct toolsets, depending on which credentials you pass at startup: Toolset How to enable What you can do **Database tools** Pass `--connectionString "mongodb+srv://…"` List databases and collections, run `find`, `aggregate`, `countDocuments`, inspect indexes, profile slow queries, infer schemas from samples **Atlas tools** Pass `--apiClientId` + `--apiClientSecret` List clusters, check replica-set status, view metrics, manage database users, inspect Atlas Search indexes You can pass both at once for a fully-armed agent. The `--readOnly` flag locks the server to non-mutating commands — strongly recommended until you trust write operations. ## Prerequisites **Node.js 18+** For `npx` — no global install needed **A MongoDB cluster** Local, Atlas, or self-hosted — anything reachable via a connection string **Read-only DB user** Strongly recommended — create a user with read-only roles for the DBs you want to expose ## Step 1: Start the Server with HTTP Transport The default transport is stdio (good for Claude Desktop / Cursor). For browser-based clients like [MCP Agent Studio](/mcp-agent-studio) you need HTTP — pass `--transport http`: ``` npx -y mongodb-mcp-server@latest \ --transport http \ --connectionString "mongodb+srv://USER:PASS@your-cluster.mongodb.net/your-db" \ --readOnly ``` The server listens on `http://127.0.0.1:3000` by default. Override with `--httpHost` and `--httpPort` if needed. Keep the process running — in production you'll want it under `pm2`, `systemd`, or in a container. Security The HTTP transport has **no built-in auth**. Run it on localhost only, or front it with a reverse proxy that adds an auth header before exposing it publicly. Never put a connection string with write privileges on a public endpoint. ## Step 2: Connect from MCP Agent Studio (Browser, No Install) Easiest way to drive the server: [MCP Agent Studio](/mcp-agent-studio). Pick the pre-built [MongoDB Agent template](/templates/mongodb-agent) — it ships with a system prompt tuned for analytics, schema work and aggregation pipelines. 1. Open [/templates/mongodb-agent](/templates/mongodb-agent) and click **Open in Studio**. 2. Paste `http://localhost:3000/mcp` into the **MCP server URL** field. 3. Pick a model — Claude Sonnet 4.5 is the default; Opus 4.7 is the strongest for complex aggregation pipelines. 4. Send a first message: _"List all databases on this cluster."_ If you'd rather use Claude Desktop or Cursor, skip the `--transport http` flag — those clients speak stdio natively. ## Step 3: Five Queries That Show What the Agent Can Do ### 1\. Schema discovery Prompt "Sample 100 documents from the `users` collection and tell me the field types — flag any field that's sometimes missing or has inconsistent types." The agent uses the `mongodb-aggregate` tool with a `$sample` stage, then infers the schema. Useful when joining a project with no schema docs, or when you suspect a producer is writing the wrong shape. ### 2\. Natural-language analytics Prompt "Daily signups for the last 30 days, grouped by signup source. Sort newest first." The model writes a pipeline with `$match` on `createdAt`, `$group` by date and source, `$sort` descending. You see the pipeline before it runs — copy it into your code if you want to reuse it. ### 3\. Index audit Prompt "Which indexes on the `events` collection have not been used in the last 24 hours? Show me which ones I can safely drop." Calls `$indexStats` and filters by `accesses.ops` and `accesses.since`. Surfaces dead indexes that are wasting RAM. Pair with the _"recommend an index for this slow query"_ prompt for a full index review. ### 4\. Slow-query triage Prompt "Look at `system.profile` from the last hour. Group slow queries by `ns` and tell me which collections are getting hammered, with the worst offending shape for each." Requires the profiler to be enabled (`db.setProfilingLevel(1, { slowms: 100 })`). The agent groups queries by namespace, surfaces the worst `command` shape, and suggests an index when the answer is obvious. ### 5\. Atlas cluster snapshot Prompt "Give me a one-paragraph status of every cluster in this Atlas project — name, region, tier, and any node that's lagging in replica set sync." Only works when you start the server with `--apiClientId` + `--apiClientSecret`. The Atlas toolset uses the public Atlas Admin API under the hood. ## Picking the Right Model Mongo aggregation pipelines are non-trivial to write, so model choice matters more here than for, say, a Slack-message agent. Model When to pick it **Claude Opus 4.7** Complex multi-stage pipelines, schema inference across heterogeneous documents, when correctness > cost **Claude Sonnet 4.5** Default. Handles 95% of analytics queries, much cheaper **GPT-5.4** Strong on Atlas-side ops (cluster status, user management); slightly weaker than Claude on aggregation pipeline composition **DeepSeek V4 Pro** Cheapest competent option — good for batch jobs that run the same prompt against many collections Use [Compare mode](/mcp-agent-studio) in Agent Studio to send the same Mongo prompt to two models side-by-side — you'll see whose pipeline is correct in seconds. ## Connection String vs Atlas Service Account Two auth modes, two different sets of tools — easy to confuse: - **Connection string** (`--connectionString`): Standard MongoDB URI. The agent can read/write data and inspect schemas. Works with any Mongo (local, Atlas, RDS-style hosted Mongo, self-hosted). **This is what you want for analytics.** - **Atlas service account** (`--apiClientId` + `--apiClientSecret`): Atlas Admin API credentials. The agent can manage clusters, users, network access lists, and Search indexes — but cannot read your data. **This is what you want for ops.** Pass both for the full picture. Create the service account at [cloud.mongodb.com](https://cloud.mongodb.com/) → **Access Manager → Service Accounts**. ## Production Notes - **Always pair `--readOnly` with prod connection strings** until you've verified the system prompt prevents accidental writes. - **Use a dedicated read-only DB user.** Don't reuse the user your app writes with. Grant only the databases the agent should see. - **The HTTP transport has no auth.** Bind to `127.0.0.1`, or front with an auth proxy. Never expose `0.0.0.0:3000` to the public internet. - **Profiler queries can be heavy.** If you enable the slow-query profiler, scope it to a database (not all of them) and use `slowms: 100` or higher. - **Aggregation result sizes** can blow up the model's context window. The default system prompt in the [MongoDB Agent template](/templates/mongodb-agent) caps results at 50 documents — keep that in your own prompts. Skip the install — get a hosted MongoDB MCP in 30 seconds Live HTTPS URL + bearer token, managed cloud sandbox. Works with Claude Desktop, Cursor, MCP Agent Studio and any MCP-compatible agent. Free tier available. [Deploy hosted MongoDB MCP →](/mcp-hosted) [Open MongoDB Agent template](/templates/mongodb-agent) ## Related Recipes - [PostgreSQL MCP: Build a Claude Analytics Agent](/blog/postgres-mcp-claude-analytics-agent-recipe) - [Build an AI Database Query Assistant (Supabase MCP)](/blog/build-ai-database-query-assistant-natural-language-sql) - [Best AI Model for MCP Tool Calling](/blog/best-ai-model-for-mcp-tool-calling) ## Frequently Asked Questions **Hosted vs self-hosted MongoDB MCP — which should I use?** Use **hosted** (on [/mcp-hosted](/mcp-hosted)) when you want to be running queries in ~30 seconds, your Mongo cluster is reachable from the public internet (Atlas, RDS-style hosted Mongo, anything not VPC-private), and you don't want to keep a process running on a laptop. Use **self-hosted** when your database is VPC-private or on a corporate network, you have hard data-residency requirements, or you're integrating into a CI runner that already has Node available. Both expose the same official `mongodb-mcp-server` tool surface — your prompts and pipelines port 1:1. **Does the official MongoDB MCP server support write operations?** Yes — by default it can run `insert`, `update`, `delete` and DDL commands. Pass `--readOnly` to lock it to non-mutating commands. Until you trust the system prompt, always pair production credentials with `--readOnly`. **Is there a hosted MongoDB MCP server I can use without running anything myself?** Yes — [MCP Playground](/mcp-hosted) offers a managed deployment of the official `mongodb-mcp-server`. Click **MongoDB** on [/mcp-hosted](/mcp-hosted), paste your connection string, click Deploy — you get a live HTTPS URL and bearer token in ~30 seconds. There's still no first-party endpoint at a URL like `mcp.mongodb.com` from MongoDB Inc., so for now the hosted option is either MCP Playground's managed deployment or self-hosting on your own infrastructure. **Can I use this with MongoDB Atlas?** Yes — pass your Atlas connection string to `--connectionString` for data tools, and an Atlas service-account client ID + secret to `--apiClientId` / `--apiClientSecret` for cluster-management tools. You can pass both at the same time. **Why does the agent need to see my schema first?** MongoDB is schema-less, so the model can't generate correct queries without seeing real document shapes. The first thing the agent typically does is sample a collection (`$sample` stage) to learn field names and types. This is normal — once it has the schema for a collection it caches it for the rest of the conversation. **Which AI model is best for MongoDB aggregation pipelines?** For complex multi-stage pipelines, Claude Opus 4.7 and Claude Sonnet 4.5 are the strongest. GPT-5.4 is competitive but occasionally botches stage ordering. DeepSeek V4 Pro is the cheapest option that still gets non-trivial pipelines right. Use [Compare mode](/mcp-agent-studio) in Agent Studio to test on your own collection. ## Frequently asked questions ### Does the official MongoDB MCP server support write operations? Yes — by default it can run insert, update, delete and DDL commands. Pass --readOnly to lock it to non-mutating commands. Until you trust the system prompt, always pair production credentials with --readOnly. ### Is there a hosted MongoDB MCP endpoint, like Supabase has? No. As of May 2026, there is no hosted MCP endpoint at a URL like mcp.mongodb.com. You self-host the official mongodb-mcp-server with your connection string, then point any MCP client at it. ### Can I use this with MongoDB Atlas? Yes — pass your Atlas connection string to --connectionString for data tools, and an Atlas service-account client ID + secret to --apiClientId / --apiClientSecret for cluster-management tools. You can pass both at the same time. ### Why does the agent need to see my schema first? MongoDB is schema-less, so the model cannot generate correct queries without seeing real document shapes. The first thing the agent typically does is sample a collection ($sample stage) to learn field names and types. This is normal — once it has the schema for a collection it caches it for the rest of the conversation. ### Which AI model is best for MongoDB aggregation pipelines? For complex multi-stage pipelines, Claude Opus 4.7 and Claude Sonnet 4.5 are the strongest. GPT-5.4 is competitive but occasionally botches stage ordering. DeepSeek V4 Pro is the cheapest option that still gets non-trivial pipelines right. --- _Canonical page: https://mcpplaygroundonline.com/blog/mongodb-mcp-server-natural-language-queries-ai-agent — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._ --- # Part 3 — Further guides (links only) These did not fit the inline budget. Each is available as clean Markdown by appending `.md` to its URL. - [Datadog MCP: AI-Powered Alert Triage and Dashboard Queries (Bits AI Setup)](https://mcpplaygroundonline.com/blog/datadog-mcp-server-ai-alert-triage-dashboard-queries): Connect Claude (or GPT, Gemini, Grok) to Datadog with the official Bits AI MCP server. Triage alerts, query metrics, search logs and pull APM traces in plain English. No OAuth dance required — two API keys and you are live. - [How to Test Your MCP Server with Z.AI GLM Models (2026 Guide)](https://mcpplaygroundonline.com/blog/test-mcp-server-with-glm-models): Step-by-step guide to testing any MCP server with Z.AI GLM — GLM 5.3, GLM 5.2, and GLM 4.7 Flash — using MCP Agent Studio. Updated with real tool-calling test results. No API keys, no setup, no code. - [How to Test Your MCP Server with ChatGPT and the OpenAI MCP Tool (2026 Guide)](https://mcpplaygroundonline.com/blog/test-mcp-server-with-chatgpt-and-openai): Step-by-step guide to testing any MCP server with ChatGPT Developer Mode, the OpenAI Responses API mcp tool, the OpenAI Agents SDK, and Codex CLI. Code samples, security pitfalls, and the read-only vs write asymmetry no one warns you about. - [How to Test an AI Agent with MCP Servers Without Burning Tokens](https://mcpplaygroundonline.com/blog/how-to-test-ai-agent-with-mcp): A five-layer method to test an AI agent with MCP servers — Inspector for schema, MCP Playground for the LLM layers, Promptfoo for regression. Cheap models first, frontier models last. - [AI Agent + MCP Explained: What Every Developer Needs to Know in 2026](https://mcpplaygroundonline.com/blog/ai-agent-mcp-explained): An AI agent + MCP setup is an LLM that can reach external tools and data through the Model Context Protocol — three swappable layers, one open standard, and the default architecture for any agent that touches the world outside its context window. - [Claude Desktop Alternative: 7 Browser-Based MCP Clients Compared (2026)](https://mcpplaygroundonline.com/blog/claude-desktop-alternative-browser-mcp-clients-2026): Claude Desktop locks you to one model and requires a local install. Here are seven tools that let you connect any MCP server from your browser — no setup, any AI model you want. - [AI for Sales Ops: Run HubSpot, Slack and Linear From One Chat Agent](https://mcpplaygroundonline.com/blog/ai-sales-ops-hubspot-slack-linear-agent): Connect HubSpot, Slack and Linear to a single AI agent and manage your entire sales pipeline from one conversation — no tab switching, no copy-pasting. Exact setup using the official MCP servers for each tool. - [AI for DevOps: GitHub, Cloudflare and Sentry in One Agent](https://mcpplaygroundonline.com/blog/ai-devops-github-cloudflare-sentry-stack): Connect GitHub, Cloudflare and Sentry to one AI agent — inspect commits, check Worker deployments, triage production errors and trace a Sentry alert back to the offending commit without switching tabs. - [AI for Customer Success: Stripe, Slack and Linear in One Agent](https://mcpplaygroundonline.com/blog/ai-customer-success-stripe-slack-linear-setup): A customer success agent that pulls Stripe billing, Slack conversations and Linear tickets into a single chat — see a customer's full health picture in one prompt, spot churn signals early, and log follow-ups without switching tools. - [Build MCP Apps: Add Interactive UIs to Any MCP Server (2026)](https://mcpplaygroundonline.com/blog/build-mcp-apps-developer-guide): Learn how to build MCP Apps — add interactive dashboards, forms, and charts to MCP servers. Covers the ext-apps SDK, security model, framework support, and step-by-step code examples. - [How to Test Your MCP Server with Google Gemini Models (2026 Guide)](https://mcpplaygroundonline.com/blog/test-mcp-server-with-gemini-models): Step-by-step guide to testing any MCP server with Google Gemini — Gemini 3.1 Pro, Gemini 3.1 Flash Lite, Gemini 3 Flash, and Gemma 4 — using MCP Agent Studio. No API keys required. - [Best AI Model for MCP Tool Calling in 2026: Claude, GPT-5.4, Gemini 3.1 Pro, GLM-5.1 & More](https://mcpplaygroundonline.com/blog/best-ai-model-for-mcp-tool-calling): We compared 30+ AI models on real MCP tool calling — including Claude Opus 4.6, GPT-5.4, Gemini 3.1 Pro, GLM-5.1, Grok 4.20, DeepSeek V3.2 and more. Here is what BFCL V4, MCP Atlas, and TAU2-Bench actually show in April 2026. - [How to Test Your MCP Server with Alibaba Qwen Models (April 2026 Guide)](https://mcpplaygroundonline.com/blog/test-mcp-server-with-qwen-models): Step-by-step guide to testing any MCP server with Alibaba Qwen — Qwen 3.6 Plus, Qwen3.5 397B, Qwen3 235B, and Qwen3 30B — using MCP Agent Studio. No API keys required. - [MCP Agent Studio: Chat with Your MCP Server Using AI (Complete Guide)](https://mcpplaygroundonline.com/blog/mcp-agent-studio-guide): MCP Agent Studio lets you have a real AI conversation that drives your MCP server's tools — no code, no config, just paste a URL and start chatting. Here's how it works and how to get the most out of it. - [What Is an MCP Agent? How AI Models Drive MCP Tools in Real Time](https://mcpplaygroundonline.com/blog/what-is-mcp-agent-tool-calling): An MCP agent is what happens when you give an AI model the ability to call your MCP server's tools — in a loop, reasoning step by step. Here's how it works, why it matters, and how to try it yourself. - [MCP Token Counter: Why Your Tools Are Silently Eating Your Context Window](https://mcpplaygroundonline.com/blog/mcp-token-counter-optimize-context-window): Every MCP tool definition is sent to the model on every single request — even tools that never get used. A server with 50 tools can burn 10,000+ tokens before your first message. Here's how to measure it and fix it. - [5 MCP Automation Recipes Every Developer Should Steal in 2026](https://mcpplaygroundonline.com/blog/mcp-automation-workflows-developer-recipes-2026): Playwright MCP lets Claude run and fix browser tests in a closed loop. GitHub MCP turns a natural language prompt into a full PR. Supabase MCP writes migrations and updates RLS from one message. Here are 5 copy-paste workflows that save hours every week. - [MCP 2026 Roadmap: Linux Foundation Move, MCP Apps & A2A Protocol Updates](https://mcpplaygroundonline.com/blog/mcp-2026-roadmap-whats-changing-for-developers): Model Context Protocol 2026 roadmap explained: MCP joined the Linux Foundation on Dec 9, 2025. MCP Apps shipped Jan 26, 2026 with 9 launch partners. Google's A2A protocol now shares governance. Every spec change, breaking change and what developers should ship next. - [How to Automate Reddit Ads with Claude AI and MCP — Subreddit Intelligence, Community Targeting, and Real Results](https://mcpplaygroundonline.com/blog/reddit-ads-mcp-claude-automation-guide): Reddit's eCPM is $2.29 versus Meta's $11.73 — but most advertisers never unlock why certain subreddits convert and others don't. The Reddit Ads MCP server gives Claude live access to your campaigns, ad groups, and community-level performance data. Here are five workflows built for Reddit's unique signals. - [10 Things You Can Do With the GitHub MCP Server](https://mcpplaygroundonline.com/blog/10-things-you-can-do-with-github-mcp-server): GitHub's official MCP server gives your AI assistant direct access to repos, PRs, issues, Actions, security alerts, and code search — 105+ tools covering the entire GitHub workflow. - [How to Deploy MCP Servers: Vercel vs Railway vs Render vs Heroku vs Fly.io (2026 Guide)](https://mcpplaygroundonline.com/blog/deploy-mcp-server-vercel-railway-render-heroku-flyio): Complete guide to deploying remote MCP servers on the top 5 cloud platforms. Compare Vercel, Railway, Render, Heroku, and Fly.io — pricing, cold starts, Redis support, code examples, and which platform to choose for your MCP server. - [10 Things You Can Do With Railway MCP Server (2026 Update)](https://mcpplaygroundonline.com/blog/10-things-you-can-do-with-railway-mcp-server-official): Railway MCP moved. It is now a hosted server at mcp.railway.com that you connect through the Railway CLI or OAuth, not an npx package. Here are the ten things it does, the full tool list for both the remote and local servers, and the setup for every supported editor. - [10 Things You Can Do With Vercel MCP Server](https://mcpplaygroundonline.com/blog/10-things-you-can-do-with-vercel-mcp-official-server): Vercel’s official Model Context Protocol server at mcp.vercel.com: search docs, manage projects and deployments, debug build and runtime logs, domains, protected previews, deploy from your AI client, and project-specific URLs—per Vercel’s own documentation. - [MCP Config File Location: Claude Desktop, Cursor & Claude Code (Mac, Windows, Linux)](https://mcpplaygroundonline.com/blog/complete-guide-mcp-config-files-claude-desktop-cursor-lovable): Claude Desktop MCP config path: ~/Library/Application Support/Claude/claude_desktop_config.json on Mac, %APPDATA%\Claude\claude_desktop_config.json on Windows. Full file paths and JSON format for Cursor mcp.json, Claude Code, Cline, Continue, Zed and Lovable — with copy-paste examples. - [How to Test Any MCP Server Online — No Setup Required](https://mcpplaygroundonline.com/blog/how-to-test-mcp-server-online-no-setup-required): You built (or found) an MCP server and want to see what it actually does before wiring it into your editor. This guide shows you how to test any remote MCP server from your browser in under a minute — no local installation, no config files. - [How Datadog's MCP Server Brings Live Observability to AI Agents](https://mcpplaygroundonline.com/blog/datadog-mcp-server-live-observability-ai-agents): Datadog's remote MCP server (GA March 2026) bridges the gap between AI coding agents and live production observability. Query logs, metrics, traces, and incidents directly from Claude Code, Cursor, or GitHub Copilot — no tab-switching required. - [From Shodan to Shell: How Attackers Find and Exploit Exposed MCP Servers — And How to Check Yours](https://mcpplaygroundonline.com/blog/mcp-server-security-complete-guide-2026): A real attacker needs under 3 minutes to find your exposed MCP server on Shodan, enumerate every tool without credentials, and exfiltrate database tokens. This is the server owner's breach playbook: CVE-2025-6514 (CVSS 9.6), the Clawdbot mass breach (17,903 servers), MCP Sampling abuse, supply chain attacks — and the free scanner that shows you exactly what attackers see when they hit your URL. - [Cross-Platform Ad Reporting with Claude AI and MCP — One Prompt for All Your Ad Data](https://mcpplaygroundonline.com/blog/cross-platform-ad-reporting-mcp-claude-guide): Most advertisers optimize each platform in a silo and never see the full picture. The real waste in paid media isn't inside Google Ads or Meta — it's in the gap between platforms. With Claude connected to all your ad accounts simultaneously via MCP, you can ask one question and get an answer that spans Google, Meta, Amazon, LinkedIn, TikTok, Pinterest, X, and Snapchat at once. - [How to Add Authentication to Your MCP Server — OAuth 2.1, Bearer Tokens, and What the Spec Actually Requires (2026)](https://mcpplaygroundonline.com/blog/mcp-server-oauth-authentication-guide): Every developer who publishes a remote MCP server eventually hits the same wall: how do I stop anyone on the internet from calling my tools? This guide covers three practical approaches — API key bearer tokens for internal tools, Cloudflare Access for zero-code protection, and full OAuth 2.1 with PKCE for public servers — plus the five security mistakes that lead to account takeovers. - [How to Automate Snapchat Ads with Claude AI and MCP — AR Intelligence, Story Performance, and Real Results](https://mcpplaygroundonline.com/blog/snapchat-ads-mcp-claude-automation-guide): Snapchat reaches 90% of 13–24 year olds — but most advertisers never get past surface-level metrics. Swipe-up rate, story completion rate, and AR lens engagement tell a story that Ads Manager buries in manual exports. The Snapchat Ads MCP server gives Claude live access to your campaigns, ad squads, and creative data. Here are five workflows built for the platform's unique signals. - [Build and Deploy an MCP Server on Cloudflare Workers — Complete Guide (2026)](https://mcpplaygroundonline.com/blog/build-mcp-server-cloudflare-workers-guide): Cloudflare Workers is the fastest path from MCP idea to globally deployed server — zero cold starts, 300+ edge locations, and a free tier covering 100k requests/day. This guide covers both the McpAgent (Agents SDK) and workers-mcp approaches with real TypeScript code, KV storage, wrangler deployment, and Claude Desktop connection. - [How to Automate X (Twitter) Ads with Claude AI and MCP — Honest Workflows for a Platform in Transition](https://mcpplaygroundonline.com/blog/x-twitter-ads-mcp-claude-automation-guide): X shipped an official MCP server at api.x.com/mcp in June 2026 — but it does not touch advertising. Here is what XMCP actually covers, which third-party servers you still need for campaign management, and the X Ads workflows that genuinely pay off. - [How to Automate TikTok Ads with Claude AI and MCP — Workflows, Creative Intelligence, and Real Results](https://mcpplaygroundonline.com/blog/tiktok-ads-mcp-claude-automation-guide): TikTok shipped an official MCP server — no developer app, no approval queue, just sign in with your TikTok for Business account. It comes in two flavours (~400 tools or ~40), and which you pick matters more than you would think. Here is how to connect it, the two gotchas that will bite you, and five workflows that change how you run TikTok paid media. - [How to Automate Pinterest Ads with Claude AI and MCP — E-Commerce Workflows, Shopping Ads, and Real Results](https://mcpplaygroundonline.com/blog/pinterest-ads-mcp-claude-automation-guide): Pinterest is the only ad platform where users arrive already planning to buy. Save rate, closeup rate, and shopping catalog performance tell a story no other platform can — and most advertisers never read it. The Pinterest Ads MCP server gives Claude live access to your campaigns, Pin metrics, and product data. Here are five workflows built for e-commerce. - [How to Automate Google Ads with Claude AI and MCP — Tools, Workflows, and Real Results](https://mcpplaygroundonline.com/blog/google-ads-mcp-claude-automation-guide): The Google Ads MCP server gives Claude live access to your campaign data. Here is how to connect it, which of the four available servers to use, and five real PPC workflows that replace hours of manual work. - [How to Automate Amazon Ads with Claude AI and MCP — Workflows, Tools, and Real Results](https://mcpplaygroundonline.com/blog/amazon-ads-mcp-claude-automation-guide): Amazon's official MCP server launched in open beta February 2026, giving Claude live access to Sponsored Products, DSP, and Amazon Marketing Cloud. Here is how to connect it and five workflows that replace hours of manual PPC management. - [How to Automate LinkedIn Ads with Claude AI and MCP — B2B Workflows That Actually Work](https://mcpplaygroundonline.com/blog/linkedin-ads-mcp-claude-b2b-automation-guide): LinkedIn drives 75–85% of B2B social leads, and most of that spend is managed manually. The LinkedIn Ads MCP server gives Claude live access to your campaign data, audience demographics, and lead gen forms. Here are five workflows that cut CPL and save 10+ hours a week. - [10 Real Automations You Can Build with Zapier MCP + Claude Right Now](https://mcpplaygroundonline.com/blog/zapier-mcp-claude-automations-guide): Zapier MCP gives Claude live access to 8,000+ apps. Here are 10 practical automations — from morning briefing agents to lead enrichment pipelines — you can set up today without writing a single line of code. - [Build an AI Standup Bot with Slack + Gmail MCP (Complete Recipe)](https://mcpplaygroundonline.com/blog/slack-email-standup-bot-mcp-recipe): Step-by-step guide to building an AI standup bot that reads your Slack channels and Gmail inbox, synthesises key updates, and posts a daily summary to your team channel automatically. Uses Slack MCP + Gmail MCP + Claude. - [How to Automate Meta Ads with Claude AI and MCP — Real Workflows, Real Results](https://mcpplaygroundonline.com/blog/automate-meta-ads-claude-ai-mcp): Meta shipped an official MCP server at mcp.facebook.com/ads in April 2026 — no Developer App, no App Review, just Business OAuth. Here is how to connect Claude to your Facebook and Instagram campaigns, which of the seven OAuth scopes actually matter, and the workflows that pay for themselves. - [Claude MCP Apps — Full Guide: Interactive UIs Inside AI Conversations (2026)](https://mcpplaygroundonline.com/blog/claude-mcp-apps-full-guide): Everything you need to know about Claude MCP Apps — the January 2026 update that lets AI render dashboards, forms, and charts directly in Claude. Covers how it works, all 10 launch partners, security model, and how to build your own MCP App. - [MCP vs REST API — What's Different? Complete Developer Comparison (2026)](https://mcpplaygroundonline.com/blog/mcp-vs-rest-api-whats-different): MCP and REST API solve different problems. Learn the key architectural differences between Model Context Protocol and REST — stateful vs stateless, JSON-RPC vs HTTP verbs, tools vs endpoints — and when to use each in 2026. - [Where to Host MCP Servers for Free: Cloudflare, Vercel, and More (2026)](https://mcpplaygroundonline.com/blog/free-mcp-server-hosting-cloudflare-vercel-guide): Compare every free MCP server hosting option in 2026. Deploy to Cloudflare Workers, Vercel, FastMCP Cloud, mcphosting.io, or a VPS — with step-by-step setup for each platform. - [MCP Server Not Working? Fix Error -32000, Timeouts, and Connection Failures (2026)](https://mcpplaygroundonline.com/blog/mcp-server-troubleshooting-common-errors-fix): The definitive troubleshooting guide for MCP server errors. Fix error -32000 (connection closed), timeouts, authentication failures, transport mismatches, and more — with step-by-step solutions for Claude Desktop, Cursor, and VS Code. - [Deploy an MCP Server to Production with Docker (Complete Guide)](https://mcpplaygroundonline.com/blog/deploy-mcp-server-docker-production-guide): How to containerize and deploy an MCP server for production. Covers Dockerfile, Docker Compose, StreamableHTTP transport, security hardening, and scaling patterns for cloud deployment. - [Multi-Agent AI with MCP: How to Use CrewAI and LangChain with MCP Servers](https://mcpplaygroundonline.com/blog/multi-agent-mcp-crewai-langchain-guide): Build multi-agent AI systems that use MCP servers for tools. Practical guide with CrewAI and LangChain examples — connect agents to GitHub, databases, and any MCP server. - [MCP vs Function Calling vs REST APIs: When to Use Each for AI Agents](https://mcpplaygroundonline.com/blog/mcp-vs-function-calling-vs-api-comparison): A practical comparison of MCP, function calling, and REST APIs for AI agent development. Covers architecture differences, pros and cons, and when to choose each approach. - [Build an AI E-commerce Order Manager with Stripe MCP + Shopify MCP](https://mcpplaygroundonline.com/blog/ecommerce-order-manager-stripe-shopify-mcp-recipe): Manage orders, refunds, and products with AI. Use the official Stripe MCP and Shopify Storefront MCP to look up payments, issue refunds, search products, and handle customer queries—all from natural language. - [Postgres MCP vs Supabase MCP: Which Should You Use? (Setup + Comparison)](https://mcpplaygroundonline.com/blog/postgres-mcp-vs-supabase-mcp-setup-comparison): Detailed comparison of PostgreSQL MCP and Supabase MCP servers. Learn the differences in tools, auth, setup, and use cases. Includes step-by-step configs for Claude Desktop and Cursor, plus when to use each. - [Context7 MCP Server: Up-to-Date Docs for Your AI Coding Assistant (Setup Guide)](https://mcpplaygroundonline.com/blog/context7-mcp-server-setup-guide): Context7 is an MCP server that fetches up-to-date library documentation so your AI assistant can reference current APIs instead of relying on training data. Setup guide for Cursor, Claude Code, VS Code, and more. - [MCP Security in 2026: Tool Poisoning, OWASP MCP Top 10, and How to Protect Your Agents](https://mcpplaygroundonline.com/blog/mcp-security-tool-poisoning-owasp-top-10-mcp-scan): The biggest security threats to MCP servers and agents in 2026: tool poisoning attacks, prompt injection, rug pulls, and the OWASP MCP Top 10. Learn how to scan with mcp-scan and protect your setup. - [PostgreSQL MCP: Build a Claude Analytics Agent (Setup + Examples)](https://mcpplaygroundonline.com/blog/postgres-mcp-claude-analytics-agent-recipe): Connect Claude to PostgreSQL with the official Postgres MCP server. Run natural language queries, explore schemas, and build an analytics agent. Includes Claude Desktop and Cursor setup, read-only SQL, and Next.js/Node.js agent patterns. - [Claude Code MCP Setup: Config File Location & Add Server Command (2026)](https://mcpplaygroundonline.com/blog/claude-code-mcp-setup-best-servers-guide): Claude Code MCP config lives in ~/.claude.json (user scope) or .mcp.json (project scope). Full file paths on Mac, Windows and Linux, the claude mcp add command syntax for HTTP/SSE/stdio transports, all 3 scopes explained, and the best MCP servers for Claude Code in 2026. - [ChatGPT MCP Support: Complete Setup Guide with OpenAI Agents SDK](https://mcpplaygroundonline.com/blog/chatgpt-mcp-openai-agents-sdk-setup-guide): ChatGPT now supports MCP servers. Learn how to connect MCP servers to ChatGPT via the OpenAI Agents SDK — hosted tools, Streamable HTTP, stdio, and ChatGPT Apps. Includes working Python examples. - [Playwright MCP: Browser Automation with AI (Complete Setup Guide)](https://mcpplaygroundonline.com/blog/playwright-mcp-browser-automation-recipe): Spin up a hosted Playwright MCP server in seconds — or run the official Microsoft Playwright MCP locally for Claude, Cursor and Claude Code. Automate browsers with AI using accessibility snapshots; no vision models required. - [Build Your First MCP Server with Python and FastMCP (Step-by-Step Tutorial)](https://mcpplaygroundonline.com/blog/build-mcp-server-python-fastmcp-tutorial): Learn to build a Model Context Protocol server in Python using FastMCP. Step-by-step tutorial with tools, resources, Claude Desktop integration, and testing. From zero to a working MCP server in 15 minutes. - [Build an AI Code Documentation Generator with MCP (GitHub + Filesystem Recipe)](https://mcpplaygroundonline.com/blog/code-documentation-generator-github-mcp-recipe): Auto-generate READMEs, API docs, and code summaries with AI. Use GitHub MCP and Filesystem MCP to read repos and source files, then produce documentation. Perfect for keeping docs in sync with code. - [Build an AI Customer Support Summarizer with MCP (Intercom + Zendesk Recipe)](https://mcpplaygroundonline.com/blog/customer-support-summarizer-intercom-zendesk-mcp-recipe): Summarize support tickets and conversations with AI. Use Intercom MCP and Zendesk MCP to pull recent tickets, generate daily digests, and highlight urgent issues. Perfect for support leads and CX teams. - [Build an AI-Powered File Organizer with MCP (Filesystem + Google Drive Recipe)](https://mcpplaygroundonline.com/blog/ai-powered-file-organizer-mcp-recipe): Automate file sorting and organization with AI. Use Filesystem MCP and Google Drive MCP to sort downloads, organize folders, and keep your files tidy using natural language. No manual drag-and-drop. - [Awesome MCP Servers List (70+) — Live-Tested Catalog for 2026](https://mcpplaygroundonline.com/blog/awesome-mcp-servers): The awesome MCP servers list you can actually test online. 70+ curated Model Context Protocol servers — AWS, X, Snowflake, Supabase, GitHub, Stripe, Notion, Figma, Linear, Slack, Sentry, Atlassian, HubSpot, Neon — plus 30 remote HTTP servers you can connect with one URL. Updated July 2026. - [AWS MCP Servers - Complete Guide to Amazon Web Services MCP Integration](https://mcpplaygroundonline.com/blog/aws-mcp-servers): Learn how to use AWS MCP servers to connect Claude and Cursor to Amazon Web Services. Setup guides for S3, Lambda, EC2, DynamoDB, and more AWS services. - [Remote MCP Servers - Test and Connect to MCP Servers Online](https://mcpplaygroundonline.com/blog/remote-mcp-servers): Learn about remote MCP servers and how to test them online without local installation. Discover public MCP servers you can connect to instantly from your browser. - [Build an AI GitHub PR Reviewer with MCP (Complete Recipe)](https://mcpplaygroundonline.com/blog/build-ai-github-pr-reviewer-mcp-recipe): Step-by-step guide to building an automated AI code reviewer that analyzes GitHub pull requests, suggests improvements, and posts comments. Uses GitHub MCP + Claude. - [Build an AI Database Query Assistant with Natural Language SQL (MCP Recipe)](https://mcpplaygroundonline.com/blog/build-ai-database-query-assistant-natural-language-sql): Learn to build an AI assistant that converts natural language questions into SQL queries. Query databases using plain English with Supabase MCP and Claude. No SQL knowledge required. - [Automate Jira Tasks from Meeting Notes with AI (Notion + Jira MCP Recipe)](https://mcpplaygroundonline.com/blog/automate-jira-tasks-from-meeting-notes-notion-mcp-recipe): Stop manually creating Jira tickets after meetings. Learn to automatically extract action items from Notion meeting notes and create Jira tasks using AI. Save hours every week. - [How to Set Up MCP in Claude Desktop (Complete 2026 Guide)](https://mcpplaygroundonline.com/blog/how-to-setup-mcp-claude-desktop): Step-by-step guide to configure MCP servers in Claude Desktop for April 2026. Covers the official GitHub MCP server (Docker), Supabase, Playwright, Desktop Extensions (.dxt), and remote MCP via Custom Connectors. - [Cursor IDE MCP Setup: mcp.json Location, Format & 20+ Server Examples (2026)](https://mcpplaygroundonline.com/blog/cursor-mcp-setup-guide): Cursor IDE MCP config lives in ~/.cursor/mcp.json (global) or .cursor/mcp.json in your project. Full mcp.json format, where to find the file on Mac and Windows, and copy-paste examples for Playwright, GitHub, Notion, Linear and 20+ more MCP servers. - [10 Best MCP Servers for Developers in 2026](https://mcpplaygroundonline.com/blog/best-mcp-servers-2026): Curated list of the most useful MCP servers for developers. Includes GitHub, Supabase, Playwright, Notion, Slack, and more with setup instructions. - [Model Context Protocol Discovery & Initialization](https://mcpplaygroundonline.com/blog/model-context-protocol-discovery-initialization): Learn how MCP discovery works and why it matters. This guide explains how clients discover tools, what happens during initialization, and common mistakes to avoid when building MCP servers. - [Wrap Existing APIs as MCP Tools (Simple Guide)](https://mcpplaygroundonline.com/blog/wrap-existing-apis-as-mcp-tools-simple-guide): Learn how to wrap existing REST APIs as MCP tools so AI clients can safely and reliably call them. This guide shows you how to create a thin, safe layer between AI and your APIs using Node.js + MCP. - [Build a Custom MCP Server Using Node.js (Simple Guide)](https://mcpplaygroundonline.com/blog/build-custom-mcp-server-using-nodejs-simple-guide): Learn how to build a basic MCP server using Node.js, step by step. This guide shows you how to create a clean, typed API for AI with validated inputs and predictable JSON output. - [How to Publish Your MCP Server to the MCP Registry (Step-by-Step Guide)](https://mcpplaygroundonline.com/blog/how-to-publish-your-mcp-server-to-registry): Learn how to publish your MCP server to the official MCP Registry so others can discover and use it. Includes testing tips and best practices for a smooth submission process. - [Safeguarding MCP Servers From Prompt Injection: Practical Tips From Real-World Builds](https://mcpplaygroundonline.com/blog/safeguarding-mcp-servers-from-prompt-injection): Once you give an LLM access to tools, files, or APIs through MCP, things get real very quickly. Here are practical approaches we learned by trial, error, and occasionally mild panic. - [How QA Teams Should Test MCP Servers](https://mcpplaygroundonline.com/blog/how-qa-teams-should-test-mcp-servers): A simple guide for ensuring security, reliability, and correct behavior. Learn how QA teams can effectively test MCP servers before they ship to production. - [Are MCP Servers Secure? Complete Security Guide (2026)](https://mcpplaygroundonline.com/blog/why-security-matters-in-mcp-servers): Are MCP servers secure? Learn MCP server security best practices, risks, and how to protect your systems. Complete guide to securing Model Context Protocol servers. - [What Is the Model Context Protocol (MCP)? A Developer's Guide](https://mcpplaygroundonline.com/blog/what-is-model-context-protocol): Most LLM apps hit the same wall quickly: they need fresh context and the ability to call real systems, without piles of custom glue code. That is exactly what the Model Context Protocol gives you.