标签：#mcp

Opening Google Analytics to answer one question is a special kind of tax. You know the number is in there. You also know it's four clicks, two date pickers and a dimension dropdown away, and by the time you've found it you've forgotten what you wanted it for. So I built Metrifyr : a remote MCP server that puts my Google marketing stack behind my AI agent. Nothing to install: connect it once (Claude, Cursor, VS Code, any MCP client), then ask the question in plain language and it goes and gets the number. It's in the Cursor marketplace and the official MCP Registry, and the catalog has grown past a hundred tools, though, as you'll see, no single session loads them all. What's actually connected Metrifyr isn't a wrapper around one API. It federates the whole Google marketing surface behind a single MCP connection: Analytics 4 : run reports, realtime, metadata, compare periods. Plus the admin side: create properties, data streams, conversion events, custom dimensions and metrics. Search Console : search analytics, URL inspection, sitemaps. AdSense : accounts, earnings, payment history, revenue by keyword. Tag Manager : read and audit containers, tags, triggers, variables. Google Ads : campaign planning. Connect it once, and the agent can reach across all of them in a single train of thought. "Which landing pages lost the most organic traffic last quarter, and were any of them earning AdSense revenue?" is one question to me. It's Search Console and Analytics and AdSense to the machine, joined without me opening a single tab. Raw numbers are the boring part Pulling a GA4 report over MCP is table stakes. The part I actually care about is the layer on top, the analysis tools that answer the questions you'd otherwise pay an SEO consultant to run: Content decay scan : which pages are quietly bleeding traffic month over month. Striking-distance optimizer : the queries ranking positions 11 to 20, one nudge away from page one. Keyword cannibalization : where two of your own pag

We use AskElephant to record client calls, and we work in claude.ai. Those two things could not talk to each other, and the reason is structural rather than a missing feature. AskElephant ships an MCP server. It runs locally over stdio, which serves Claude Desktop, Cursor, VS Code and Windsurf. A browser cannot spawn a process on your laptop, so claude.ai needs an MCP server at an HTTPS address. That is a different program. Building it took about a day. Working out what it should refuse to do took considerably longer, and that part generalises to any MCP server sitting in front of a large corpus. The code is on GitHub . The arithmetic that determines the design Before writing tools, measure your payload. We measured every transcript in our account: 3,706 engagements, 2,230 of which carry one. Characters Approx tokens Average transcript-bearing call 32,485 8,100 Median 28,240 7,060 p95 75,543 18,885 Largest 175,643 43,900 The largest single call is more than a fifth of a 200,000-token context window on its own. Now consider the actual user request: "find where we discussed pricing with this client this year." That touches maybe forty calls. The naive tool returns forty transcripts, which is roughly 325,000 tokens. It does not fit. Not slow, not costly: impossible. So the design constraint is not the API. It is arithmetic, and it arrives before you write a single tool definition. Do the reading on the server The whole design collapses to one line: The Worker does the reading. Claude does the thinking. search_transcripts fetches the candidate transcripts, scans them inside the Worker, and returns only matching passages with speaker and timestamp attached. A real forty-meeting search, run through claude.ai against the live archive, returned 76,757 characters of excerpt: about 19,200 tokens rather than 325,000. The scanner is a pure function with no IO, which makes it trivial to test: export function scanTranscript ( text : string , queries : string [], opts : ScanOption

When Anthropic introduced the Model Context Protocol on November 25, 2024, it got everyone's eyes on it, including Christy, who was Appwrite's Engineering Lead back then. I had just started my role as an "Engineering Intern" and had no idea what a whole new protocol meant, or why it was such a big deal. Looking at the surface, I wasn't entirely wrong. MCP is JSON-RPC with a schema and a handshake stapled on. What took us sixteen months was everything stapled around it. Streamable HTTP did not exist when MCP launched. It replaced HTTP+SSE in the 2025-03-26 revision. The stdio years Christy had a working stdio server in the repo by February 26, 2025. We already had API keys, so the wiring was simple: claude mcp add appwrite \ --env APPWRITE_PROJECT_ID = <YOUR_PROJECT_ID> \ --env APPWRITE_API_KEY = <YOUR_API_KEY> \ --env APPWRITE_ENDPOINT = https://cloud.appwrite.io/v1 \ -- uvx mcp-server-appwrite An API key is scoped to exactly one project by design, so the ceiling was baked into the credential. Switching projects meant editing your editor config. Creating a project was impossible. So was anything at the organization level. The credential is the whole difference between the two transports, and everything hard about the hosted version follows from swapping it for a token that belongs to the user instead of the project. Authorization ate the schedule By the spec, authorization is genuinely optional: Authorization is OPTIONAL for MCP implementations. [...] Implementations using an HTTP-based transport SHOULD conform to this specification. For a service where one tool call can drop a database, we weren't comfortable treating it as optional. If you use Auth0 or WorkOS, this is a config screen. Appwrite keeps everything in-house, so Matej built the authorization server itself, and I built the resource server plus whatever Cloud was still missing before real clients would work. Steps 2 through 6 are the part that makes "just paste this URL" work. Nothing is pre-provisioned.

Building an AI agent locally is an exciting first step. Running that same agent reliably in production is a different challenge. Once real users and external services are involved, the application needs more than working code. It needs repeatable deployments, secure configuration, health checks, monitoring, controlled updates, and a clear recovery process. This article is part of my MCP series. If you are new to the topic, start with my first article: Model Context Protocol (MCP) Servers Explained: A Complete Beginner’s Guide . In this article, I will outline a practical architecture for taking a Model Context Protocol, or MCP-based, AI agent from a local development environment to Kubernetes. This is a production architecture blueprint. The exact implementation will depend on the AI provider, MCP servers, cloud platform, and security requirements used by the application. What Is an MCP-Based AI Agent? The Model Context Protocol provides a standardized way for AI applications to connect with external tools, services, and data sources. An MCP-based agent may interact with: Internal APIs Databases File systems Search services Monitoring platforms Business applications Custom automation tools A basic implementation might work well on a developer's machine. In production, however, every dependency introduces operational questions: How will the application be deployed? Where will credentials be stored? How will failed requests be detected? Can the service handle additional traffic? How can a broken release be rolled back? What happens when an MCP server becomes unavailable? These are familiar DevOps and Site Reliability Engineering problems applied to a new type of workload. Target Architecture A practical delivery flow could look like this: Developer ↓ GitHub Repository ↓ GitHub Actions ↓ Container Registry ↓ Kubernetes Cluster ↓ MCP Servers and External Services ↓ Logs, Metrics, Traces, and Alerts Each component has a clear responsibility: GitHub stores the application

What is MCP (Model Context Protocol)? Complete 2026 Guide TL;DR — Model Context Protocol (MCP) is an open JSON-RPC 2.0 specification, introduced by Anthropic in late 2024, that lets AI agents talk to external systems — file systems, databases, APIs, custom services — through a single standardized interface. An MCP server exposes capabilities (tools, resources, and prompts); an MCP client (Claude Desktop, Cursor, Zed, Sourcegraph Cody, your own agent) consumes them. Write the server once, and every MCP-compatible client can use it — no per-app integration work. If you have built agent tooling before, think of MCP as "LSP for AI tools" : the same idea that unified language servers across editors, now applied to the plumbing between agents and the systems they need to act on. Why MCP Exists Before MCP, every agent framework defined its own tool format. A tool written for LangChain didn’t work in Claude Desktop, which didn’t work in your custom agent, which didn’t work in Cursor. Each integration was bespoke, every prompt-engineered "function description" was framework-specific, and every team rebuilt the same wheel. The pain points MCP solves: Fragmentation. Five frameworks, five tool formats. Five times the work. No discovery. Clients couldn’t enumerate what a tool server offered without a hard-coded manifest. No portability. A debugging assistant you wrote for one agent wouldn’t move to another. Auth was ad hoc. Every integration invented its own way to handle API keys and OAuth. MCP makes the contract uniform: a server declares its tools, resources, and prompts; a client speaks the same JSON-RPC dialect to discover and call them. The same MCP server that ships with Anthropic's TypeScript SDK today will work with any future client that implements the spec, regardless of which LLM the client uses underneath. The Wire Protocol in One Page MCP rides on JSON-RPC 2.0 , which means every message is a JSON object with a jsonrpc: "2.0" envelope, a method , optional params ,

Short answer To build an MCP server: install an official MCP SDK, declare your tools with typed inputs, optionally expose resources and prompts, run the server over stdio or HTTP, then connect an MCP client like Claude and test it. A minimal Python server is about ten lines; the work is in choosing what to expose and validating every input. This is the build . For what MCP is, its three primitives, and how it differs from an API, start with what is the Model Context Protocol — this page assumes that and goes straight to code. Prerequisites You need very little to get a server running locally: A language with an official SDK. Python and TypeScript are the most mature; the same protocol is also implemented for other languages. This guide uses the Python SDK (the secondary path most people search for), with notes on where the TypeScript SDK is equivalent. Python 3.10 or newer and uv (recommended) or pip to manage the environment. An MCP client to test against — Claude Desktop, or the MCP Inspector that ships with the SDK. You do not need cloud credentials to build or run the server itself. Conceptually a server exposes three things — tools (model-callable functions), resources (readable data), and prompts (reusable templates) . The steps below add them in that order. Exact SDK signatures evolve, so treat the snippets as the current shape and check the live docs before shipping. Which spec revision this builds against. The code here targets MCP revision 2025-11-25 — the revision the spec's versioning page still names as the current protocol version. Revision 2026-07-28 is published and reworks the wire format substantially. A server built against 2025-11-25 stays conformant today; what the new revision changes for a server author is set out below, so you can build now and plan the move. Step 1: scaffold the server Create a project, install the SDK, and write the smallest server that runs. With uv : uv init weather cd weather uv venv source .venv/bin/activate # Install t

I still remember the frustration when our team's support bot, powered by LangGraph and MCP, couldn't retain context between user interactions. It was as if the bot had a case of conversational amnesia, forcing users to repeat themselves over and over. We later discovered that the issue stemmed from our lack of a centralized tooling server, making it impossible for the bot to access and leverage external tools in a scalable manner. This experience taught us the importance of building a robust MCP server to expose tools to our AI applications. In this post, we'll walk through the process of setting up an MCP server, focusing on exposing a single tool to any MCP-compatible AI app. Let's consider a simple tool that performs sentiment analysis on text input. We want this tool to be accessible from our support bot, allowing it to gauge user sentiment and respond accordingly. The first step in building an MCP server is to define the tool and its interface. MCP provides a set of APIs and protocols for tool definition, including the Tool class and the MCPTool interface. We'll use these to create our sentiment analysis tool. Here's a simplified example of how we might define this tool in Python: from MCP import Tool , MCPTool class SentimentAnalysisTool ( Tool , MCPTool ): def __init__ ( self ): super (). __init__ () self . name = " SentimentAnalysis " self . description = " Analyzes the sentiment of the input text " def execute ( self , input_text ): # Simplified sentiment analysis logic for demonstration if " love " in input_text or " great " in input_text : return " Positive " elif " hate " in input_text or " bad " in input_text : return " Negative " else : return " Neutral " # Create an instance of our tool sentiment_tool = SentimentAnalysisTool () Next, we need to set up an MCP server to host our tool. MCP servers can be configured to expose tools over various interfaces, including REST and gRPC. For simplicity, let's use a basic REST server. We'll use Flask, a lightweig

The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, for connecting AI models to the tools, data, and systems they need to be useful. The easiest way to understand it is through the metaphor most people in the space now reach for: MCP is "USB-C for AI." Before USB-C, plugging a device into a computer meant hunting for the right proprietary cable. MCP solves the equivalent problem for AI — before it existed, every AI application that wanted to talk to an external tool (a database, a calendar, a codebase, a CRM) needed a custom, one-off integration built specifically for that pairing. That sounds like a minor inconvenience until you do the math. If you have ten AI applications and a hundred tools they might each want to use, the naive approach requires up to a thousand separate integrations — and every new tool or every new AI application multiplies that number further. Integration complexity was scaling quadratically just as the number of both AI agents and business tools was exploding. MCP replaces that tangle with a single, standardized interface: a tool built to speak MCP can be plugged into any MCP-compatible AI application, and an AI application that speaks MCP can reach any MCP server, without bespoke wiring in either direction. Structurally, MCP defines a client-server relationship. An "MCP server" exposes a set of capabilities — tools it can call, data it can retrieve, prompts it can offer — through a standardized protocol. An "MCP client," typically embedded in an AI application, discovers and uses those capabilities on the model's behalf. The protocol itself has kept evolving: its governance now sits with the Linux Foundation's Agentic AI Foundation, giving it a vendor-neutral home, and a new specification — covering a more stateless protocol core, formal extensions, long-running tasks, and hardened authorization — is set to finalize in late July 2026. Why Every AI Startup Is Talking About MCP The short answer is that MC

When an AI agent runs a multi-step pipeline, every step creates temporary files. Article drafts, image uploads, JSON payloads, log files. Over fifty runs, these files accumulate. Some get cleaned up, some don't. And the ones that don't cause the next run to fail in confusing ways. I hit this exact problem with my publishing pipeline. A failed cleanup from run #12 left a stale devto_article.json in the working directory. Run #13 picked it up, parsed it, and published a draft with last week's title. The logs showed "JSON loaded successfully" — which was technically true. The file was valid JSON. It just belonged to the wrong run. The fix was a Guard class that sits between the pipeline and the filesystem. Every file the pipeline creates must be registered before the pipeline starts. Any file that appears without registration halts the pipeline immediately. Run identity gets embedded into every file, so even if a cleanup fails, the next run can tell the file doesn't belong. The Problem With Temp Files Temp files are invisible by design. You create them, use them, delete them. But when deletion fails — file lock, process crash, permission error — the file becomes a ghost. It exists on disk but nobody remembers it's there. The next run scans the directory, finds the ghost, and treats it as intentional. This is especially dangerous for JSON files because they're always valid. A stale manifest.json looks identical to a fresh one. The only difference is the content, and the loader doesn't check content provenance. Here's a concrete example from my pipeline: # The naive approach — just check if the file exists def load_manifest ( path ): if not path . exists (): return None return json . loads ( path . read_text ()) This code returns valid data from any run, any day, any context. It answers "can I read this file?" but not "should I read this file?" That distinction is the entire bug. The Guard Pattern The Guard class solves this by requiring every temp file to be registered

Everything looked perfect. I had mcporter 0.7.3 configured with the Exa MCP server: mcporter list exa # ✅ exa (2 tools) — "Search the web for any topic..." Healthy. Ready. Then I made the first real call: mcporter call "exa.web_search_exa(query: \" ollama cloud models\ ", numResults: 5)" JSON parse error at position 1. Every. Single. Time. I tried every quoting trick known to PowerShell: Backslash escaping --% stop-parsing operator cmd /c wrapper Single-quoted outer strings Same error. The shell was eating my quotes before mcporter ever saw them. This is the full story of how I debugged it, verified on Windows PowerShell 5.1 on July 31, 2026. Chapter 1: The Root Cause - PowerShell 5.1's Dirty Secret PowerShell 5.1 strips ALL embedded double-quotes at the native-argument boundary when passing args to external programs. There is no $PSNativeCommandArgumentPassing in 5.1. That is a PowerShell 7.3+ feature. So this: mcporter call --args '{"query":"test"}' Literally becomes this before Node.js even starts: { query:test } The JSON is destroyed. No shell-level trick can fix it. Stop fighting the shell. Chapter 2: The Hero - A 10-Line Node.js Spawn Wrapper The fix is to bypass the shell entirely with spawn(..., { shell: false }) . Node passes a real argv array, no re-quoting happens. Create mcporter_exa.js : // mcporter_exa.js - The hero const { spawn } = require ( ' node:child_process ' ); const args = process . argv . slice ( 2 ); // --tool <tool> <base64Json> mode, or default web_search_exa const tool = args [ 0 ] === ' --tool ' ? args [ 1 ] : ' exa.web_search_exa ' ; const payload = args [ 0 ] === ' --tool ' ? args [ 2 ] : JSON . stringify ({ query : args [ 0 ], numResults : Number ( args [ 1 ] || 5 ) }); const child = spawn ( process . execPath , [ require . resolve ( ' mcporter/dist/cli.js ' ), ' call ' , tool , ' --args ' , payload ], { shell : false , stdio : ' inherit ' }); child . on ( ' exit ' , ( code ) => process . exit ( code ?? 0 )); Usage: # Web search - que

I've been seeing news everywhere that MCP just went stateless, but I had no clue what it means. So I decided to dig into it and write a blog post about it. Stateless MCP for Beginners The Model Context Protocol (MCP) connects AI assistants to tools, databases, and external applications. In the 2026-07-28 specification revision, MCP removed protocol-level sessions and became stateless. That change makes remote MCP servers easier to operate. They can scale behind ordinary load balancers without sticky routing or a shared MCP session store. Clients can safely cache tool definitions, and agents get more control over which application resources they share. But stateless does not mean MCP servers can no longer remember anything. A browser can still have open tabs, a database transaction can still have uncommitted changes, and a shopping cart can still hold items. The difference is how the client refers to that state. Why MCP Sessions Became a Problem State is information a system remembers between requests. Imagine an MCP server that controls a web browser. An agent might call open_browser , followed by navigate , click , and take_screenshot . The server needs to know that all four actions refer to the same browser. In earlier MCP versions, the connection could provide that context. The client began with an initialize request. Under Streamable HTTP, the server could respond with an Mcp-Session-Id , which the client attached to later requests. The server could then use that ID to recover information associated with the session. This worked naturally when one client talked to one server process. It became more complicated when an MCP service ran across several machines behind a load balancer. If Server A created a session and the next request reached Server B, Server B needed some way to recover that session. Infrastructure teams typically solved this with sticky routing, which kept the client tied to Server A, or a shared database that every server could use for session lo

If you've built an MCP App — the HTML widget an MCP server hands a host to render inline — you may have hit this: the tool call succeeds, structuredContent comes back fine, the model announces that a widget rendered, and the user sees nothing. No error. No console output. Just a gap in the conversation. There's a long issue full of people with this exact symptom, all of them (me included) posting variations of "my server is spec-correct and nothing renders." That's a hard thing to act on. So I built a probe server designed to answer one question at a time and ran it 36 times. This post is mostly about method — how you experiment on a host whose source you can't read and whose renderer you can't attach a debugger to. The MCP specifics are the worked example. The most useful part is at the end, where my measurements lied to me twice. Everything behavioural here was measured on 31 July 2026 against claude.ai web. Host behaviour changes; treat the numbers as a snapshot, not a spec. The finding, up front The most-upvoted lead in that thread says claude.ai silently refuses to place the iframe unless your resource declares _meta.ui.domain , computed as sha256(<your endpoint URL>)[:32] + ".claudemcpcontent.com" . Here's what varying that one field actually does: _meta.ui.domain iframe mounted sandbox origin computed value 10/10 one stable origin, every render absent 10/10 host default — differs per conversation present but wrong 0/8 never created Omitting it doesn't stop anything. What it actually controls is origin stability , which is exactly what the SDK docs say it's for: a fixed origin your API server can allowlist for CORS. But a wrong value is fatal. And the easy way to produce one is hashing an endpoint string that differs slightly from the URL the client connected with — a trailing slash, a missing path segment, http vs https . So the advice inverts the risk: follow it imprecisely and you convert a working app into a broken one. The original comment wasn't wrong ab

A few days ago I fixed update_article , one of the tools in this repo's MCP server, because it had a nasty shape: it took a bare integer article_id , PUT whatever fields you gave it straight to the DEV.to API, and if the id was wrong or hallucinated, it would silently overwrite a live published post with nothing left behind to show it had happened. The fix added a fetch-before-write diff and a JSONL audit log: _ARTICLE_UPDATE_LOG = " logs/article_updates.jsonl " def _log_article_update ( article_id , before , fields_changed , after ): os . makedirs ( os . path . dirname ( _ARTICLE_UPDATE_LOG ), exist_ok = True ) entry = { " article_id " : article_id , " fields_changed " : sorted ( fields_changed ), " url " : after . get ( " url " )} for field in fields_changed : entry [ f " { field } _before " ] = before . get ( field ) entry [ f " { field } _after " ] = after . get ( field ) with open ( _ARTICLE_UPDATE_LOG , " a " ) as f : f . write ( json . dumps ( entry ) + " \n " ) The whole point of that function is durability. "Zero trace" was the bug; a JSONL file that records before/after state on every write was the fix. I verified the logging logic itself with an offline unit test against fake before/after states and moved on, same as the diff field. What I never checked is whether logs/article_updates.jsonl outlives the process that writes it. Checking whether the trace actually exists anywhere logs/ isn't in .gitignore — I checked, it's not there. So nothing is actively hiding it. But not-hidden isn't the same as tracked: $ git log --all --oneline -- 'logs/*' $ ls logs/ ls: cannot access 'logs/': No such file or directory Empty output from the first command, across every branch and every commit this repo has ever had (50 commits, not a shallow clone — git rev-parse --is-shallow-repository is false ). Nothing has ever touched logs/ . The directory doesn't even exist right now. Not because anything deleted it — because nothing has ever run update_article in an environment

Watching an autonomous agent run through a loop of tasks is like watching a black box try to solve a puzzle in another room. You can see the final result, but the middle part—the reasoning, the failures, and that pivotal moment where it realizes its plan was garbage—is buried in thousands of lines of unstructured logs. If you've ever deployed an agentic workflow only to check back an hour later and find it has been stuck in a high-latency loop of 'I made a mistake... let me try again' for forty minutes, you know the pain. You didn't have failure; you had expensive, silent repetition. The problem with current LLM observability is that we focus too much on the input and output (the traces) and not enough on the internal state transitions of the agent itself. We need to quantify how often an agent is actually self-correcting versus just spinning its wheels. I recently started working with a specific tool designed for this exact visibility gap: the Agent Self-Reflection & Sentiment Scanner . The Observability Gap in Agentic Loops When we talk about 'agents,' we're usually talking about a loop: Observe, Think, Act, Repeat. In a perfect world, the 'Think' step includes self-correction. If an action fails (e.g., a 403 error from an API), the agent should reflect on that failure and adjust its next move. But how do you measure if your agent is actually getting better during a session? How do you distinguish between an agent that is 'Proceeding' with confidence and one that is in a state of constant 'Correction'? You can't just look at the final success/fail status. You need to parse the execution logs for deterministic markers. Why Deterministic Matching Wins Over LLM-Based Analysis The temptation here would be to pipe your agent logs into another, even larger LLM and ask, 'Is this agent struggling?' Don't do that. It’s redundant, it’s slow, and if you're running high-volume loops, the cost will kill your margin. You've already paid for the primary reasoning engine; don't p

There is a number going around that roughly half of all remote MCP servers are dead. I had repeated it myself, in the README of a tool I published. I could not find where it came from, so I measured it. The answer is that about one in ten is actually broken. The "half" figure appears to come from counting servers that require an API key as if they were down. Here is the method and the full breakdown. What I measured On 29 July 2026 I pulled every entry from the official MCP registry — 1,200 servers. Of those, 297 had status: active and advertised a remote endpoint URL (the rest are stdio/local packages with nothing to probe over the network). Each got one anonymous JSON-RPC initialize over streamable HTTP, with a 10 second timeout: { "jsonrpc" : "2.0" , "id" : 1 , "method" : "initialize" , "params" : { "protocolVersion" : "2025-06-18" , "capabilities" : {}, "clientInfo" : { "name" : "mcp-uptime" , "version" : "0.1.0" } } } Then I classified the response: a valid result containing protocolVersion or serverInfo is up, 401/403 is auth-gated, and everything else got bucketed by its actual failure. Results (n = 297) Result Count Share Completed an MCP handshake 133 44.8% Auth-gated (401/403) 134 45.1% DNS failure 8 2.7% Server error (5xx) 6 2.0% Not found (404/410) 5 1.7% Redirect (307/308) 4 1.3% Timeout 2 0.7% Non-MCP response 2 0.7% Other (400, 405, connection) 3 1.0% Reachable: 267 (89.9%). Genuinely broken: 30 (10.1%). Where "half are dead" comes from Look at the first two rows. 55.2% of these endpoints will not complete an anonymous handshake — and that is suspiciously close to the number people quote. But 134 of those 164 are returning a clean 401 or 403. They are running. They are answering. They want an API key, which is a completely reasonable thing for a hosted service to want. Counting those as dead inflates the failure rate by roughly five times. This matters beyond pedantry: if you believe half the ecosystem is rubble, you build defensively against the wron

A short case study from my "building and testing MCP agents" series — it stands on its own, but the method behind it is laid out in https://dev.to/langensjonathan/the-parameters-that-actually-matter-when-youre-tuning-an-ai-agent-2agd . TL;DR: I benchmarked two agents that are identical except for one thing — how many MCP servers they're connected to — on the exact same question. Both got the right answer, both called the same single tool. The one with more MCP servers attached still cost 28% more per question , purely from the extra tool schemas the model has to be told about on every single call, whether it uses them or not. The setup MAVERIK is my open-source MCP test bench: define a suite of questions with pass criteria, run it against one or more agent configurations, and compare the results on hard numbers. This post is one deliberately tiny experiment with it: change exactly one thing about an agent, hold everything else fixed, and see what the numbers attribute to that one change. I have a small "GitHub summarizer" agent: one system prompt, one job — answer questions about my GitHub account by calling the GitHub MCP server . I duplicated its configuration (MAVERIK supports this directly — same model, same prompt, same everything) and changed one field on the copy: the set of attached MCP servers, adding deepwiki , microsoft-learn , and context7 . Neither agent needs any of those three for the question I was about to ask; they were attached because that's what the "kitchen sink" version of this agent had accumulated over a few sessions of general-purpose use. Then I wrote the simplest possible test suite — one question: "How many repositories do I have?" with a contains criterion checking the answer includes the correct count. No judge model, no subjectivity — it either says the right number or it doesn't. I ran both agents against it, 2 repetitions each, same model ( claude-haiku ) for both, and pulled up MAVERIK's Agent Comparison report. Agent A — github on

A common MCP setup carries auth the same way: create an API key, paste it into mcp.json or an .env file, restart the client. It works. Now the key sits in plaintext on every machine that runs the agent. It often carries one broad, fixed permission set. Every agent that reads the file gets the same set. And when one agent misbehaves, the fix is rotate the shared key everywhere. There's a second failure that arrives after you add real auth: the agent calls a tool and gets a bare 403. The user doesn't know what to approve. The agent doesn't know what to ask for. Somebody ends up reading server logs. I build multiuser AI systems for production. My agents act on users' Gmail and Slack accounts every day - external agents like Claude Code included. None of those agents receives a provider token. This is the auth chain that makes that work, including the part that took the most design: what happens when consent is missing at call time. A URL instead of a key An external agent doesn't get the Gmail or Slack credential. It gets a URL - a managed MCP endpoint my platform exposes. I call that endpoint the door, and so does the interface further down. Claude Code connects to the door as an OAuth client. Dynamic client registration (DCR) registers its client identity against a configured redirect allowlist. The user signs in and approves the maximum this connection may be granted. The OAuth exchange returns a scoped KDCube bearer tied to that client and grant, not a provider token. The approval screen also resolves those requested capabilities to the accounts behind them. If a required provider is not connected, it is named there with a connect link. The connect step already says what to add - the same shape as the call-time denial later in this post, moved to the front. Approve it, and the connection becomes a card. That card is the whole governance relationship. Nobody registered Claude by hand, and nobody pasted a provider token. The checklist is a ceiling: the most this app

Eighteen months ago, MCP was the thing. Every demo and chatbot connector was running on MCP under the...

Every MCP server I've read that wraps a third-party REST API has the same shape: someone picked fifteen or twenty endpoints that seemed useful, hand-wrote a Zod schema for each, and shipped it. That works for about three months. Then the API adds a field, deprecates an enum value, renames a query parameter. The wrapper doesn't notice, because nothing in it is connected to the API's own description of itself. The schemas drift. The model starts getting rejected by the upstream API for reasons it can't see, and you get to debug an LLM guessing at a shape that stopped being true in February. The other failure is quieter. You need endpoint twenty-one — the one about persistent disks, or scaling, or environment groups — and the author skipped it. Now you're back to curl , except the agent is holding half the context and you're holding the other half. I wanted neither, so I built render-useful-mcp : an MCP server for Render where every API tool is generated from Render's own OpenAPI document. All 207 endpoints, no curation. The generating part took a weekend. Everything after that was the actual work. Make the generator refuse to guess The tempting way to write a spec-to-tools generator is to make it forgiving. Skip what you can't parse, fall back to { type: "object" } when a $ref gets hairy, log a warning and move on. You get 207 tools on the first run and feel great. You also get tools that lie. A parameter typed as a free-form object when the API actually wants one of four enum values is worse than no tool at all — the model will confidently produce garbage, and the failure surfaces three layers away from the cause. So the generator is fail-closed. It aborts the build, loudly, on: An operation whose tag doesn't map to a known toolset. Render added a resource category and I haven't classified it yet. That's my problem to solve, not something to paper over. A tool name collision. Two operations deriving the same name means my naming scheme is wrong. A cyclic $ref it can'

This article presents a defense-in-depth approach for securing Model Context Protocol (MCP) deployments in production. It outlines four architectural control layers: safe execution, management infrastructure, outbound trust, and semantic integrity, arguing that production security requires enforcement beyond the gateway at the earliest trustworthy control points. By Nik Kale