DEV Community: Rupa Tiwari

How to let AI run your social media: Claude, Codex, Cursor & more (Full MCP Setup)

Rupa Tiwari — Mon, 12 Oct 2026 06:20:54 +0000

Your AI assistant can already write your posts.

It just can't post them. So you copy, paste, open 6 tabs, upload the same image 6 times, and fix the character count for X by hand.

We built Autoadify's MCP server to kill that copy-paste step. It went live this week.

Here's what it gets you:

Claude, Codex, Cursor, Gemini CLI or VS Code posts to Instagram, Facebook, LinkedIn, X, TikTok, YouTube, Reddit, Bluesky and Threads
Different text per platform, from one request
Your media library, searchable by what's actually in each image
Everything lands in your Autoadify calendar, so you can still see and edit it

Let's get into it.

1. Get a key (2 minutes)

In Autoadify, go to Settings → API & MCP and click Create key.

Give it Read and Publish.

Pro tip: limit the key to the channels you want the assistant to touch. Start with one test channel. Publishing is real, so it goes out on your actual accounts.

The key starts with aak_live_. You only see it once. Put it in your password manager.

(API & MCP are on paid plans, from Pro at $29/mo.)

2. Connect your assistant

One server URL for everything:

https://mcp.autoadify.com/mcp

Claude Code (one line):

claude mcp add --transport http autoadify https://mcp.autoadify.com/mcp --header "Authorization: Bearer aak_live_..."

Cursor: add it to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "autoadify": {
      "url": "https://mcp.autoadify.com/mcp",
      "headers": { "Authorization": "Bearer aak_live_..." }
    }
  }
}

Codex (OpenAI's coding agent). Put your key in an env var, then:

export AUTOADIFY_API_KEY="aak_live_..."
codex mcp add autoadify --url https://mcp.autoadify.com/mcp --bearer-token-env-var AUTOADIFY_API_KEY

Gemini CLI: add it to ~/.gemini/settings.json:

{
  "mcpServers": {
    "autoadify": {
      "httpUrl": "https://mcp.autoadify.com/mcp",
      "headers": { "Authorization": "Bearer aak_live_..." }
    }
  }
}

VS Code, Claude Desktop and any other client that supports remote MCP with a custom header work too. The exact config for each is in the docs (link at the end).

(Using the ChatGPT app? It can't send an API key header to a custom server yet, so use Codex for now.) [CHECK BEFORE POSTING]

3. Ask it what it can see

Before you post anything, run this:

Prompt:

What channels do I have connected, and what does each one need before I can post to it?

This calls list_channels. You get every account plus its rules: Instagram needs an image or video, X caps your characters, Reddit needs a subreddit.

Now your assistant knows the rules before it writes a single word.

That alone fixes half the "why did this fail" moments.

4. Write once, post everywhere (properly)

This is where it clicks.

Prompt:

Here's our announcement: [paste it].
Schedule it to LinkedIn and X for Tuesday 9am IST.
Keep the full version for LinkedIn. Write a punchier version under 280 characters for X.
Show me both versions and the time before you schedule anything.

One post, two versions, one request. Under the hood it's a single post with per-platform text, so it shows up as one item in your calendar.

The "show me before you schedule" line matters. Good assistants confirm first anyway, but say it out loud.

5. Let it find the image for you

Most media libraries are a pile of IMG_4471.JPG.

Ours describes what's actually in each file, so the assistant can search by content.

Prompt:

Find a photo from our library that shows the product on a desk, and use it for an Instagram post tomorrow at 6pm about our new feature.

Don't have the image in the library yet? Give it a link:

Import this image and post it to Instagram tomorrow morning: [URL]

If you're in Claude Code, it can even upload a file straight from your computer.

6. Run your week from one chat

Once it's connected, the calendar is a conversation.

Prompts I use every Monday:

What's scheduled for next week?

Move Friday's post to Monday, same time.

Did yesterday's posts go out? If any failed, tell me why.

That last one is underrated. Every post comes back with its status per platform, the live link, and the exact error if something failed (like a connection that needs reconnecting).

And the errors are written so the assistant can actually fix the request, not just say "400".

7. Guardrails (read this)

It's your real accounts, so:

Scope the key. A read-only key gives the assistant zero tools that change anything. Great for a reporting agent.
Limit channels. Give a test key one channel until you trust the flow.
Same rules as the app. Platform requirements, plan limits and our content policy all still apply.

That's it

No more copy-paste between 6 tabs.

You write (or the AI writes), and the AI schedules it.

Docs + every tool: https://docs.autoadify.com/mcp/overview

6 things that broke when we built an AI pipeline that posts to 9 social networks

Rupa Tiwari — Wed, 07 Oct 2026 13:17:31 +0000

At Autoadify we build Workflows: a schedule, a new Shopify/WooCommerce product, or a post that's taking off fires a pipeline that writes the copy, generates the image/video/voiceover/music, and publishes to Instagram, TikTok, YouTube, Facebook, LinkedIn, X, Threads, Bluesky and Reddit. No human in the loop.

"Call an LLM, then call a posting API" is a weekend project. Making it run unattended every day is not. Here's what broke, and what we changed.

The shape

trigger ─▶ content steps ─▶ transform steps ─▶ publish
            ai_text            add_hashtags       9 networks
            ai_image           rewrite_tone
            ai_edit            translate
            ai_video / ai_animate
            ai_voiceover / ai_music
            library_media

Triggers: schedule (daily/weekly/biweekly/monthly, timezone-aware), shopify / woocommerce (product webhooks, HMAC-verified), monitor_post (fires when a post's likes/comments/shares/impressions/reach/clicks grow past a threshold), plus manual run.

Models: every step has its own model picker over a 60+ model catalog — GPT-5.6, Claude Opus 4.8 / Sonnet 5, Gemini 3.1, Grok, DeepSeek V4, Qwen, Kimi for text; Nano Banana, GPT Image 2, Seedream, Recraft, Krea for images; Veo 3.1, Kling 3.0, Seedance 2.0, Runway Gen-4.5, Hailuo, Wan 3.0 for video; ElevenLabs for voice and music.

Each step's output lands in a context map keyed by step ID, and later steps interpolate it: {{trigger.product.name}}, {{trigger.recent_posts}}, the previous step's text, the previous step's media.

1. The video prompt became the Instagram caption

To keep script and caption consistent, one AI Text step writes both:

[VIDEO PROMPT] Slow push-in on a ceramic mug, steam rising, morning light, 35mm
[CAPTION] Mornings, slower. ☕ New in the shop.

The first version published the "most recent text output" as-is. So a live Instagram caption read "[VIDEO PROMPT] Slow push-in on a ceramic mug…".

Fix: a tiny labelled-section parser. Each consumer reads the section meant for it:

// The part of a text output that is meant to be posted.
export function postCopy(text: string): string {
  const { preamble, sections } = parseSections(text);
  if (sections.length === 0) return text;           // not sectioned — leave it alone
  for (const label of ["CAPTION", "POST", "COPY"]) {
    const caption = sections.find((s) => s.label === label);
    if (caption?.body) return caption.body;         // a caption section wins outright
  }
  // otherwise: drop prompt sections, keep the rest
}

The edge case worth a test: a real caption that starts with [NEW] Spring drop… is not a sectioned output. Only return untouched text when there's no caption or prompt label.

2. "Pick a random photo" re-posted the same photo

The library_media step picks from the user's uploads. Random-with-replacement means a 30-photo library repeats within days, and followers notice.

Fix: pick only from media never published by any post. When the pool is empty, the step fails — it doesn't fall back to a used photo. In an unattended system, a loud failure is better than quietly degraded output.

Second problem: uploads are named IMG_4471.jpg. The caption step had nothing to work with. Every upload now gets a vision pass that stores a description ("a ceramic mug on a linen tablecloth, morning light"), and the library step hands that to the next text step.

3. The daily post said the same thing every day

A scheduled "daily tip" with a fixed prompt is a fixed point: the model converges on the same five tips. Scheduled runs now inject {{trigger.date}}, {{trigger.weekday}} and {{trigger.recent_posts}} — the workflow's own last posts — into the first AI Text step. The model sees what it already said, and rotates.

4. The credit estimate lied

The builder shows "this run costs N credits" before you activate. The first version priced a video step at the length the user picked. But some models snap to their own durations (Grok Imagine renders 6s regardless), so the bill differed from the estimate.

Fix: the estimator uses the same creditsForGeneration function the executor charges with, and replicates the executor's model-fallback rules. Invariant: the estimate is never lower than a full successful run. A failed step refunds.

Related: we charge before calling the provider, so a process killed mid-generation would skip the refund catch. A reaper job refunds generations stuck in PENDING for 45+ minutes.

5. Every platform has a silent failure mode

Things that returned success and still produced a broken post:

LinkedIn: commentary uses "little text format". An unescaped ( silently truncates the post from that point. API returns 201.
Bluesky: link facets use UTF-8 byte offsets. Use JS string indices and links render as dead text. The 300 limit is graphemes.
X: refresh tokens are single-use. Two concurrent jobs refreshing the same account → one wins, the other kills the connection. We serialize refresh behind a Postgres advisory lock.
Threads: a 60-day token that dies permanently if not refreshed in time.

None of these throw. You only find them by reading your own published posts.

6. Safety has to sit on the pipeline, not the editor

We had moderation in the editor UI. Workflows don't use the editor. In fact our four generation entry points (studio, agent, storyboard, workflow executor) shared no common call path, so a control added to one reached none of the others.

Now there's a pre-generation gate (assertGenerationAllowed) in all four, and a pre-publish check on the publish path. Unattended content gets checked twice.

Why not just use n8n?

We get this a lot, and for a lot of teams n8n is the answer — it's fair-code, free to self-host, and connects to everything. If social posting is one branch of a larger automation, use it.

But every section above is something you'd rebuild inside n8n for a social pipeline:

Problem above	In n8n
Publishing to TikTok, Threads, Bluesky	No official core nodes — community node, a paid posting API, or HTTP Request nodes
Long-running video	Submit → Wait → poll loop → download → re-upload to a public URL
`[VIDEO PROMPT]` vs `[CAPTION]`	A Code node with your own parser
Never-repeat media pool	A database table + a query node
Captions for `IMG_4471.jpg`	An extra vision API call
`recent_posts` so daily posts rotate	Query your own post history, pass it in
Credit estimate = actual bill	Separate bills per AI vendor
LinkedIn `(`, Bluesky bytes/graphemes, X token rotation	Discover each one in production
Moderation on every path	Add a moderation node to every workflow

None of that is hard alone. Together it's the product. That's the trade: n8n gives you a general engine and you build the social layer; Autoadify is the social layer.

Takeaways

Fail loud. An empty pool, a dead token, a timed-out render — fail the run and notify. Never "fall back" to something worse.
Estimate with the billing code, not a parallel approximation.
Read your own outputs. The platform said 201. The post was still wrong.
Put controls where every path passes, not where the UI is.

If you'd rather use this than build it: Autoadify Workflows — start from a template, the step builder, or just describe the workflow in plain English. Happy to answer questions about any of the above in the comments.

MCP AI Agent Readiness: Will Agents Pick Your Tools? (2026)

Rupa Tiwari — Wed, 30 Sep 2026 18:06:56 +0000

📖 TL;DR

An agent picks your tools from their names, descriptions and schemas. Nothing else. If those are vague, it picks wrong.
A normal MCP test can't see this. Every call returns 200 whether the model chose well or not.
AI Readiness is a new MCP Playground workspace that measures MCP AI agent readiness: free structure checks, then an AI review.
The AI Agent Readiness Review gives a 0–100 score, a question bank of up to 120 real user questions, ready-to-paste tool rewrites and a list of missing capabilities.
Then it proves it. One click runs the questions against a real model and checks which tool it actually called first.
50 credits per review. Every organisation gets one free preview.

My MCP server passed every test I threw at it. Every tool listed. Every call returned clean JSON.

Then I connected it to an agent. It called the wrong tool on the second question.

Nothing was broken. The server did exactly what I built. The agent just couldn't tell my tools apart.

That gap has a name: MCP AI agent readiness. It's whether a model, reading only your tool definitions, picks the right tool and calls it correctly.

It's also the part almost nobody tests. A green test run tells you the server works, not that an agent can use it.

So I built a workspace for it. It's called AI Readiness, and it lives in the MCP Playground dashboard.

In this post I'll cover the seven problems that break tool selection, why your current tests can't see them, and exactly what the new checks do.

If you ship an MCP server that agents are meant to use, this is the test you're probably missing.

What Is MCP AI Agent Readiness?

MCP AI agent readiness is how reliably a model chooses and calls your tools, using only what your server tells it.

When an agent connects, it calls tools/list. It gets back names, descriptions and input schemas. That's the entire picture it has of your server.

It never sees your code, your database or your docs site. If a description is vague, the model guesses.

The research backs this up. A February 2026 study, "MCP Tool Descriptions Are Smelly!", looked at 856 tools across 103 servers.

97.1% of tool descriptions had at least one defect.
56% never clearly stated what the tool does.
Rewriting them raised task success by a median of 5.85 points, but also increased execution steps by 67.46%.

That last point matters. Longer descriptions aren't automatically better. I covered the study in detail in why most MCP tool descriptions are broken.

Readiness isn't about writing more. It's about writing what lets a model decide.

Seven Problems That Break MCP Tool Selection

Here's what I see again and again when agents struggle with an MCP server. None of these throw an error.

1. Vague descriptions

"Returns user information." Which user? Which fields? What happens without auth?

The model fills the gaps with guesses, and guesses change between runs.

2. Overlapping tools

A search tool and a docs tool that both "find information". The model has no rule for choosing.

Overlap is the most common cause of wrong-tool calls I see in eval runs.

3. Missing `required` lists and untyped parameters

Without a required array, the model can't tell mandatory arguments from optional ones. Without types, it guesses the shape.

You get -32602 invalid params errors, or worse, calls that succeed with the wrong arguments.

4. No tool annotations

The spec defines tool annotations like readOnlyHint and destructiveHint.

Without them, a client can't tell a safe lookup from a delete. It either asks the user every time or doesn't ask at all.

5. Context-token bloat

Every tool definition is re-sent on every request. Seven popular servers can eat 67,300 tokens before the user types anything.

Bloated schemas crowd out the model's working context. I wrote about the fix in MCP context bloat and tool search.

6. Out-of-scope misuse

A user asks your account server to "delete my account". You have no delete tool.

A good agent says so. A confused one calls get_user and pretends to help. Your descriptions never said what the server can't do.

7. Two spec versions in the wild

Servers now speak either the stateful 2025-11-25 protocol or the stateless 2026-07-28 revision.

The same server can behave differently depending on which one a client negotiates. You need to test the version your users' clients actually use.

Why Normal MCP Testing Misses Readiness Problems

Functional tests check that a tool works when you call it. Readiness is about whether a model calls it in the first place.

When you test a tool by hand, you already know which one to pick. The model doesn't.

Check	Functional test	Readiness check
Tool returns valid JSON	✅	—
Model picks the right tool	❌	✅
Model tells overlapping tools apart	❌	✅
Model declines what you can't do	❌	✅
You know what users will ask next	❌	✅

You still need functional testing. Test any MCP server free → first, then check readiness on top.

Free Structure Checks: What a Lint Can and Can't Tell You

Open AI Readiness from the dashboard sidebar, under Build & Secure. Add your server and the free structure checks run straight away.

They look at what a model sees and flag concrete problems:

Missing or very short descriptions
Parameters with no description or no type
No required list
Vague tool names like get_data or run
Schemas over roughly 2,000 tokens
Missing readOnlyHint / destructiveHint annotations and no outputSchema

You also get the total context cost of your tool definitions, in tokens, on every request.

Here's a choice I made on purpose. Structure checks show issue counts, not a score.

A lint can tell you a field is missing. It can't tell you whether a model will pick the right tool.

A tidy schema with a misleading description passes every lint.

Putting "90/100 ready" on a lint result would be dishonest. So the only readiness score in the product comes from the review.

The AI Agent Readiness Review: What You Get

The review reads your tool definitions the way a model does, then tells you where agents will fail.

It's one pass over your names, descriptions, schemas and annotations. It never calls your tools, so it can't change any data on your server.

AI score (0–100) — Excellent 85+, Good 70+, Fair 50+, Needs work below.
Biggest issue — a 2–3 sentence verdict that leads with what to fix first.
Strengths & risks — what works for agents, what will fail, with the tools named.
Question bank — up to 120 real user questions, each mapped to the right tool.
Tool rewrites — clarity and distinctness scores plus a description ready to paste.
Missing capabilities — what users will ask for that no tool can do yet.

The review header: score, rating, key figures and the biggest issue to fix first. Sample server.

The score bands come with plain meaning. "Needs work" means agents are likely to pick the wrong tool or misuse it. "Excellent" means they should pick and call reliably.

Every tool name in the report is clickable. One click opens that tool in the MCP Tester, so you can call it and check.

The MCP Question Bank: What the Questions Are For

This is the part people ask about most. Each question is a test prompt a real user might type to an assistant with your server connected.

Each one names the tool an agent should call first. You get about 50 questions for a one-tool server, 80 for two or three, and 120 for four or more.

They're split into five kinds, because each kind catches a different failure:

Type	Example	What it catches
Direct	"What's the status of ticket 4812?"	The agent can't find the obvious tool
Chained	"Who owns the oldest open bug in billing?"	One tool's output doesn't feed the next
Ambiguous	"Find anything about the login outage."	Two tools look right; descriptions don't decide
Edge case	"Show me all 5,000 tickets from last year."	Limits, pagination, empty results
Out of scope	"Refund this customer."	The agent misuses a tool instead of declining

The question bank: every question mapped to the tool an agent should call first. Sample server.

Ambiguous and out-of-scope questions are where servers fail most. They're also the ones nobody writes by hand.

You can filter by type, search, and page through the bank. Export it as CSV or JSON and use it as a test set anywhere.

Tool Rewrites and Missing Capabilities

Tool rewrites you can paste

Every tool gets two scores out of 10:

Clarity: can a model tell what it does, when to use it and what it returns?
Distinctness: could it be confused with another tool?

You get the specific problems found, then a rewritten description ready to paste. The worst tools come first.

The rewrites keep the facts from your original. They never invent capabilities your tool doesn't have. They stay under 600 characters, because shorter and specific beats long.

Tool rewrites: worst tools first, with a description you can paste straight into your server. Sample server.

Missing capabilities

This section answers a different question: what will users ask for that your server can't do yet?

For an account server, that might be "change a password" or "look up another user". Each item comes with a concrete suggestion for a tool to add.

Each also links to the questions that hit it. Click one and the question bank jumps to it.

Documentation fixes don't belong here. They're already in the rewrites, so the review filters them out. This list is purely what to build next.

Prove It: Run the Questions as Routing Evals

Here's the honest limit of any review. It predicts what an agent will do. It doesn't prove it.

So the report ends with one button: run the questions as evals.

A real model gets your tools and one question at a time. I record which tool it actually calls first.

Pass or fail comes straight from the transcript:

Direct, chained, ambiguous and edge-case questions pass when the first tool call is the expected tool and the model answers within budget.
Out-of-scope questions pass when the model declines without calling any tool.
Calling a different tool first is a Wrong tool result, with a plain explanation of which tool it chose instead.

Because the result is read from what the model did, there's no AI judge in the loop and no judge fee.

There's no writing fee either. The review already wrote the questions.

By default it runs a 20-question sample. Ambiguous questions go first, since they're most likely to fail. You can run the whole bank too.

You choose the model. GPT-6 Luna Pro is the default, because a strong model forgives vague descriptions. If even it picks the wrong tool, the description genuinely needs work.

Want to see how your server does on cheaper models? Pick one. Comparing models is what the best AI model for MCP tool calling is about.

Results show the top failures inline. Full transcripts open in Evals: every tool call, its arguments, the result and the final answer.

Routing evals: which questions a real model routed to the wrong tool, and why. Sample server.

New to evals? What is an MCP eval explains the idea in five minutes.

The loop that actually works: run the review, paste the rewrites into your server, then re-run the evals.

If "Wrong tool" results drop, the fix worked. If they don't, you've learned something a lint never would.

How to Run an MCP Readiness Check in 5 Steps

Open AI Readiness. It's in the dashboard sidebar under Build & Secure.
Add your server. Paste the URL and any auth headers: Bearer, Basic or custom like X-API-Key. Pick HTTP or SSE.
Pick the spec version. Auto tries 2026-07-28 first and falls back to 2025-11-25. You can pin either.
Read the structure checks, then run the AI Agent Readiness Review. It takes a minute or two.
Run the questions as evals, fix what fails, and re-run to confirm.

Testing a local server? Calls run from MCP Playground's servers, so they can't reach localhost. Expose it with a tunnel and paste the public URL:

npx cloudflared tunnel --url http://localhost:3000

Servers you add here are shared with the MCP Tester, so you can call any tool by hand in one click.

Check your server's AI readiness → Free structure checks, plus one free review preview per organisation.

AI Readiness Pricing, Limits and Privacy

Structure checks are free, always.
An AI Agent Readiness Review costs 50 credits. You're only charged if it completes.
Every organisation gets one free preview. You see the score, verdict, strengths and risks in full, plus a sample of the rest. Unlocking the full report costs 50 credits, with no second model call.
Routing evals are billed per tool call, at the rate of the model you pick. You see the price before you run.
Each organisation can review up to 5 different servers for now. Re-running a server you've already reviewed is always allowed.

On privacy: auth headers are encrypted at rest and never sent back to your browser. Private and loopback addresses are blocked on every call.

The review only reads your tool definitions. It never calls a tool. Only the evals you choose to run make real calls.

Conclusion

A working MCP server and an agent-ready one aren't the same thing. Agents choose from your descriptions alone, and most descriptions don't give them enough.

AI Readiness gives you free structure checks, an AI review with rewrites you can paste, and routing evals that prove whether the fixes worked.

Run it before your users find the gaps for you. Check your server's AI readiness →

Want the fundamentals first? Start with what the Model Context Protocol is, or testing MCP servers with real AI models.

FAQ

What is MCP AI agent readiness?

It is how reliably an AI model picks and calls the right tool on your MCP server, using only the tool names, descriptions and schemas your server returns from tools/list. A server can work perfectly and still score low if its tools are vague or overlap.

Does the AI Agent Readiness Review call my tools?

No. The review reads your tool definitions only, so it cannot change data on your server. Real tool calls happen only if you choose to run the questions as routing evals.

Why don't the free structure checks give a score?

A lint can find missing fields, but it cannot tell whether a model will choose the right tool. A tidy schema with a misleading description passes every lint, so a score there would overstate readiness. The only score comes from the AI review.

How do routing evals decide pass or fail?

From the transcript, with no judge model. A question passes when the model's first tool call is the expected tool and it answers within budget. An out-of-scope question passes when the model declines without calling any tool.

How much does an AI readiness review cost?

Structure checks are free. A full AI Agent Readiness Review costs 50 credits, and every organisation gets one free preview. Routing evals are billed per tool call at the chosen model's rate, and the price is shown before you run.

Can I test a localhost MCP server?

Not directly, because calls run from MCP Playground's servers. Expose your local server with a tunnel such as cloudflared or ngrok and add the public URL instead.

Originally published on MCP Playground.

MCP Observability: How to Trace Every Tool Call in Production

Rupa Tiwari — Thu, 24 Sep 2026 18:33:49 +0000

📖 TL;DR

MCP observability means seeing the full path from a prompt, through the model's tool choice, into your server, and back.
The 2026-07-28 spec deprecated protocol-level Logging, along with Roots, Sampling and HTTP+SSE, on a twelve-month clock.
OpenTelemetry's GenAI semantic conventions now include a dedicated MCP section with defined spans, attributes and metrics.
Trace context travels in params._meta using unprefixed traceparent, tracestate and baggage keys.
The MCP client span is the parent of the server span, regardless of transport. That is what repairs a broken trace.
The conventions are not stable yet. Pin your instrumentation version and expect attribute renames.

A tool call failed in production last week. The agent said "I wasn't able to retrieve that."

That was the entire signal. No stack trace, no timing, no tool name.

This is the MCP observability gap, and almost every team building agents hits it around month three. Your app has traces. Your MCP server has logs. Neither knows the other exists.

The worst part is not the outage. It is the failure that looks like success — a confident, wrong, expensive answer that nobody flags for a week.

Two things changed in 2026 that make this fixable. The 2026-07-28 MCP specification deprecated protocol-level Logging. And OpenTelemetry's GenAI semantic conventions grew a proper MCP section with defined span names, attributes and metrics.

So there is now one vendor-neutral vocabulary for agent, tool and MCP spans.

I'll walk through the exact field names, how trace context survives a stateless request, what to alert on, and the five mistakes that quietly produce useless traces.

If you are new to the protocol itself, start with my introduction to the Model Context Protocol first.

What Is MCP Observability, Exactly?

MCP observability is the ability to answer "what did the agent actually do" from telemetry alone.

That means three linked questions, not one.

Which tool did the model pick, and why that one? Model-side. Lives in your LLM spans.

What did the server do with that call? Server-side. Latency, downstream calls, errors.

Did the result actually help? Outcome-side. Did the agent retry, give up, or hallucinate around a bad result?

Traditional APM answers the middle question well and the other two not at all.

An MCP tool call is a distributed transaction that crosses a model, a client, a transport and your backend. Treat it like one.

The three signals map cleanly:

Traces — the causal path of one request across client and server.
Metrics — call rate, duration percentiles, error rate per tool.
Logs — the detail you attach to a span, not a separate stream.

That last point is the one that changed this year.

The 2026-07-28 Spec Deprecated Logging — Here Is What Replaced It

The 2026-07-28 specification deprecated four things at once: Roots, Sampling, Logging, and the legacy HTTP+SSE transport.

Each gets a minimum twelve-month support window. These were the first deprecations to follow MCP's new formal feature lifecycle policy.

Logging is the one that matters here. MCP servers were inventing their own log formats and shipping them over the protocol. That never aggregated well.

The replacement is not another MCP feature. It is OpenTelemetry.

The spec also documented W3C Trace Context propagation with fixed keys — traceparent, tracestate and baggage. Distributed traces now correlate across SDKs and render as one span tree in your backend.

⚠️ Practical read on the deadline

If you built on notifications/message logging, you have until roughly mid-2027. Do not rewrite in a panic, but do not build anything new on it either.

The rest of the release pushed the same direction. Stateless core, header-based routing via Mcp-Method and Mcp-Name, and cacheable list results carrying ttlMs and cacheScope.

All of that assumes you can see across many short-lived requests rather than one long session. Which is exactly what tracing gives you.

If you have not made that move yet, my guide to migrating to the 2026-07-28 stateless spec covers the breaking changes.

Why Your Agent Traces Break at the MCP Boundary

Here is the failure, concretely.

Your agent framework emits a span for the LLM call. Good. It emits a child span for "tool use". Still good.

Then the request crosses into your MCP server and a brand-new, parentless trace begins.

You now have two traces for one logical operation. Neither is searchable by the other's ID.

Ask "why did the checkout agent take 40 seconds" and you get an agent trace showing 40 seconds of "tool call" and a server trace showing 38 seconds of something. Joining them is manual archaeology.

The root cause is that JSON-RPC over HTTP has nowhere obvious to put trace headers. MCP is a protocol on top of a transport, and the transport headers are not always yours to control — gateways rewrite them, stdio has none at all.

This got worse with the stateless spec, not better. Without Mcp-Session-Id, you lost the one accidental correlation key many teams were quietly relying on.

Every request now travels alone, carrying its own protocol version, client identity and capabilities in _meta.

Which turns out to be the hint. _meta is also where the trace context goes.

The OpenTelemetry MCP Semantic Conventions, Field by Field

OpenTelemetry's GenAI Special Interest Group formed in April 2024 and has since expanded to cover agent orchestration, MCP tool calling, content capture and quality evaluation.

The MCP conventions live in the semantic-conventions-genai repository.

The headline rule: when instrumenting MCP calls, follow the MCP conventions rather than the generic RPC conventions. MCP spans record things RPC spans cannot — tool identity, protocol version, message exchanges inside streaming calls.

Span names and kinds

Both sides use the same name format: {mcp.method.name} {target}.

The target matches gen_ai.tool.name or gen_ai.prompt.name where one applies. So a tool call becomes tools/call get_invoice, not a generic POST /mcp.

Client span — kind CLIENT
Server span — kind SERVER

That naming alone fixes most dashboards. You can group by tool without parsing a request body.

The attributes that matter

Attribute	Level	What it carries
`mcp.method.name`	Required	The request or notification method.
`jsonrpc.request.id`	Conditional	When the client executes a request, as a string.
`mcp.resource.uri`	Conditional	When the request carries a resource URI.
`error.type`	Conditional	If the operation fails.
`rpc.response.status_code`	Conditional	If the response carries an error code.
`gen_ai.operation.name`	Recommended	Set to `execute_tool` for tool calls.
`mcp.protocol.version`	Recommended	Which spec revision this request speaks.
`mcp.session.id`	Recommended	Where a session concept still applies.
`network.transport`	Recommended	`tcp`, `quic`, or `pipe` for stdio.
`gen_ai.tool.call.arguments`	Opt-in	The parameters passed in. Off by default.
`gen_ai.tool.call.result`	Opt-in	What came back. Off by default.

Those opt-in attributes are opt-in for a reason. Tool arguments routinely carry customer records, tokens and internal IDs. Turn them on in staging, sample them hard in production, and scrub before export.

mcp.protocol.version deserves a callout. Once you support two spec revisions, it becomes the single most useful attribute you have — it tells you which clients are still on the old path.

The four metrics

mcp.client.operation.duration
mcp.server.operation.duration
mcp.client.session.duration
mcp.server.session.duration

Client and server duration are split on purpose. The gap between them is your transport, gateway and queueing cost — and it is usually where the surprise lives.

How Context Propagation Works Through params._meta

This is the mechanism that stitches the trace back together.

Instrumentations inject trace context into the MCP request's params._meta property bag using the configured OpenTelemetry propagators. The keys are unprefixed: traceparent, tracestate, baggage.

So a tools/call on the wire carries something like this:

JSON-RPC request frame

{
  "jsonrpc": "2.0",
  "id": "42",
  "method": "tools/call",
  "params": {
    "name": "get_invoice",
    "arguments": { "invoice_id": "inv_123" },
    "_meta": {
      "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"
    }
  }
}

On the receiving side the rule is explicit. Server instrumentation should use the context extracted from params._meta as the parent for the server span, and should link the ambient context if one is present.

Read that twice, because the ordering is the whole trick.

The MCP client span becomes the parent of the MCP server span regardless of transport. Span links then record the transport context separately, where one exists.

Why parent from _meta rather than from HTTP headers? Because _meta rides inside the protocol. It survives stdio, gateways that rewrite headers, and the stateless routing layer. HTTP headers do not.

That is also why this works for local stdio servers, where there is no HTTP request to hang a header on at all.

How to Instrument an MCP Server With OpenTelemetry

The order matters. Do it in this sequence and you get a usable trace on the first try.

1. Install the SDK and set a real service name. The service.name value shows up as the box in every trace diagram. unknown_service helps nobody.

2. Wrap the request handler, not the transport. You want one SERVER span per JSON-RPC request. Name it {mcp.method.name} {target} and set the kind explicitly.

3. Extract the parent from params._meta before you create the span. Pull traceparent out and pass it to your propagator's extract call. If it is missing, start a fresh root span rather than throwing.

4. Set mcp.method.name on every span. It is the one required attribute. Everything downstream groups by it.

5. Add gen_ai.operation.name set to execute_tool on tool calls. This is what makes your MCP spans join the wider GenAI span tree instead of sitting off to the side.

6. Record errors as error.type, and set rpc.response.status_code when the JSON-RPC response carries an error code.

The single most common gap

A JSON-RPC error is still an HTTP 200. If you only alert on HTTP status, your error rate reads as zero while the agent fails every call. This is the same class of problem behind MCP error -32602, which returns a perfectly healthy 200.

7. Propagate outward. If your tool calls a database or a third-party API, those become child spans automatically once the context is active.

8. Keep payload capture opt-in. Gate gen_ai.tool.call.arguments behind an environment variable. Default it off.

One caution before you wire this into a build pipeline: the GenAI conventions are still under active development and not stable. Pin your instrumentation library version and read the changelog on upgrade. Attribute names have moved before.

Coding agents including VS Code Copilot, OpenAI Codex and Claude Code already emit OTel GenAI traces, so the client half is increasingly free.

Is _meta actually populated on the wire?

Do not trust the library. Connect to your server in the browser and read the raw JSON-RPC frames your instrumentation is really sending.

Test any MCP server free → Scan your MCP server

What to Actually Alert On

Dashboards are easy. Useful alerts are not.

Alert on tool-level error rate, not server-level. One broken tool out of thirty will never move an aggregate. Group by mcp.method.name plus gen_ai.tool.name and alert per tool.

Alert on the client-server duration gap. If client duration p95 runs far above server duration p95, your server is fine and your gateway is not.

Alert on p95, never on mean. Agent latency distributions are brutally long-tailed. One tool doing a cold database connect will hide entirely in an average.

Alert on retry storms. Same tool name, same arguments, three or more calls inside one trace means the agent is stuck in a loop and burning tokens.

Alert on protocol version drift. A sudden rise in old mcp.protocol.version values means a client rolled back, or a new one connected on the deprecated path.

What not to page on: tools/list volume. Cacheable list results arrived in the 2026-07-28 spec with ttlMs and cacheScope, so list traffic now varies with client cache behaviour, not with demand.

One thing tracing will not tell you: whether the answer was correct. Latency and error rate say nothing about quality — that gap is what MCP evals exist to close. Run both.

How to Test MCP Observability Before You Ship

Instrumentation that emits nothing fails silently. That is the whole problem with it.

Check these four before you call it done.

Does a real client call produce two spans, not one? A client span and a server span, with the server span's parent set to the client span.
Does _meta actually carry traceparent on the wire? Read the raw frame.
Does a deliberately failing tool set error.type? Force a bad argument and look.
Does a stdio server still correlate? network.transport should read pipe and the parent should still resolve.

The fastest way to check all four is to drive the server with a real client and watch the JSON-RPC traffic. For the wider checklist, my step-by-step guide to testing MCP servers covers the functional side.

Five MCP Observability Mistakes I Keep Seeing

1. Treating a JSON-RPC error as a success. The transport returns 200. The call failed. If your error rate comes from HTTP status codes alone, it is wrong.

2. Using RPC semantic conventions instead of MCP ones. You get a span called POST with no tool name. Technically valid, operationally useless.

3. Logging tool arguments by default. gen_ai.tool.call.arguments is opt-in because arguments carry customer data and credentials. Shipping it to a third-party backend by default is a data-handling incident waiting to happen.

4. Instrumenting the transport instead of the handler. A span per HTTP request looks fine until one request carries a batch, or the transport is stdio and there is no HTTP request at all.

5. Assuming the conventions are frozen. They are not stable. An unpinned instrumentation library can rename an attribute in a patch release and quietly break every dashboard that depends on it.

If you are auditing what your server exposes more broadly, my complete MCP server security guide covers the data-handling side of mistake three.

Instrument One Tool First

MCP observability comes down to three moves. Emit MCP-specific spans rather than generic RPC ones, propagate trace context through params._meta, and alert per tool instead of per server.

The spec deprecating Logging was not a loss. It pushed MCP onto a vocabulary that every observability backend already speaks.

Start with one tool. Confirm the client span actually parents the server span. Then expand.

And if you run several servers behind one entry point, the gateway itself becomes a span worth watching — my MCP gateway guide covers that routing layer.

FAQ

Is MCP logging removed?

Deprecated, not removed. The 2026-07-28 specification deprecated Logging alongside Roots, Sampling and the legacy HTTP+SSE transport, each with a minimum twelve-month support window. Existing code keeps working through that period, but new work should emit OpenTelemetry data instead of protocol-level log notifications.

Do I need OpenTelemetry to run an MCP server?

No, it is optional. A single-user local server does fine without it. But once more than one team calls your server, or once it runs behind a gateway or load balancer, correlating a failure without distributed tracing becomes guesswork across two unrelated log streams.

How does tracing work for stdio MCP servers with no HTTP headers?

Trace context travels inside the params._meta property bag of the JSON-RPC request, not in transport headers, so stdio works identically to HTTP. Set network.transport to pipe on the span. This is precisely why the OpenTelemetry MCP conventions propagate through _meta rather than relying on the transport layer.

Does the stateless 2026-07-28 spec break tracing?

The opposite. Losing Mcp-Session-Id removed an accidental correlation key that many teams were relying on, and _meta-based trace propagation is the deliberate replacement. It survives load balancers, header-rewriting gateways and round-robin routing in a way session IDs never did.

Which observability backend should I send MCP traces to?

Any OTLP-compatible backend. That is the point of a vendor-neutral semantic convention: the span shape is identical whether it lands in Jaeger, Grafana Tempo, Datadog, Honeycomb or a self-hosted collector. Choose on cost and retention rather than on MCP support, since the conventions do the compatibility work.

Why is my MCP error rate showing zero when calls are failing?

Because a JSON-RPC error is returned inside a successful HTTP 200 response. If your monitoring derives error rate from HTTP status codes alone, every failed tool call looks healthy. Set error.type on the span and populate rpc.response.status_code when the JSON-RPC response carries an error code.

Originally published on MCP Playground.

MCP Agent Use Cases: 8 AI Agents You Can Build by Role

Rupa Tiwari — Tue, 15 Sep 2026 08:25:22 +0000

📖 TL;DR

An MCP agent is four things: a model, two or three MCP servers, a system prompt, and a guardrail on writes.

Sales → HubSpot or Salesforce + Slack + Calendar. Marketing → Ahrefs or Semrush + Exa + Notion.

Social media → X and TikTok have official ad MCP servers. Organic posting still needs Zapier or your own server.

Support → Stripe + Slack + Linear. Data → PostHog or Amplitude + your warehouse. Engineering → GitHub + Sentry + Linear.

Three servers is the ceiling for most agents. Past that, tool-selection accuracy falls off a cliff.

Model choice is a cost decision, not a quality one. Haiku for routing, Sonnet for reasoning, Opus for long chains.

Every team I talk to wants the same thing from MCP. Not a protocol tour — an agent that does their actual job.

The sales lead wants call prep. The marketer wants a content brief that cites real keyword data. The support lead wants refund triage.

These are all the same build. Only the servers change.

So this post is organised the way you actually think about it: by role. For each one I list the MCP servers worth connecting, the hosted URLs, a model recommendation, and example prompts that work on day one.

I have kept every URL genuine. Where a service has no official hosted MCP server, I say so instead of inventing one.

Anatomy of an MCP Agent (Four Parts, No More)

Strip away the frameworks and every MCP agent is the same four things.

Part	What it decides	Where teams get it wrong
Model	How well it picks the right tool	Paying for a frontier model to do lookups
MCP servers	What the agent can actually reach	Connecting eight when three would do
System prompt	The job, the tone, the limits	Vague role text with no stop rules
Write guardrail	What it may change without asking	Skipped entirely until something breaks

The fourth row is the one people skip. An agent with a Stripe token can issue refunds. An agent with a CRM token can overwrite deal stages.

I put one line in every system prompt I write: propose writes, never execute them, until I say go.

How to Pick MCP Servers for Any Agent

The instinct is to connect everything. Resist it.

Every connected server injects its full tool schema into the model's context on every single request. A large server like GitHub runs to roughly 18,000 tokens on its own.

Connect six of those and you have burned your context window before the user types a word. Worse, tool-selection accuracy drops as near-identical tool descriptions pile up.

I use a three-server rule, and each server plays a distinct part:

System of record — where the truth lives. HubSpot, GitHub, Stripe, your warehouse.
Context source — what fills the gaps. Exa for the web, Notion for internal docs, Calendar for timing.
Delivery channel — where the output lands. Slack, Notion, Linear.

Record, context, channel. Almost every useful agent below is that shape.

1. The Sales Agent: CRM Hygiene and Call Prep

Sales reps lose hours to two chores. Researching a prospect before a call, and updating the CRM after it.

Both are pure context assembly. That is exactly what an MCP agent is good at.

MCP server	Hosted URL	What it unlocks
HubSpot	`https://mcp.hubspot.com`	Deals, contacts, pipeline stages, notes
Salesforce	Per-org URL from your instance	Opportunities, accounts, custom objects
Clay	`https://mcp.clay.earth/mcp`	Enrichment, firmographics, contact finding
Exa	`https://mcp.exa.ai/mcp`	Live web research on the account
Google Calendar	`https://calendarmcp.googleapis.com/mcp/v1`	Who you are meeting, and when
Slack	`https://mcp.slack.com/mcp`	Delivery channel for the brief

My recommended build: Calendar + HubSpot + Exa. The agent reads tomorrow's meetings, pulls each account's CRM history, and researches recent news.

Model: Claude Sonnet 5. Call prep involves synthesis across three sources, which is where cheaper models start dropping details.

Prompts that work immediately:

Prep me for tomorrow's calls. For each one, pull the deal stage, last contact date, and anything newsworthy about the company.
Which deals have had no activity in 21 days and are still marked as open?
Draft a follow-up email for the Acme deal referencing what we discussed last time.

Watch the write scope. A HubSpot token with write access lets the agent change deal stages. Start read-only, and add writes once you trust its judgement.

2. The Marketing Agent: Briefs Backed by Real Data

Most AI content workflows fail for one reason. The model has no idea what people actually search for.

It guesses at keywords, invents volumes, and produces a brief that reads well and ranks nowhere.

Connecting a real SEO data source fixes that in one step.

MCP server	Hosted URL	Best for
Ahrefs	`https://api.ahrefs.com/mcp/mcp`	Backlinks, keyword difficulty
Semrush	`https://mcp.semrush.com/v1/mcp`	Competitor gaps, position tracking
DataForSEO	`https://mcp.dataforseo.com/mcp`	Raw SERP data, cheapest per call
OpenSEO	`https://app.openseo.so/mcp`	AI-search visibility tracking
Firecrawl	`https://mcp.firecrawl.dev/v2/mcp`	Scraping competitor pages to markdown
Notion	`https://mcp.notion.com/mcp`	Where the finished brief lands
Webflow / Sanity	`https://mcp.webflow.com/mcp` / `https://mcp.sanity.io`	Publishing straight to the CMS
Canva	`https://mcp.canva.com/mcp`	Generating on-brand visuals

My recommended build: Ahrefs + Exa + Notion. Keyword truth, live SERP context, and a place to file the output.

Model: Sonnet 5, or a stronger reasoning model when the brief spans a dozen competitor pages.

Prompts worth stealing:

Find five keywords we rank on page two for, with difficulty under 30, and outline a post for the best one.
Compare the top five results for this keyword and list every heading they cover that we do not.
Which of our published posts have lost positions in the last 90 days?

Before you hand an SEO server real API credits, connect it in the browser and read its tool list. Ahrefs and Semrush both meter by call, and a chatty agent burns quota fast.

Test any MCP server free →

3. The Social Media Agent: Where MCP Helps and Where It Does Not

This is the role with the biggest gap between expectation and reality, so let me be blunt about it.

Paid social has excellent official MCP coverage. Organic posting mostly does not.

X and TikTok both ship real hosted MCP servers, and both are aimed at advertising. There is no official hosted MCP server for scheduling an Instagram carousel or a LinkedIn post.

Platform	MCP URL	Scope
X (Twitter)	`https://api.x.com/mcp`	Official, ads and API surface
TikTok for Business	`https://business-api.tiktok.com/open_mcp/tt-ads-mcp-flat`	Official, campaign management
Meta Ads (Pipeboard)	`https://meta-ads.mcp.pipeboard.co/`	Third-party, Facebook and Instagram ads
Apify	`https://mcp.apify.com`	Scraping public profiles and competitor feeds
Canva	`https://mcp.canva.com/mcp`	Generating post creative from a brand template
Zapier	Per-account URL you generate	The practical bridge to organic posting

Zapier is the honest answer for scheduling. You pick the actions you want exposed, Zapier generates a private MCP endpoint, and the agent calls those actions as tools.

It is not elegant. It works today, and it covers the platforms nobody else does.

Model: Sonnet-class for ad analysis. A cheap model is plenty if the agent only drafts copy and reads metrics.

Prompts to start with:

Which three ad sets had the worst ROAS last week, and what do the winning ones have in common?
Pull our last 20 posts and tell me which format gets the most saves.
Draft five hooks for this week's launch, each under 200 characters, in our usual voice.

4. The Customer Support Agent: Triage Before a Human Reads It

Support tickets arrive with no context. The agent's job is to attach it before a human opens the thread.

Who is this customer? What plan are they on? Did they just get charged twice? Is this a known bug?

Three servers answer all four questions.

Stripe — https://mcp.stripe.com/ for subscription state, invoices and failed payments.
Slack — https://mcp.slack.com/mcp to read the support channel and post the summary back.
Linear — https://mcp.linear.app/sse to check whether the bug is already filed.

Model: Claude Haiku 4.5. Triage is high-volume and low-ambiguity, which is the cheapest model's sweet spot.

This is also the role where read-only really matters. A support agent should never issue a refund on its own initiative.

⚠️ Prompt injection is a live risk here. Ticket text is untrusted input written by strangers. An agent that reads tickets and holds a Stripe write token is one crafted message away from a bad day. Keep the refund tool out of its reach.

Scan your MCP server →

5. The Data and Analytics Agent: Answers Without a Ticket

Every analytics team has the same queue. Twenty people asking questions that are one SQL query away from an answer.

An MCP agent with warehouse access clears most of that queue, as long as you keep it read-only.

Category	Servers
Product analytics	PostHog `https://mcp.posthog.com/mcp`, Amplitude `https://mcp.amplitude.com/mcp`
Warehouses	BigQuery `https://bigquery.googleapis.com/mcp`; Snowflake and ClickHouse run locally
App databases	Neon `https://mcp.neon.tech/sse`, MongoDB via its local server
Notebooks	Hex `https://app.hex.tech/mcp`

My recommended build: one analytics source, one warehouse, Slack for delivery.

Model: a strong reasoning model. SQL generation against an unfamiliar schema is where the cheaper tiers start guessing at column names.

Non-negotiable: connect with a read-only role. Not a role you promise to use carefully — one the database will not let write.

6. The Engineering Agent: The Best-Served Role in MCP

Engineering has the deepest MCP coverage of any function. Almost every developer tool shipped a server first.

Server	URL	Agent job
GitHub	`https://api.githubcopilot.com/mcp/`	PR review, release notes, stale-branch sweeps
Sentry	`https://mcp.sentry.dev/mcp`	Error triage, regression spotting
Linear	`https://mcp.linear.app/sse`	Sprint state, ticket creation
Vercel	`https://mcp.vercel.com`	Deploy status, build log reading
Cloudflare	`https://mcp.cloudflare.com/mcp`	Workers, DNS, edge config
Figma	`https://mcp.figma.com/mcp`	Design-to-code handoff
Context7	`https://mcp.context7.com/mcp`	Current library docs, no auth needed
Datadog	`https://mcp.datadoghq.com/api/unstable/mcp-server/mcp`	Live metrics and logs during an incident
PagerDuty	`https://mcp.pagerduty.com/mcp`	On-call context and incident timelines

Three builds cover most of what engineering teams ask for:

Engineering lead — GitHub + Linear + Slack. Sprint status without the standup.
Full-stack shipper — GitHub + Vercel + Sentry. Ship, watch, roll back.
Post-incident review — Sentry + Linear + Slack. A timeline written while it is still fresh.

Model: the top tier. Code reasoning across a diff is the one place a frontier model consistently earns its cost.

Only the GitHub server is free to connect with no key. Context7 is the other one, which makes the pair a good first test.

7. The Project Ops Agent: Meetings In, Tasks Out

Project managers spend their week converting one format into another. Meeting notes into tickets. Tickets into status updates.

That is mechanical work, and it is the easiest agent on this list to get right.

Asana — https://mcp.asana.com/mcp
Monday.com — https://mcp.monday.com/mcp
Jira and Confluence — https://mcp.atlassian.com/v1/mcp
Airtable — https://mcp.airtable.com/mcp
Google Calendar — https://calendarmcp.googleapis.com/mcp/v1

My recommended build: Calendar + Notion + Slack. It reads yesterday's meetings, finds the notes, and drafts the action items.

Model: Haiku 4.5. Summarising and restructuring text does not need a reasoning model, and this agent runs daily.

8. The Finance and RevOps Agent: Revenue Questions, Answered Live

Finance questions are usually simple and always urgent. Which subscriptions failed to renew this week?

Payment platforms have solid MCP coverage, so this one is quick to stand up.

Stripe — https://mcp.stripe.com/ for subscriptions, invoices, disputes and payouts.
PayPal — https://mcp.paypal.com/mcp for orders and refunds.
Cashfree — https://mcp.cashfree.com/mcp for India-first payment flows.

Join Stripe to Linear and Slack, and a spike in failed payments becomes a tracked issue rather than a Slack message nobody actions.

Model: Sonnet-class. Money questions deserve a model that checks its arithmetic against the tool output rather than guessing.

Which Model for Which Agent?

Teams overthink this. Model choice is a cost decision far more often than a quality one.

A triage agent reading tickets does not need frontier reasoning. A code-review agent across a 900-line diff does.

Tier	Use it for
Nano / Flash	One-tool lookups, routing, Zapier actions
Claude Haiku 4.5	Support triage, standups, daily digests
Claude Sonnet 5	The default. Sales, marketing, finance
Claude Sonnet 4.6	Three servers, long tool chains, SQL
Claude Opus 5	Code review, incident analysis, hard chains

Start one tier below what you think you need. If the agent picks the wrong tool or drops a step, move up one and compare.

Test Before You Trust: Four Checks That Take Five Minutes

Here is the failure mode I see most. Someone wires four servers into an agent, it behaves strangely, and they blame the model.

Nine times out of ten the server was the problem. It exposed three tools instead of the twelve the docs promised, or its auth silently failed.

So before any URL above goes into an agent, run it through four checks:

Does it connect at all? Paste the URL into a tester and watch the handshake.
What tools does it really expose? Read the list. Compare it to what you assumed.
Does a real call return real data? A tools list that loads is not proof the tool works. Invoke one.
How big is the schema? A server with 40 verbose tools will crowd out everything else you connect.

This runs in the browser with no install. Paste any remote MCP URL, complete the OAuth flow or add a bearer token, and inspect the tool list and raw JSON-RPC responses before you commit.

Five Mistakes That Ruin Otherwise Good Agents

1. Connecting every server you can find. Three is the working ceiling. Each extra one costs context and accuracy.

2. Giving write access on day one. Run read-only for a week. Read the transcripts. Then decide which writes it has earned.

3. Using one generic system prompt for every agent. A sales agent and a support agent need different stop rules, not the same helpful-assistant boilerplate.

4. Skipping the token scope review. A GitHub token with repo scope reaches every private repository you can. Scope it down before it goes in.

5. Never evaluating the thing. If you cannot say whether last week's version was better, you are guessing.

Start With One Role, Not a Platform

The pattern repeats across every role here. One system of record, one context source, one delivery channel, and a model matched to the difficulty.

Sales gets a CRM and a calendar. Marketing gets keyword data. Support gets billing state. Engineering gets the repo and the error tracker.

Pick the role that loses the most hours this week and build that one. Test every server in the browser before you trust it with a token.

Related Guides

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.

DEV Community: Rupa Tiwari

How to let AI run your social media: Claude, Codex, Cursor & more (Full MCP Setup)

1. Get a key (2 minutes)

2. Connect your assistant

3. Ask it what it can see

4. Write once, post everywhere (properly)

5. Let it find the image for you

6. Run your week from one chat

7. Guardrails (read this)

That's it

6 things that broke when we built an AI pipeline that posts to 9 social networks

The shape

1. The video prompt became the Instagram caption

2. "Pick a random photo" re-posted the same photo

3. The daily post said the same thing every day

4. The credit estimate lied

5. Every platform has a silent failure mode

6. Safety has to sit on the pipeline, not the editor

Why not just use n8n?

Takeaways

MCP AI Agent Readiness: Will Agents Pick Your Tools? (2026)

What Is MCP AI Agent Readiness?

Seven Problems That Break MCP Tool Selection

1. Vague descriptions

2. Overlapping tools

3. Missing required lists and untyped parameters

4. No tool annotations

5. Context-token bloat

6. Out-of-scope misuse

7. Two spec versions in the wild

Why Normal MCP Testing Misses Readiness Problems

Free Structure Checks: What a Lint Can and Can't Tell You

The AI Agent Readiness Review: What You Get

The MCP Question Bank: What the Questions Are For

Tool Rewrites and Missing Capabilities

Tool rewrites you can paste

Missing capabilities

Prove It: Run the Questions as Routing Evals

How to Run an MCP Readiness Check in 5 Steps

AI Readiness Pricing, Limits and Privacy

Conclusion

FAQ

What is MCP AI agent readiness?

Does the AI Agent Readiness Review call my tools?

Why don't the free structure checks give a score?

How do routing evals decide pass or fail?

How much does an AI readiness review cost?

Can I test a localhost MCP server?

MCP Observability: How to Trace Every Tool Call in Production

What Is MCP Observability, Exactly?

The 2026-07-28 Spec Deprecated Logging — Here Is What Replaced It

Why Your Agent Traces Break at the MCP Boundary

The OpenTelemetry MCP Semantic Conventions, Field by Field

Span names and kinds

The attributes that matter

The four metrics

How Context Propagation Works Through params._meta

How to Instrument an MCP Server With OpenTelemetry

What to Actually Alert On

How to Test MCP Observability Before You Ship

Five MCP Observability Mistakes I Keep Seeing

Instrument One Tool First

FAQ

Is MCP logging removed?

Do I need OpenTelemetry to run an MCP server?

How does tracing work for stdio MCP servers with no HTTP headers?

Does the stateless 2026-07-28 spec break tracing?

Which observability backend should I send MCP traces to?

Why is my MCP error rate showing zero when calls are failing?

MCP Agent Use Cases: 8 AI Agents You Can Build by Role

Anatomy of an MCP Agent (Four Parts, No More)

How to Pick MCP Servers for Any Agent

1. The Sales Agent: CRM Hygiene and Call Prep

2. The Marketing Agent: Briefs Backed by Real Data

3. The Social Media Agent: Where MCP Helps and Where It Does Not

4. The Customer Support Agent: Triage Before a Human Reads It

5. The Data and Analytics Agent: Answers Without a Ticket

6. The Engineering Agent: The Best-Served Role in MCP

7. The Project Ops Agent: Meetings In, Tasks Out

8. The Finance and RevOps Agent: Revenue Questions, Answered Live

3. Missing `required` lists and untyped parameters

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