DEV Community: Rupa Tiwari

Agent Skills vs MCP vs Function Calling vs A2A: When to Use Each

Rupa Tiwari — Wed, 02 Sep 2026 11:47:01 +0000

📖 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, which merges the top two.

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 keep seeing.

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.

Optional fields are license, compatibility, metadata, and the experimental allowed-tools.

Progressive disclosure is the whole trick

Skills load in three stages, and this is why they are cheap.

Discovery — only name and description load at startup, roughly 100 tokens per skill.
Activation — the full SKILL.md body loads when a task matches. Keep it under 5,000 tokens.
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, AWS Kiro, Block 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.

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

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.

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.

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.

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.

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.

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

MCP connects it to Linear, Sentry and Postgres. That is how it reads the ticket, the stack trace and the affected rows.
An Agent Skill holds your triage policy — severity ladder, escalation thresholds, the exact template your team expects.
Function calling happens invisibly underneath, when the model emits the structured call your MCP client executes.
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.

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.

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.

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 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 an MCP Eval? Why Your Server Passes Every Test and Still Fails

Rupa Tiwari — Mon, 17 Aug 2026 12:10:05 +0000

📖 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.

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 has nothing to say about the second one, and it should not — conformance is not usability. The 2026-07-28 release 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, 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.

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 →

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 grades 1,000 tasks across 36 real servers using a rubric-driven judge, and MCP-Bench 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 when:

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 when:

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

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.

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.

Related Guides

Meta's Muse Models and MCP: What the Benchmarks Actually Say

Rupa Tiwari — Tue, 11 Aug 2026 15:22:54 +0000

📖 TL;DR

Muse Spark 1.1 ranks #1 on Scale AI's MCP-Atlas leaderboard at 88.1% — ahead of Claude Opus 5 (85.8%) and Claude Fable 5 (83.3%).

Muse Glimmer 30B is Apache 2.0 and runs locally — under 20GB at 4-bit, so it fits a 24GB machine.

Glimmer is distilled from Spark via logit distillation. Teacher and student, not two sizes of one model.

Meta reports 75.5 on MCP-Atlas for Glimmer vs 62.5 (Qwen3.6-27B) and 54.2 (Gemma4-31B) — a vendor figure, not a leaderboard entry.

Glimmer loses badly at terminal and desktop control. Qwen wins TerminalBench 2.1 60.7 to 51.7 and OSWorld-Verified 75.6 to 65.9.

Neither model's tool-calling wire format is documented. Through OpenRouter both are OpenAI-shaped function callers.

Meta shipped two models a week apart in August 2026, and the relationship between them is the story. Muse Spark 1.2 is closed, API-only, with a million-token context. Muse Glimmer 30B is Apache 2.0, open-weights, and distilled from Spark — it runs on a single consumer GPU.

If you build on MCP, the student is the more interesting release. Here is why, and where the marketing stops matching the data.

MCP-Atlas is a real benchmark, and Muse tops it

Most launches give you MMLU and a coding score. Neither predicts whether a model will drive your MCP server without mangling arguments.

MCP-Atlas is different. It is Scale AI's benchmark, built specifically for Model Context Protocol tool use: 1,000 tasks across 36 real MCP servers and 220 tools, three to six tool calls per task. The model has to discover the right tool from a limited set, call it with correct parameters, handle errors, coordinate across servers, and synthesise an answer.

On Scale's public leaderboard:

Rank	Model	Pass rate
1	Muse Spark 1.1	88.1%
2	claude-opus-5 (xhigh)	85.8%
2	gemini-3.5-flash (high)	83.6%
2	Claude Fable 5	83.3%
2	kimi-k3 (max)	82.3%
2	claude-opus-4-8 (max)	82.2%

Two caveats, both load-bearing. The leaderboard was last updated April 2026, so the ranked entry is Spark 1.1, not 1.2. And Glimmer, which launched in August, is not on it at all. This is evidence the Muse line is strong at MCP work — not a verified score for the build you are calling today.

What Meta reports for Glimmer

Glimmer's numbers are from Meta's own launch table, so read them as a vendor comparison. Conditions matter: Glimmer at High Reasoning, the rivals in Thinking Mode. All best-effort configurations, not defaults.

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
τ²-Banking	23.5	16.7	15.1
GAIA2	43.3	40.0	36.4
SWE-Bench Pro	51.2	50.2	36.9
SWE-Bench Verified	76.0	77.2	66.6
TerminalBench 2.1	51.7	60.7	43.4
OSWorld-Verified	65.9	75.6	58.5

The pattern is sharper than "Glimmer wins."

Glimmer's advantage is protocol-shaped agentic work — discovering tools, invoking schemas correctly across a long workflow, recovering from failures. On MCP-Atlas the gap over Qwen is 13 points; on τ²-Banking it is a rout.

But Qwen3.6-27B takes SWE-Bench Verified, TerminalBench 2.1 and OSWorld-Verified, and those last two are not close. The honest reading: Glimmer is tuned for calling tools through a protocol, not for driving a terminal or a desktop. Strong MCP results do not transfer to computer use.

The number nobody puts in a headline

Meta also publishes safety results. 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%; 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 content that originated outside your control — search results, file contents, third-party API responses — that content reaches the model, and these are the empirical odds it can steer it. Model choice moves the margin. It does not remove the problem. The controls that matter stay on your side of the boundary.

Glimmer's architecture

A dense causal transformer — not MoE — at ~29.6B parameters including a 1.8B ViT-G/14 perception encoder. 52 layers, hidden dim 6,656, SwiGLU at 19,968 intermediate width.

Two choices stand out if you plan to run it:

GQA at 16:1 — 32 query heads against 2 KV heads. Aggressive, 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 per global one.

Context is 131,072 tokens by default, extendable to 262,144. Sampling defaults are temperature 1.0, top_p 0.95, top_k 64 — carrying over a temperature 0.2 habit from another vendor is a real source of "it did worse for me."

Full precision needs 55GB+. Quantized to ~4-bit it drops under 20GB, leaving headroom for KV cache and the perception encoder in a 24–32GB envelope. Meta reports "minimal to no degradation on agentic tasks" from that compression.

DFlash speculative decoding ships with it: a lightweight drafter proposes token blocks, the main model verifies in parallel. Output quality is identical by construction; measured speedup is 3.1x on an RTX 5090, 1.8x on an M5 Max, 1.5x on an M4 Max.

Runtimes at launch: Ollama, LM Studio, llama.cpp, MLX, ExecuTorch, vLLM, SGLang.

The one claim worth testing yourself

Meta describes three training phases — logit distillation from Spark in pre-training, extended-context agent data with reasoning traces in mid-training, then SFT blended with on-policy distillation and RL.

Buried in that is the most falsifiable claim in the launch materials:

"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 the behaviour separating a model you can leave running from one that needs a human every time an endpoint hiccups. And it takes one run to check: point the model at a server that deliberately returns errors, and watch whether it reads the error and adjusts its arguments, or apologises and stops.

Muse Spark 1.2, briefly

Closed weights, API-only. 1,048,576-token context, ~131,072 output. Accepts text, images, video, audio and PDF.

For agent builders: structured output, parallel function calling, configurable reasoning effort, and explicit multi-agent support in either role — primary planner or parallel subagent. It leans on planning, goal conditioning and context compaction to hold direction through long tasks.

Pricing is $1.25 / $4.25 per million tokens. Note the cost shape: with most models, cost tracks how much work the model does. With a 1M-context model, cost tracks how much context you chose to send — a 200k-token prompt is $0.25 before it writes a word. Compaction is a feature for a reason.

What nobody has published

Meta has not documented the tool-calling wire format for either model. The model card and developer pages assert reliable tool use and precise schema invocation, but no serialization is specified. The reference runtimes simply expose an OpenAI-compatible surface.

So: routed through a provider, both models behave as OpenAI-shaped function callers, the same path every non-Anthropic model takes. Any claim you read about how Muse specifically handles deeply nested arguments is currently untested rather than documented.

Which makes your own server the only authority that counts.

Which one

Glimmer when you want a model you can self-host, when tool calls must stay on your hardware, or when you are checking whether an open 30B is good enough to replace a frontier model on your tools.
Spark 1.2 when the task genuinely needs the context or parallel function calling — whole-repository work, long debugging sessions, multi-agent orchestration.

The distillation relationship is the mental model: Glimmer inherits Spark's agentic behaviour in a package you can run at home; Spark keeps the scale, context and modalities that will not fit on a laptop.

You can run both Muse models against your own MCP server in the browser — no install, no Meta account: Test your MCP server with Meta Muse

Full writeup with the complete benchmark tables: Muse Spark 1.2 and Muse Glimmer 30B for MCP

Sources: Meta AI Research — Introducing Muse Glimmer · Scale AI MCP-Atlas leaderboard · Muse Glimmer on Hugging Face · Muse Spark 1.2 on OpenRouter

MCP Went Stateless: Migrating to the 2026-07-28 Spec (and Proving It Works)

Rupa Tiwari — Thu, 30 Jul 2026 18:06:09 +0000

📖 TL;DR

The 2026-07-28 spec shipped final on July 28, 2026 (RC locked May 21). It is the biggest revision since MCP launched.

Sessions are gone. No initialize, no Mcp-Session-Id. Every request is self-contained.

TypeScript ships as two new packages — @modelcontextprotocol/client@2 and @modelcontextprotocol/server@2. The old @modelcontextprotocol/sdk line lives on at 1.x for 2025-era servers.

server/discover is a MUST. Mcp-Method / Mcp-Name headers are required on Streamable HTTP POSTs.

Roots, Sampling, Logging, and HTTP+SSE are deprecated with a 12-month clock.

The new #1 security bug: an unsigned requestState blob. It round-trips through the client, which makes it attacker-controlled input.

I spent last week migrating a platform that talks to other people's MCP servers in both revisions. This is the writeup I wanted before I started.

Not a spec summary — a diff, a build order, and the two things that broke in ways the changelog does not warn you about.

Stop thinking "version bump." Start thinking "era."

This is the mental model shift that makes everything else click.

Older MCP negotiated a version string during a handshake. The 2026 SDK does not model revisions as a flat list anymore. It models two eras:

Era	Revisions	How the version travels
`legacy`	2024-10-07 … 2025-11-25	Negotiated via `initialize`, carries `Mcp-Session-Id`
`modern`	2026-07-28 and later	Rides in `_meta` on every request; `server/discover` advertises capabilities up front

These are not points on one line. They are two different wire protocols that happen to share JSON-RPC.

Once you internalize that, the migration stops looking like "add a feature" and starts looking like "support a second protocol."

The wire diff: what a request actually looks like now

Forget SDK APIs for a second. Here is the part that matters, because it is what your gateway, your load balancer, and your security scanner all see.

Before (2025-11-25, stateful)

Two round trips minimum, and a session header you have to carry forever:

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2025-11-25",
  "clientInfo":{"name":"my-client","version":"1.0.0"},
  "capabilities":{}
}}

→ 200 OK
   Mcp-Session-Id: 9f2c1e7a-...      ← now sticky-route every later request here

POST /mcp HTTP/1.1
Mcp-Session-Id: 9f2c1e7a-...
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
  "name":"get_user","arguments":{"id":"123"}
}}

After (2026-07-28, stateless)

One round trip. No handshake. Everything the server needs is in the envelope:


POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Method: tools/call
Mcp-Name: get_user

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
  "name":"get_user",
  "arguments":{"id":"123"},
  "_meta":{
    "io.modelcontextprotocol/protocolVersion":"2026-07-28",
    "io.modelcontextprotocol/clientInfo":{"name":"my-client","version":"1.0.0"},
    "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}}
  }
}}

Three things to notice.

Mcp-Method and Mcp-Name are headers now (SEP-2243). A gateway can route on them without parsing the body — that is the whole point.

The _meta keys are fully qualified: io.modelcontextprotocol/protocolVersion, not protocolVersion. Getting this wrong is a silent no-op, not an error.

And the session ID is simply absent. Any instance in your cluster can serve this request.

The payoff: a remote server that needed sticky sessions and a shared session store can now sit behind a plain round-robin load balancer. That is the real reason this change happened.

Install: two packages, not one upgrade

This surprised me and it is good news. v2 did not replace the SDK — it shipped alongside it.

{
  "@modelcontextprotocol/sdk":    "^1.30.0",  // legacy line, still maintained
  "@modelcontextprotocol/client": "^2.0.0",   // new: stateless + auto-fallback
  "@modelcontextprotocol/server": "^2.0.0"    // new: for building 2026-spec servers
}

All three coexist in one package.json. No fork, no vendoring, no version pinning games.

There is a codemod for the mechanical parts:

npx @modelcontextprotocol/codemod@beta v1-to-v2 .

It handles the renames — .tool() becomes registerTool, imports move to the new packages. What it cannot do is decide your statefulness strategy, which is the actual work.

Tool schemas in v2 use Standard Schema, so Zod v4, Valibot, and ArkType all work instead of Zod-only.

The server checklist: seven concrete changes

This is the list I actually worked through. Ordered by how much it breaks if you skip it.

1. Implement server/discover. It is a MUST in the new spec. It replaces the handshake as the way a client learns your capabilities and supported versions. No server/discover, no modern-era client.

2. Stamp resultType: "complete" on every result. Cheap, mandatory, easy to forget.

3. Add ttlMs and cacheScope to tools/list, prompts/list, resources/list, resources/read, and resources/templates/list. Clients now cache tool lists like HTTP responses.

4. Order tools/list deterministically. A SHOULD, not a MUST — but unstable ordering defeats client-side caching, so it is effectively required.

5. Swap the HTTP GET stream and resources/subscribe for subscriptions/listen.

6. Drop ping, logging/setLevel, and notifications/roots/list_changed from your modern-era handler.

7. Fix your error codes. More on that next, because it is the sneakiest one.

One trap worth calling out: if your v1 server sets sessionIdGenerator: undefined and you have a comment nearby that says "stateless mode," that is not this. That is v1's stateless-session mode. It still performs the initialize handshake. It is not 2026-compliant. I had exactly this comment in my own codebase.

Error codes: grep for these today

The spec partitioned the JSON-RPC server-error range. -32000…-32019 stays implementation-defined; -32020…-32099 is now reserved for the spec.

Code	Meaning	Note
`-32020`	`HeaderMismatch`	`Mcp-Method` disagrees with the body
`-32021`	`MissingRequiredClientCapability`	You asked for something the client never advertised
`-32022`	`UnsupportedProtocolVersion`	Version in `_meta` is not supported
`-32602`	Resource not found	Changed — was `-32002`

That last row is the one that will bite you quietly:

# run this in your client codebase right now
grep -rn "32002" src/

A hardcoded -32002 check does not throw when the code changes. It just stops matching, and your "resource not found" branch silently becomes your generic-error branch.

Practical advice: accept both codes when validating, emit the era-appropriate one. The v2 SDK still ships -32002 in ProtocolErrorCode for legacy compatibility, so both are live in the wild.

Deprecations: the 12-month clock started

The spec added a formal lifecycle — Active → Deprecated → Removed — with a minimum 12-month window. Nothing here disappears before July 2027.

Roots → pass scope explicitly via tool parameters, resource URIs, or config.
Sampling → call the LLM API directly from your server. Fewer round trips anyway.
Logging → stderr or OpenTelemetry.
HTTP+SSE transport → Streamable HTTP.
includeContext: "thisServer" | "allServers"
OAuth Dynamic Client Registration → Client ID Metadata Documents.

Do not add new usage of any of these. And audit your docs and UI — mine were still advertising two of them.

Two gotchas that cost me a day

Here is the part you will not find in the changelog.

Gotcha 1: `LATEST_PROTOCOL_VERSION` is `2025-11-25`

Yes, in @modelcontextprotocol/client@2. I assumed it was a packaging mistake. It is not.

That constant means "the newest legacy-era version, used for the fallback handshake." It is not the newest revision overall. If you write protocolVersion: LATEST_PROTOCOL_VERSION expecting 2026-07-28, you have quietly pinned yourself to the old era.

The era model explains it. Once you stop reading revisions as one ordered list, the naming makes sense.

Gotcha 2: auto-fallback is not a free lunch

The v2 client advertises automatic fallback: point it at a 2025-era server and it detects, falls back to initialize, and connects. Mostly true, and it deletes a lot of detection code you would otherwise write.

Then I shipped it as the single client for everything and broke auth-gated servers.

The failure: v2's auto mode treats a failed server/discover probe as fatal. A 2025-era gateway that answers unknown methods with 401 becomes unreachable — even though the initialize that would have followed uses the same credentials and succeeds fine.

Second, related discovery: v2's legacy mode is not bug-for-bug identical to the v1 SDK against non-conforming servers. So "just pin to 2025-11-25 on the new client" is also not the old flow.

What actually works is keeping the generations apart behind one facade:

// dispatcher — one facade, two clients underneath
switch (preference) {
  case 'legacy':  return connectV1(url);            // exact pre-2026 flow, untouched
  case 'modern':  return connectV2(url, '2026-07-28'); // fail loudly, no fallback
  case 'auto':                                       // default
  default:
    try   { return await connectV2(url);  }          // try stateless first
    catch { return await connectV1(url);  }          // on ANY failure, fall back to v1
}

The rule I would tattoo on this migration: never route your existing working path through the new client. Add the new generation beside the old one, dispatch between them, and let auto fall back to the flow you already trust.

One more sharp edge inside that facade: callTool's second argument is a result schema in v1 and request options in v2. Same method name, different meaning. Forward options only on the modern path.

The new surface you actually want

Migration is not only removal. Three additions are worth adopting deliberately.

MRTR (Multi Round-Trip Requests). A server can return an InputRequiredResult mid-tool-call. The client gathers answers, echoes back the requestState, and re-issues the original request. This is how a tool asks a clarifying question without failing.

If your agent loop does not implement it, a fully compliant server just looks broken to you.

The design question MRTR forces: who answers the question? An auto-approve policy that fills in defaults defeats the point — the server asked because it needed a decision. In Agent Studio I wired the answers to come from the model itself: the tool schema carries _mcpInputResponses and _mcpRequestState, an input_required result goes back to the model as retry instructions, and the whole exchange stays visible in the transcript. If you are building an agent loop against a 2026 server, that is the shape I would copy.

Tasks. Now an extension (io.modelcontextprotocol/tasks), not core. Poll tasks/get, tasks/update, tasks/cancel. Note that tasks/list was removed and task creation is server-directed. Code written against the experimental core Tasks API from 2025-11-25 needs updating.

MCP Apps. Servers return HTML rendered in a sandboxed iframe; UI actions route back through JSON-RPC. The demo value here is high.

Also free with the upgrade: full JSON Schema 2020-12 in tool inputs (oneOf, anyOf, allOf, $ref) and standardized W3C Trace Context propagation. If you were flattening complex inputs to work around old schema limits, you can stop.

The security bug this revision created

Statelessness moved state onto the wire, and wire state is attacker-controlled.

Under MRTR, your server mints a requestState blob, hands it to the client, and receives it back on the retry. The client can modify it in between. The spec makes integrity protection a MUST, and the SDK explicitly does not do it for you.

If an unprotected blob influences authorization or business logic, that is direct exploitation — tamper with the blob, resume someone else's operation.

Sign it. Use the SDK's createRequestStateCodec rather than rolling your own MAC.

The other new-in-2026 checks worth running against yourself:

cacheScope: "public" on tenant-scoped data — leaks across users via any shared intermediary.
Missing iss validation in auth responses — RFC 9207 mix-up mitigation, now mandatory.
Missing application_type during client registration — OIDC redirect URI conflicts.
Credentials reused across issuers — must be keyed by issuer identity.

Scan your MCP server →

How to actually test the migrated server

You can get the first 20% with curl. Fire a tools/call with no handshake and see whether it works:

curl -sS https://your-server.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Mcp-Method: tools/list' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{
        "_meta":{
          "io.modelcontextprotocol/protocolVersion":"2026-07-28",
          "io.modelcontextprotocol/clientInfo":{"name":"curl","version":"1.0"}
        }}}' | jq

If that returns tools with ttlMs and cacheScope, you are on the new era. If it returns -32022, you are not.

Ironically, statelessness made this commodity check easier — curl and Postman can now do the raw protocol ping they never could before. Good. That was never the interesting part.

The interesting part is everything curl cannot answer:

Does my server behave the same on both revisions, for the clients that have not migrated?
Does a real model still pick the right tool now that my schemas use oneOf?
Does my client handle InputRequiredResult, -32022, and a tampered requestState correctly?
Is my requestState actually signed, or did I just assume the SDK did it?

How MCP Playground helps

That is the gap I built MCP Playground around, and the 2026 spec is fully wired into it. Paste a URL and there is a protocol switch on every test surface: Auto (detect and show the negotiated revision), Force 2025-11-25, or Force 2026-07-28 — so you can prove your server answers both eras instead of hoping. If you are building a client, the test client points at mock servers in either revision, including ones that return InputRequiredResult, -32022 UnsupportedProtocolVersion, and a deliberately tampered requestState, so you can exercise your retry loop against hostile-but-legal responses. No install, runs in the browser.

Test any MCP server free →

My migration order

If I did it again, in this order:

Centralize your protocol constants first. I found protocolVersion hardcoded in four files, pinned to a revision 20 months out of date. Fix that before anything else or you will chase the same strings again next revision.
Add v2 packages alongside v1. Do not remove anything yet.
Build the dispatcher (legacy / modern / auto) so nothing existing changes behavior.
Add server/discover, resultType, ttlMs / cacheScope to the server.
Fix error codes, add Mcp-Method / Mcp-Name handling.
Sign requestState before you ship MRTR — not after.
Swap deprecated features on the 12-month clock, separately.
Run both revisions against a real model and confirm every tool still resolves.

Step 8 is the one people skip. Regressions in an MCP migration are rarely loud — a tool quietly stops resolving, an auth flow fails silently, and you find out from a user.

Wrapping up

The 2026-07-28 spec deletes the handshake, makes server/discover mandatory, moves protocol metadata into _meta, changes error codes, and starts a 12-month clock on Roots, Sampling, and Logging. The migration is a checklist, not a rewrite.

Keep your old path intact, add the new one beside it, sign your requestState, and then prove both eras work before your users find the gap.

Test any MCP server free →

Further reading

MCP 2026-07-28 changelog — official
Migrate Your MCP Server to the 2026-07-28 Spec — canonical version of this post
Build an MCP Server on the 2026-07-28 Spec — starting fresh instead of migrating
MCP Goes Stateless — why the session model was removed
What Is the Model Context Protocol? — background

Migrating something now? Tell me what broke — I am collecting the failure modes that are not in the changelog.

GPT-5.6 MCP: Testing Servers With Sol, Terra & Luna

Rupa Tiwari — Tue, 14 Jul 2026 06:17:21 +0000

📖 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 — 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, 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 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.

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 — 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:

Connect the MCP server URL (plus token if needed)
Select a GPT-5.6 tier in the model dropdown
Chat and inspect each tool call live

Want the wider workflow? The step-by-step guide to testing MCP servers 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 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 40+ models side by side — see the best 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 maps the common ones fast.

And before you point any agent at a production server, scan it. Scan your MCP server 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 40+ 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 gives me a live server URL in one click — no infra to babysit.

Testing an MCP server with GPT-5.6? Connect your endpoint, switch between Sol, Terra, and Luna mid-chat, and see which tier holds the plan.

Test any MCP server free →

Chat with it in Agent Studio →

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.

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 and switch between Sol, Terra, and Luna mid-chat to see which one holds the plan.

Related Guides

MCP vs A2A: Model Context Protocol vs Agent2Agent

Rupa Tiwari — Tue, 30 Jun 2026 15:19:41 +0000

📖 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.

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? and how MCP tool calling works.

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

Dimension	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 and MCP vs function calling.

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 →

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

The planner agent uses A2A to delegate flights to a flight agent and hotels to a hotel agent.
The flight agent uses MCP to call an airline API and a payments tool.
The hotel agent uses MCP to query a booking database and a maps service.
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.

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

Why Testing MCP Servers With Real AI Models Matters (2026)

Rupa Tiwari — Sat, 13 Jun 2026 16:53:58 +0000

TL;DR

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.
Fastest way to do it: paste your server URL into MCP Playground, pick a model, and watch every tool call as structured JSON. No setup.

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.

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, then come back.

Why It 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.

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 the step-by-step guide to testing MCP servers and how QA teams should approach it.

How AI Model Performance Changes Your 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 goes deeper on the differences.

Checking How Different Models Work With Your 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, Gemini models, DeepSeek V4, and Grok.

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.

Wire check first — confirm the server lists tools and returns valid results with curl or your client. Fix transport bugs before involving a model.
One strong model — connect a frontier model and run real prompts. Confirm it finds and calls each tool.
One weak model — repeat on a smaller or open-weight model. This is where unclear descriptions break.
Watch the arguments — don't just check the final answer. Read the actual JSON arguments the model built for each call.
Test the chains — give a prompt that needs two or three tools in sequence and confirm the model wires outputs into inputs.
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, scan your MCP server for exposure and prompt injection.

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

Test any MCP server free →

FAQ

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.

Originally published on MCP Playground — a free browser-based tool for testing MCP servers against real AI models.

Connect Your MCP Server With DeepSeek V4 — Step-by-Step Guide (2026)

Rupa Tiwari — Mon, 18 May 2026 10:22:52 +0000

TL;DR

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.
Fastest way to test on your MCP server: paste the URL into MCP Agent Studio, pick V4-Pro or V4-Flash, start chatting. No DeepSeek API key required.

You can connect any MCP server to DeepSeek V4 in about 60 seconds — paste the server URL into 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 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:

Open mcpplaygroundonline.com/mcp-agent-studio and sign in (free credits are added to your account).
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.
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.
In the Model dropdown, pick DeepSeek V4-Pro (for hard reasoning) or DeepSeek V4-Flash (for speed + cost).
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 mcpplaygroundonline.com/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.

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.

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

40+ 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.
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.

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 — 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.

FAQ

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

Originally published on mcpplaygroundonline.com/blog/testing-mcp-with-deepseek.

How to Test Your MCP Server with Z.AI GLM Models (2026 Guide)

Rupa Tiwari — Wed, 06 May 2026 19:39:45 +0000

TL;DR

How to test:

Open MCP Agent Studio

Paste your MCP server URL

Pick a GLM model from the picker

Start chatting — Agent Studio handles the MCP → OpenAI-function-calling translation automatically

No API keys, no setup, no code

Which GLM to pick:

🟢 GLM 4.5 Air — daily driver. Fast, low cost, 76.4 on BFCL-v3

🔵 GLM 5 Turbo — mid-tier agentic execution at lower cost than the flagship

🟣 GLM 5.1 — long-horizon multi-step agents. 200K context, autonomous up to 8 hours, 58.4 on SWE-Bench Pro (beats GPT-5.4, >Claude Opus 4.6, Gemini 3.1 Pro)

Z.AI's GLM family has quietly become one of the strongest options for MCP tool calling in 2026. The flagship GLM 5.1, released open-source on April 8, 2026, is purpose-built for long-horizon agentic work — capable of running autonomously for up to 8 hours across hundreds of tool calls. It scores 58.4 on SWE-Bench Pro, ahead of GPT-5.4, Claude Opus 4.6, and Gemini 3.1 Pro. The smaller GLM 4.5 Air (106B total / 12B active MoE) hits 76.4 on BFCL-v3 and 69.4 on τ-bench at a fraction of the cost.

The fastest way to test any GLM model against your MCP server — without a Z.AI account, OpenRouter key, or any code — is MCP Agent Studio. You paste your server URL, pick a GLM model, and the agent starts calling your tools in real time.

The fastest way to test any GLM model against your MCP server — without a Z.AI account or api key, or any code — is MCP Agent Studio. You paste your server URL, pick a GLM model, and the agent starts calling your tools in real time.

What you'll get from this guide

Understand the GLM 5.1 / GLM 5 Turbo / GLM 4.5 Air lineup and which one to pick for MCP tool calling
Connect any MCP server (HTTP, SSE, Streamable HTTP) to GLM in seconds — no Z.AI account required
Run your first agentic conversation with GLM and inspect every tool call live
Know exactly when GLM beats Claude or GPT on your server — and when it doesn't

1. The GLM family in Agent Studio — which one to use

Z.AI (formerly Zhipu AI) shipped GLM-4.5 in July 2025, GLM-4.6 in late September 2025, GLM-5 on February 11, 2026, and GLM-5.1 to subscription users in late March 2026 (open-sourced April 8, 2026). Each generation tightened agentic behaviour, expanded context, and pushed harder on long-horizon tool use rather than chasing chatbot benchmarks.

MCP Agent Studio exposes three GLM models covering the full quality-to-cost range:

Model	Architecture	Context	Best for MCP
GLM 5.1	Flagship long-horizon agent	200K input / 128K output	Best for complex MCP work — long chains of tool calls, autonomous bug-fix-style loops, hundreds of iterations
GLM 5 Turbo	Fast inference, agent-tuned	200K input / 131K output	Mid-tier daily driver — strong tool-call accuracy at lower latency than GLM 5.1
GLM 4.5 Air	MoE (106B total / 12B active)	128K	Best daily driver — 76.4 on BFCL-v3, 69.4 on τ-bench,

💡 Recommended starting point: GLM 4.5 Air is the right first stop for most MCP testing sessions. It hits 76.4 on BFCL-v3 — within striking distance of frontier closed models — and runs cheap. Switch to GLM 5.1 when you need long-horizon planning across 50+ tool calls, or when your MCP workflow has the kind of "agent debugs itself" loop GLM 5.1 was specifically trained on.

A practical reality check: most MCP testing prompts don't need the full GLM 5.1. If your conversation involves 1–5 tool calls with simple arguments, GLM 4.5 Air is faster, cheaper, and accurate enough. The accuracy gap shows up when you ask the model to plan, execute, observe, and revise across many turns.

2. How GLM handles MCP tool calling

GLM models expose an OpenAI-compatible function calling API at https://api.z.ai/api/paas/v4/. The same tools array and tool_calls response format you'd send to GPT-5.4 or Qwen also works against GLM. That means any MCP client that already speaks OpenAI function calling can route GLM at MCP servers with zero changes.

A few GLM-specific behaviours worth knowing when testing your server:

Tuned specifically for agentic loops. GLM 5.1's training puts heavy weight on planning, executing, observing tool output, and revising. On long-horizon MCP tasks it tends to recover from a bad first tool call faster than smaller open-weight models.
Native MCP integration mentioned in Z.AI docs. Z.AI's official docs reference MCP support directly — GLM is one of the few non-Anthropic providers explicitly designed with the protocol in mind.
Anthropic-compatible endpoint also available. Z.AI exposes a Claude-shaped API at https://api.z.ai/api/anthropic — useful if you've already built around Claude's MCP-native client and want to swap GLM in. Agent Studio uses the OpenAI-compatible route under the hood.
Parallel tool calls supported. All three GLM variants in Agent Studio can issue multiple tool calls in a single turn — important for MCP servers where read operations are independent.
Strong long-context behaviour. GLM 5.1 and GLM 5 Turbo carry ~200K input windows (202,752 tokens), GLM 4.5 Air carries 128K. Even a server with 50+ tool definitions plus a long conversation history fits comfortably.

3. Connect your MCP server to GLM in 3 steps

No Z.AI account, no api 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 and sign in. New accounts get starter credits — enough to test all three GLM models against your server immediately.

2. Paste your MCP server URL
Click + Add Server and paste the endpoint. Agent Studio supports HTTP, SSE, and Streamable HTTP. If the server needs an auth token, drop it in the auth field. You can wire up to 4 servers in one conversation.

3. Pick a GLM model and start chatting
Open the model picker, search for "GLM". Pick GLM 4.5 Air to start. 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.

No MCP server yet? Grab a hosted mock server (Echo, Auth, Error, or Complex) from MCP Test Client and paste the URL into Agent Studio. Each one stresses a different part of your tool-calling flow.

4. Prompts that exercise long-horizon GLM behaviour

GLM 5.1 was trained specifically for tasks where the model has to plan, act, observe, and revise — not just one-shot tool calls. The shape of your prompt decides how much of that behaviour you actually see.

🔍 Discovery prompt — forces GLM 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 GLM 5.1 actually 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 GLM batches independent reads in one turn:

Compare [item A] and [item B] side by side — fetch
both at the same time.

🛑 Recovery prompt — tests how GLM handles a failing tool, the area where 5.1 was tuned:

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.

For multi-server setups, GLM handles cross-server coordination cleanly. A prompt like "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 — exactly the workload where GLM 5.1's long-horizon training pays off.

5. Reading the tool-call inspector with GLM

Every time GLM 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. You'll see:

Inspector field	What it shows	What to check with GLM
Tool name	Which MCP tool GLM picked	Right tool for the request? GLM 5.1 sometimes picks a richer tool than the obvious one
Input JSON	Arguments GLM sent	Types correct? GLM tends to populate optional fields proactively — verify they match your schema
Output JSON	What your server returned	Empty arrays or errors trigger GLM 5.1's revision 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 GLM picked the right namespace

GLM-specific pattern to watch: If a tool returns an error or empty payload, GLM 5.1 often calls a different tool with adjusted arguments before replying — this is the "revise" half of its plan-execute-observe-revise loop. The inspector lets you follow the full chain.

6. GLM vs Claude vs GPT 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	GLM 5.1	GPT-5.4	Claude Sonnet 4.6
Argument accuracy on first call	High	High	High
Long-horizon agent loops	Best in class — designed for this	Very good	Very good
Recovers from failed tool calls	Strong — revises and retries	Strong	Strong
Parallel tool calls	Yes	Yes	Yes
Context window	200K input / 128K output	1M	200K (1M tier available)
SWE-Bench Pro score	58.4 (leader)	Lower	Lower
Native MCP support	Listed in Z.AI docs	Via Agents SDK	Native (`mcp_servers` param)
Pricing per 1M tokens (in / out)	$1.05 / $3.50	$2.50 / $15	$3.00 / $15
Open-weight / self-hostable	Yes (MIT licence)	No	No

Bottom line: GLM 5.1 is the strongest open-weight model for MCP tool calling in 2026 and the only model in this tier with explicit long-horizon agent training. Output tokens — the dominant cost in agentic workloads — are roughly a quarter the price of GPT-5.4 or Claude Sonnet 4.6, and it tops both on SWE-Bench Pro at 58.4. Runs under an MIT licence, so you can self-host the same weights in production.

Try it yourself

Open MCP Agent Studio →

No Z.AI account. No API keys. GLM 5.1, GLM 5 Turbo, and GLM 4.5 Air all ready in seconds — alongside Claude, GPT-5.4, and Gemini for side-by-side comparison.

FAQ

Does GLM support MCP natively?
GLM doesn't speak the raw MCP wire protocol the way Claude does — it uses OpenAI-compatible function calling. Z.AI's docs do reference MCP integration directly, and the model's training makes it well-suited to tool-driven agentic loops. MCP Agent Studio handles the protocol translation: it discovers your server's tools via MCP, converts them to the function-calling format GLM expects, runs the agentic loop, and shows results — no code on your end.

Which GLM model should I start with for MCP testing?
Start with GLM 4.5 Air. It hits 76.4 on BFCL-v3 and 69.4 on τ-bench — close enough to the flagship for most testing — at the lowest cost tier in Agent Studio. Move to GLM 5.1 when you're stress-testing long-horizon multi-step workflows or comparing against Claude Opus on complex agentic tasks. Use GLM 5 Turbo when you want stronger agent behaviour than 4.5 Air without paying flagship rates.

What makes GLM 5.1 different from GPT-5.4 or Claude Opus on MCP work?
Two things. First, training focus — GLM 5.1 was tuned specifically for long-horizon agentic loops, which is exactly the workload most MCP servers create. It can run autonomously for up to 8 hours across hundreds of tool calls. Second, cost — at $1.05/$3.50 per million input/output tokens, output (the dominant cost in agentic workloads) is roughly a quarter the price of GPT-5.4 or Claude Sonnet 4.6, while topping both on SWE-Bench Pro at 58.4.

Can I self-host GLM and point it at my MCP server?
Yes. GLM 4.5, GLM 4.5 Air, and GLM 5.1 are all open-source under MIT licence on Hugging Face. You can run them locally with vLLM (use --tool-call-parser glm45) or SGLang — both expose an OpenAI-compatible API. Any MCP client wired to OpenAI function calling will work against your self-hosted endpoint. Use Agent Studio first to validate prompt and tool behaviour, then swap in your local endpoint for production.

Do I need a Z.AI API key to use GLM 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 GLM against your MCP server immediately — no Z.AI account, no api key, no billing setup.

How many MCP tools can GLM handle per request?
GLM inherits the OpenAI-compatible 128-function-per-request limit. In practice, tool-selection accuracy starts to slip beyond 30–40 definitions in a single call — same range as GPT, Gemini, and Qwen. For MCP servers exposing many tools, Agent Studio's Tokens tab shows the exact token cost of your tool schemas so you can decide what to keep in scope.

Originally published on MCP Playground.

How to Test Your MCP Server with Alibaba Qwen Models (April 2026 Guide)

Rupa Tiwari — Mon, 20 Apr 2026 08:15:06 +0000

TL;DR — To test your MCP server with Alibaba Qwen: open MCP Agent Studio, paste your server URL, pick a Qwen model from the picker, and start chatting. Agent Studio handles the MCP-to-function-calling translation automatically — no API keys, no setup.

Which Qwen to pick? Start with Qwen3 30B for a fast, accurate daily driver. Upgrade to Qwen3 235B-A22B for complex multi-step agentic workflows. Try Qwen 3.6 Plus if you want the newest Alibaba flagship. Drop to Qwen3.5 Flash for high-volume runs where latency matters most.

What you'll get from this guide:

Understand the Qwen 3 / 3.5 / 3.6 family available in Agent Studio and which variant to pick for MCP tool calling
Connect any MCP server (HTTP, SSE, Streamable HTTP) to Qwen in seconds
Run your first agentic conversation and inspect every tool call live
Know exactly when Qwen outperforms GPT or Claude on your server — and when it doesn't

Alibaba's Qwen lineup has become one of the most capable open-weight model families for tool calling. The flagship Qwen3 235B-A22B (a 235B mixture-of-experts with 22B active parameters) rivals frontier closed models on function-calling benchmarks, while smaller variants like Qwen3 30B-A3B and Qwen3.5 Flash give you strong tool-use at a fraction of the compute cost.

The fastest way to test any of these against your own MCP server — without writing a single line of code or managing API keys — is MCP Agent Studio. You paste your server URL, pick a Qwen model, and the agent starts calling your tools in real time.

In this guide

The Qwen family in Agent Studio — which one to use
How Qwen handles MCP tool calling
Connect your MCP server in 3 steps
Prompts that exercise your tools well
Reading the tool-call inspector
Qwen vs GPT vs Claude on tool calling
FAQ

1. The Qwen family in Agent Studio — which one to use

Qwen has gone through three generations in a little over a year — Qwen3 (2025), Qwen3.5 (early 2026), and Qwen 3.6 Plus (April 2026). Each generation improved tool-calling accuracy, extended context, and refined the thinking / non-thinking toggle (budget tokens for private reasoning before the model produces a response or a tool call).

MCP Agent Studio exposes five Qwen variants covering the full quality-vs-speed spectrum:

Model	Architecture	Context	Best for MCP
Qwen 3.6 Plus	Flagship (April 2026)	Up to 128k	Newest Alibaba flagship — strongest overall accuracy on complex MCP tasks
Qwen3.5 397B	MoE (large)	Up to 128k	Heavy multi-step reasoning; Qwen3.5 generation flagship
Qwen3 235B-A22B	MoE (235B total, 22B active)	256k (262,144)	Proven frontier for open-weight tool use; great quality/value ratio
Qwen3 30B-A3B	MoE (30B total, 3B active)	Up to 128k	Best daily driver — fast, accurate, low compute footprint
Qwen3.5 Flash	Speed tier	Up to 128k	High-volume runs, lowest latency, router agents, quick schema checks

Start here: Begin with Qwen3 30B-A3B in Agent Studio. The mixture-of-experts design means only 3B parameters are active at inference time, so it's fast and cheap — but its tool-calling accuracy is very close to the 235B flagship for most MCP workloads. Upgrade to Qwen3 235B-A22B or Qwen 3.6 Plus if you hit accuracy limits on complex multi-tool chains.

2. How Qwen handles MCP tool calling

Qwen 3 models use the OpenAI-compatible function calling format — the same tools array and tool_calls response structure. This means any MCP client that supports OpenAI function calling can route Qwen against MCP servers with zero modification.

A few Qwen-specific behaviours to know when testing your server:

Thinking mode by default — Qwen3 / 3.5 / 3.6 all support a private-reasoning pass before producing a tool call. On ambiguous queries this tends to produce more accurate tool selection at the cost of a slightly longer first token. If latency is critical, switch to Qwen3.5 Flash.
Parallel tool calls supported — all Qwen variants from Qwen3 30B-A3B upward can issue multiple tool calls in a single turn, which matters for MCP servers with independent read operations.
Large context window — the 235B models carry 256k context (262,144 tokens); the 30B sits at 128k. Either way, even a server with 50+ tools (each ~150 tokens of schema) leaves ample room for a long conversation history and tool results.
Strict JSON output — Qwen produces well-formed tool-call JSON reliably, with a low rate of hallucinated or missing required arguments. In practice this is one of the main reasons teams pick Qwen over smaller open models.

3. Connect your MCP server in 3 steps

Step 1 — Sign in to MCP Agent Studio

Go to mcpplaygroundonline.com/mcp-agent-studio and sign in. No API keys, no setup — you get access to all 30+ models including the full Qwen family (Qwen 3.6 Plus, Qwen3.5 397B, Qwen3 235B, Qwen3 30B, Qwen3.5 Flash) immediately.

Step 2 — Paste your MCP server URL

Enter your server endpoint in the URL bar at the bottom of the chat. If your server requires an auth token, add it in the auth field next to the URL. Agent Studio supports HTTP, SSE, and Streamable HTTP transports.

Step 3 — Select a Qwen model and start chatting

Open the model picker and search for "Qwen". Select Qwen3 30B to start. Type a natural-language question that would require one of your server's tools to answer. The agent will discover your tools, decide which to call, and show you every step live.

No MCP server yet? Use the built-in test server — https://mcpplaygroundonline.com/mcp-test-client

4. Prompts that exercise your tools well

The quality of Qwen's tool calling shows most clearly when the prompt requires the model to decide between tools, sequence multiple calls, or handle a partial result and continue. Try these patterns:

Discovery prompt

Forces the model to list and summarise what's available.

"What tools do you have access to on this server? Give me a one-line summary of what each one does."

Multi-step prompt

Requires two or more sequential tool calls.

"Get the list of [items], then for each one fetch the details and give me a summary table."

Parallel tool prompt

Tests whether Qwen issues multiple calls in a single turn.

"Compare [item A] and [item B] side by side — fetch both at the same time."

Edge-case prompt

Tests what happens when a tool returns an error or empty result.

"Look up [a resource that doesn't exist] and tell me what you find."

5. Reading the tool-call inspector

Every time Qwen calls a tool on your server, Agent Studio logs it in the Inspector panel on the right. Click any tool card in the chat to expand it. You'll see:

Tool name — which of your server's tools Qwen chose to call
Arguments — the exact JSON Qwen sent (great for catching schema mismatches)
Result — what your server returned, exactly as Qwen received it
Latency — time from tool invocation to result receipt (helps separate slow server from slow model)

Common Qwen-specific thing to watch: With thinking mode enabled, you may notice Qwen calls a tool, receives the result, then calls a second tool before replying — this is intentional. Qwen reasons step-by-step internally and the inspector lets you follow exactly that chain. If you see an unexpected second call, check the arguments — it's usually Qwen correcting a first attempt based on an intermediate result.

6. Qwen vs GPT vs Claude on tool calling

Rather than abstract benchmarks, here's a practical comparison of what you'll notice on a real MCP server in Agent Studio:

Behaviour	Qwen3 30B-A3B	GPT-5.4	Claude Sonnet 4.6
Argument accuracy on first call	High (thinking mode helps)	High	High
Parallel tool calls	Yes	Yes	Yes
Handling empty / error results	Good — retries or explains	Very good	Very good
Context window (tools + history)	128k (30B) / 256k (235B+)	1M	200k
Native MCP support	Via OpenAI-compatible API	Via Agents SDK	Native (mcp_servers param)
First-token latency	Moderate (thinking overhead)	Fast	Fast
Open-weight / self-hostable	Yes	No	No

Bottom line: Qwen3 30B-A3B sits in the same tier as GPT-5.4 mini and Claude Haiku 4.5 on most MCP tool-calling tasks — at a fraction of the closed-model cost, with the option to self-host. For teams exploring open-weight models or building on-prem pipelines, it's the obvious first stop. The broader Qwen lineup (Qwen 3.6 Plus, Qwen3.5 397B, Qwen3 235B-A22B) competes directly with frontier closed models on complex multi-tool workflows.

Test Qwen on your MCP server — right now, in your browser →

No API keys. No setup. Qwen 3.6 Plus, Qwen3.5 397B, Qwen3 235B, Qwen3 30B, Qwen3.5 Flash — all ready in seconds.

FAQ

Does Qwen3 support MCP natively?

Not natively in the same way Claude does — Qwen3 uses the OpenAI-compatible function calling format (tools / tool_calls). MCP Agent Studio handles the translation: it discovers your server's tools via MCP, converts them into the function-calling format Qwen expects, runs the agentic loop, and shows you the results. From your perspective it's seamless — paste the URL, chat.

Which Qwen variant should I start with?

Start with Qwen3 30B-A3B in Agent Studio. It's the best all-around option — strong tool-calling accuracy, up to 128k context, thinking mode for tricky multi-step queries, and very fast because only 3B parameters are active per token. Upgrade to Qwen3 235B-A22B or Qwen 3.6 Plus when you need the highest accuracy on complex agentic tasks, or switch to Qwen3.5 Flash for the lowest latency at volume.

How many tools can Qwen handle per request?

Qwen3 inherits the OpenAI-compatible 128-function limit. In practice, accuracy starts to drop when you send more than 20–30 tool definitions at once — the same recommendation as Gemini. If your MCP server exposes many tools, Agent Studio's Tokens tab will show you exactly how many tokens your tool schemas consume.

Can I self-host Qwen and point it at my MCP server?

Yes — most Qwen3 and Qwen3.5 weights are publicly released. You can run them locally via Ollama, vLLM, or llama.cpp, all of which expose an OpenAI-compatible API. Any MCP client that supports OpenAI function calling will work against your self-hosted Qwen endpoint. Use Agent Studio first to validate prompt and tool behaviour, then point your production stack at your own inference endpoint.

What's the difference between Qwen3 and Qwen 2.5?

Qwen3 adds a thinking/non-thinking toggle (budget token reasoning), better function-calling accuracy across all model sizes, longer context (128k vs 32k on most Qwen 2.5 variants), and a new 235B MoE flagship. For MCP testing the biggest practical difference is that Qwen3's thinking mode catches more edge cases in multi-step tool workflows — things that Qwen 2.5 would sometimes get wrong on the first attempt.

What Is an MCP Agent? How AI Models Drive MCP Tools in Real Time

Rupa Tiwari — Fri, 17 Apr 2026 05:07:27 +0000

TL;DR

An MCP agent is an AI model that calls your MCP server's tools in a loop to answer a question or complete a task

Instead of you picking which tool to call, the AI decides based on a natural language prompt

Each "step" = model picks a tool → executes it → reads the result → decides what to do next

A single user message can trigger 5–10+ tool calls behind the scenes

You can try it in the browser at MCP Agent Studio — paste any server URL and start chatting

If you've read anything about the Model Context Protocol, you already know the basics: MCP servers expose tools, resources, and prompts in a standard format so AI clients can use them. But there's a piece people gloss over: what actually happens when an AI uses those tools?

That's where the idea of an MCP agent comes in. Understanding what an agent does — and how it differs from a one-shot API call — is the key to building, testing, and getting real value out of MCP servers.

What is an MCP agent?

An MCP agent is an AI model that's been given access to one or more MCP servers' tools, and decides on its own which tools to call, in what order, and with what arguments — to fulfill a natural language request from a user.

In plain English:

A user says something → the AI figures out which MCP tools to call → the tools run → the AI reads the results → the AI either calls more tools or writes a final answer.

That whole cycle — the deciding, the calling, the reading, the deciding-again — is what we call an agent loop. The "agent" is the thing doing the loop. Without a loop, you don't have an agent; you just have a function call.

Agent vs a single tool call — what's the difference?

This is the part people miss. Most MCP tutorials and test tools show you how to invoke one tool with one set of arguments. That's useful for debugging — but it doesn't reflect how AI actually uses MCP in production.

Aspect	Single tool call	MCP Agent
Who picks the tool?	You (the developer)	The AI model
Input format	JSON arguments you supply	Natural language prompt
Number of calls	Exactly 1	0 to many (loops until done)
Reasoning between calls	None — raw JSON back	AI reads each result and decides next
Output	Raw tool result	Natural language answer + full trace
Best for	Verifying a specific tool works	Testing real-world agent behavior

When someone uses Claude Desktop or Cursor with your MCP server, they're running an agent — not a single tool call. So if you want to know how your server really behaves, you need to test it as an agent.

How the tool-call loop works (step by step)

Here's what happens behind the scenes when you send one message to an MCP agent:

Step 1 — The agent connects to your MCP server
It calls tools/list to get the full set of available tools, with their names, descriptions, and JSON schemas.

Step 2 — Your message + the tool catalogue go to the AI model
The AI sees something like: "Here's a user question. Here are 12 tools you can use. What do you want to do?"

Step 3 — The AI responds with a tool call (or a direct answer)
If it needs more info, it picks a tool and constructs the JSON arguments. If it already has enough, it skips to step 6.

Step 4 — The runtime executes the tool on your MCP server
The agent sends tools/call with the AI's arguments. Your server does its thing and returns a JSON result.

Step 5 — The result goes back to the AI — and we loop
The AI reads the result and decides: "Do I have enough now, or do I need another tool?" If more is needed, back to step 3.

✓ Step 6 — The AI writes a final answer in natural language
It synthesises everything it learned into a response for the user. Loop complete.

⚙️ Under the hood: Most agent runtimes cap the loop at 5 to 15 steps to prevent runaway behaviour. MCP Agent Studio uses a 10-step cap, which handles almost every realistic task while keeping costs predictable.

A real walkthrough

Imagine you have a Supabase MCP server connected, and the user asks:

"Which 3 customers spent the most last month?"

Here's what an MCP agent does, step by step:

Step 1: AI calls list_tables
        → learns there's a "customers" and "orders" table

Step 2: AI calls describe_table(name: "orders")
        → sees columns: customer_id, amount, created_at

Step 3: AI calls query_database with a SQL JOIN query
        → orders filtered to last month, grouped by customer, top 3

Step 4: AI reads 3 rows back
        → writes: "Your top 3 customers last month were
           Acme ($12,400), Beta ($9,100), and Delta ($7,800)."

Three tool calls. One natural language answer. The user never wrote any SQL. They never picked a tool. They never looked at the schema. The agent figured it all out.

This is why MCP matters — not because it's a new protocol, but because it makes this kind of agentic behaviour portable across every AI client that speaks it.

Why this matters if you're building or using MCP

🛠️ If you build MCP servers
Your tool descriptions and schemas decide whether the AI picks the right tool. Agent testing reveals bad descriptions instantly. Manual tool calls hide the problem.

🤖 If you use MCP servers
Different models make very different choices in the loop. Agent testing is how you find the cheapest model that still works for your workload.

💰 If you care about cost
Each step in the loop = another model call. An agent that takes 8 steps costs roughly 8× a one-shot call. Watching the loop helps you design for fewer steps.

🔒 If you care about security
Agents can be tricked into calling tools they shouldn't via prompt injection. Watching the loop is how you catch it before your users do.

Try an MCP agent yourself — no code required

The fastest way to actually understand MCP agents is to watch one run on a server you already know.

MCP Agent Studio is a browser tool that runs the whole agent loop for you — no SDK, no API keys, nothing to install. You paste an MCP server URL, pick a model (Claude Opus 4.6, GPT-5.4, Gemini 3.1 Pro, DeepSeek, Grok 4.20, and 30+ more), and start chatting.

The key things you'll see that static MCP testers can't show you:

Every tool call as a card — click each one to see exactly what the AI sent and what it got back
The full loop in order — with timing for each step
Different models making different decisions — switch from Claude to Gemini and watch how they approach the same problem differently

💡 No server of your own? Grab one from the MCP Servers List and paste it straight into Agent Studio. Free credits on sign-up are enough for several test runs.

FAQ

Is "MCP agent" an official term?

Not quite — the MCP spec defines hosts, clients, and servers, not "agents". "MCP agent" is the practical term people use for a host + client that runs an AI model in a tool-call loop against MCP servers. Think of it as the behaviour pattern, not a formal role in the protocol.

Does every AI model support MCP agents?

Any model with a tool-use API can power an MCP agent — which today means basically every major frontier model: Claude, GPT-5, Gemini, DeepSeek, Grok, Qwen, Mistral, and more. The agent runtime bridges between MCP's tools/list + tools/call and each model's function-calling format.

How many steps can an agent take?

The protocol doesn't set a hard limit — it's up to the runtime. Production agents often cap at 10–20 steps to prevent infinite loops. MCP Agent Studio uses a 10-step cap which handles almost every real-world task.

Can a single agent use multiple MCP servers at once?

Yes — this is one of MCP's superpowers. A host (like Claude Desktop) can connect to several servers and merge all their tools into one catalogue the model sees. The model can then chain tools across servers in a single response (e.g. query Supabase, then post a Slack message).

How is an MCP agent different from a LangChain / CrewAI agent?

LangChain and CrewAI are agent frameworks — they give you opinionated Python/JS abstractions for building agents with custom tools. MCP is a protocol for exposing tools in a standard way. You can use LangChain or CrewAI as the runtime and use MCP servers as the tools — they're complementary, not competitors.

10 Things You Can Do With Vercel MCP Server

Rupa Tiwari — Sun, 29 Mar 2026 18:47:33 +0000

Vercel MCP is Vercel's official Model Context Protocol server — a hosted endpoint at https://mcp.vercel.com that uses OAuth so AI clients like Cursor, Claude, and VS Code Copilot can work with your Vercel account directly.

This is not the same as deploying your own MCP server to Vercel — this is Vercel's own server for managing your account. Everything below is taken directly from the official Vercel MCP tools reference.

💡 Before you start: If you want to explore any MCP server's tools interactively before configuring your IDE, you can use the free browser-based tester at MCP Playground — paste the URL, connect, and browse tools without touching a config file.

Quick setup

Install helper (any client):

npx add-mcp https://mcp.vercel.com

Cursor — .cursor/mcp.json:

{
  "mcpServers": {
    "vercel": {
      "url": "https://mcp.vercel.com"
    }
  }
}

Open Cursor → connect the server → complete OAuth when prompted. Other supported clients: Claude Code, ChatGPT (connector), VS Code Copilot, Codex CLI — full list here.

1. Search Vercel docs from inside your editor

Tool: search_documentation

Instead of alt-tabbing to a browser, ask your assistant to search Vercel's docs directly. You pass a topic — edge functions, env vars, routing — and it returns grounded, current answers from Vercel's actual documentation with an optional text limit.

No more "I think Next.js does it this way" guesses from stale training data.

2. List your teams and projects

Tools: list_teams, list_projects

Most other tools need a team and project identifier. These two let the assistant resolve the correct target automatically before calling anything downstream — especially useful when you have personal and org projects mixed together.

3. Get detailed project info

Tool: get_project

Returns a structured snapshot for one project: detected framework (Next.js, Astro, etc.), attached domains, latest deployment summary, and other metadata the Vercel API exposes. Gives the model factual grounding for questions like "what framework is this app using?" or "what's live right now?"

4. Browse deployment history + inspect a specific deploy

Tools: list_deployments, get_deployment

list_deployments is your history view — states, targets, timing. get_deployment is the drill-down: build status, regions, and metadata for one deploy by ID or URL.

Typical flow: list to find the failing preview → get detail on that single deployment → pull logs.

5. Debug failed builds

Tool: get_deployment_build_logs

Retrieves build-phase logs (not runtime logs) for a deployment, with a configurable line limit. When your preview is red, the assistant can fetch the logs for that deployment ID and help you identify dependency errors, wrong build commands, or missing build-time env vars — without you navigating to the Vercel dashboard log viewer.

6. Filter and search runtime logs

Tool: get_runtime_logs

This is the strongest operational tool in the set. It surfaces runtime output from Vercel Functions — console.log, errors, request traces.

Documented filters:

Environment (production or preview)
Log level
HTTP status
Source type (serverless vs edge)
Time range
Full-text query
Request ID

That combination is ideal for AI-assisted debugging when users are hitting 500s or you need to trace one specific bad request.

7. Check domain availability and buy domains

Tools: check_domain_availability_and_price, buy_domain

Check one or more domain names, then walk through buy_domain with registrant fields when you're ready. These are real commerce actions — treat them like any sensitive dashboard operation and verify before approving tool runs.

8. Work with protected deployments

Tools: get_access_to_vercel_url, web_fetch_vercel_url

Preview deployments are often protected. Two different tools for two different needs:

get_access_to_vercel_url — creates a temporary shareable link so someone can open a protected preview URL without disabling protection globally.
web_fetch_vercel_url — fetches the actual response body from a deployment URL, including when Vercel Authentication is required. Good for verifying a page or API route returns the right output.

9. Deploy and use the Vercel CLI from your assistant

Tools: deploy_to_vercel, use_vercel_cli

deploy_to_vercel — deploys the current project through the MCP tool surface.
use_vercel_cli — steers the model toward CLI-first patterns, including --help for specific commands when you prefer that workflow.

10. Use a project-scoped MCP URL

From the Vercel docs:

https://mcp.vercel.com/{team-slug}/{project-slug}

By pointing at a project-specific endpoint, the server already knows your team and project context. Fewer manual slug parameters, better errors when context is missing, and a cleaner workflow when one repo maps to one Vercel project.

See Advanced usage in the Vercel docs.

Real-world scenarios

Scenario	Tools involved
Red preview build	`list_deployments` → `get_deployment_build_logs`
500s in prod	`get_runtime_logs` (filter by status + time)
"What's live?"	`list_projects` → `get_project`
Ship from the IDE	`deploy_to_vercel`
Review a protected preview	`get_access_to_vercel_url` or `web_fetch_vercel_url`
Buy a domain	`check_domain_availability_and_price` → `buy_domain`

A note on security

Vercel explicitly recommends:

Human confirmation before tool runs (don't let the model act autonomously on deployments)
Reading their prompt injection and confused-deputy guidance when multiple MCP servers are connected

Worth 5 minutes of reading before you wire this up to an autonomous agent.

FAQ

Is Vercel MCP free?
The MCP server itself is free to use if you have a Vercel account. The actions it performs (deploys, domain purchases) use your account's normal plan limits and billing.

Does this work with Claude Desktop?
Vercel's supported client list includes Claude Code (CLI). Check Supported clients for the current list.

Is this the same as deploying my own MCP server to Vercel?
No. This article is about using Vercel's hosted MCP to manage your account. If you want to host your own MCP server on Vercel infrastructure, that's a separate guide — Vercel documents that separately.

References

Want to try MCP servers interactively before configuring your IDE? MCP Playground lets you connect to any remote MCP server from the browser, browse its tools, and run them with live JSON-RPC logs — free, no sign-up required.

DEV Community: Rupa Tiwari

Agent Skills vs MCP vs Function Calling vs A2A: When to Use Each

Four Layers, Not Four Choices

What Are Agent Skills?

Progressive disclosure is the whole trick

What Is MCP?

The context cost nobody warns you about

What Is Function Calling?

What Is A2A?

Agent Skills vs MCP: The Real Difference

Four differences that show up in production

Side-by-Side Comparison

When to Use Each

Build an Agent Skill when…

Build an MCP server when…

Use plain function calling when…

Reach for A2A when…

Skills over MCP: The Two Standards Are Converging

One Real Stack, All Four

Five Expensive Mistakes

How to Test the MCP Layer

The Decision, In One Paragraph

Frequently Asked Questions

Related Guides

Further Reading

What Is an MCP Eval? Why Your Server Passes Every Test and Still Fails

What an MCP Eval Actually Is

MCP Eval vs Testing vs Inspecting

The Failure That Has No Red Log Line

The Four Outcomes and What Each One Means

Pass

Wrong Answer

Too Many Calls

Untestable

Why "Untestable" Deserves Its Own Outcome

Evals Are Not Deterministic — and That Is Fine

When You Need Evals, and When You Do Not

How to Run Your First One

Frequently Asked Questions

The Short Version

Related Guides

Further Reading

Meta's Muse Models and MCP: What the Benchmarks Actually Say

MCP-Atlas is a real benchmark, and Muse tops it

What Meta reports for Glimmer

The number nobody puts in a headline

Glimmer's architecture

The one claim worth testing yourself

Muse Spark 1.2, briefly

What nobody has published

Which one

MCP Went Stateless: Migrating to the 2026-07-28 Spec (and Proving It Works)

Stop thinking "version bump." Start thinking "era."

The wire diff: what a request actually looks like now

Before (2025-11-25, stateful)

After (2026-07-28, stateless)

Install: two packages, not one upgrade

The server checklist: seven concrete changes

Error codes: grep for these today

Deprecations: the 12-month clock started

Two gotchas that cost me a day

Gotcha 1: LATEST_PROTOCOL_VERSION is 2025-11-25

Gotcha 2: auto-fallback is not a free lunch

The new surface you actually want

The security bug this revision created

How to actually test the migrated server

How MCP Playground helps

My migration order

Wrapping up

GPT-5.6 MCP: Testing Servers With Sol, Terra & Luna

What Is GPT-5.6? Sol, Terra, and Luna Explained

Why GPT-5.6 Changes MCP Tool Calling

Sol vs Terra vs Luna: Which for MCP Servers?

How to Test MCP Servers With GPT-5.6 (Step by Step)

Step 1 — Connect Your MCP Server

Step 2 — Pick a GPT-5.6 Tier

Step 3 — Send and Inspect Every Tool Call

GPT-5.6 vs Claude for MCP Agents: The Honest Take

Getting Reliable Tool Calls From GPT-5.6

How MCP Playground Helps

Gotcha 1: `LATEST_PROTOCOL_VERSION` is `2025-11-25`