标签：#mcp

Every team I've worked with has unwritten rules — who to ask before touching auth, which decisions are settled, what "in progress" actually means. They used to travel by osmosis. Once everyone on the team is coding with an agent, osmosis stops working, because half the conversation now happens in someone's private session. This is the one-page agreement we ended up writing down, and why each clause is in it. When every developer on a team codes with an AI agent, one of the first things to break down can be the unwritten rules. Small, shared assumptions that once traveled through everyday conversation ("ask before you touch auth," "we decided on v2 last week") may not reach a teammate's private session — let alone the agent working in it. The established fix for that is a working agreement : a short, explicit set of norms a team writes for itself. This one is designed for AI-assisted teams — a page you can copy, adapt, and keep somewhere every teammate can access and every agent is configured to read. What a working agreement is — and isn't A working agreement is a team norm, written by the team, kept short, and revised as you learn. It is not a tool, and not a policy handed down from above. It doesn't enforce anything — it aligns behavior. That's precisely why it survives across whatever mix of editors and agents your team actually uses: it lives at the human layer, above any one tool. If you've run agile ceremonies, you've seen these before. What's new is that agents now perform part of the work, so a few assumptions that people may have absorbed implicitly need to be written down. Accountability still stays with people. The template Copy this, cut what doesn't fit, and fill in the blanks. Keep it to a page. # Our AI Coding Working Agreement (v1) ## 1. Shared decisions - Decisions that affect others live in: ______ (a shared memory, a decisions doc). - Before a decision affects someone else's work, we record who decided it, what changed, and why. ## 2. Declaring wo

Cloudflare announced a developer preview that lets any website enable a WebMCP (Web Model Context Protocol) interface with a single dashboard switch. This allows browser-based AI agents to interact with unmodified web pages through structured tools instead of scraping or guessing, keeping human traffic and control on the original site. By Sergio De Simone

I remember the old days of manual scaling. You'd jump into a CLI, check your metrics, realize you needed another node or a capacity adjustment, log into a web console, navigate three layers deep into some proprietary dashboard, and hope you didn't click the wrong thing while trying to find a specific cluster ID. Now we have AI agents. But most people are using them wrong. They treat Claude or Cursor as just better search engines for code, rather than giving them hands. If you're running high-availability workloads on something like TiDB Cloud, the friction isn't in writing the SQL—you already know how to do that. The friction is in the operational visibility: knowing exactly what’s happening across your serverless instances versus your dedicated clusters without leaving your IDE. The Gap Between Code and Infrastructure The reason I spend so much time building things like MCPFusion is precisely because of this disconnect. An LLM might help you write a complex join perfectly, but if it doesn't know whether the target TiDB X instance is actually healthy or which project ID handles your staging environment, it's basically flying blind. You end up copy-pasting JSON blobs from your terminal into the chat window just to give the model context. That's slow, prone to error, and frankly, beneath what modern tooling should look like. This is why we released the TiDB Cloud (Serverless Distributed SQL) MCP server on Vinkius. It closes that loop. What This Actually Does (And Doesn't) Let's be very clear about what this tool allows you to do through an agent like Claude or Cursor. We aren't looking for "magic" here; we want predictable utility. The current implementation focuses on discovery and inspection. In DevOps terms, it provides a controlled read-only view of your topology. Here is what's available: Organization Discovery: You can call list_projects to see everything sitting under your umbrella and pull metadata via get_project . This solves the "what was that project ID ag

Abstract In recent AI Agent engineering practice, many development teams are shifting away from the Model Context Protocol (MCP) and adopting CLI‑based tool invocation patterns. This shift does not represent technological regression. Instead, it reflects pragmatic engineering choices balancing protocol standardization, operational overhead, token consumption and debugging efficiency. This article analyzes the core design philosophy of MCP, exposes four real‑world pain points observed in production deployments, and outlines the practical strengths of CLI‑driven tool execution. Benchmark measurement data is retained for quantitative comparison. This paper also provides structured decision‑making dimensions for technology selection, introduces hybrid architecture as the optimal production‑grade solution, and summarizes actionable engineering recommendations. For multi‑model and multi‑tool request routing scenarios, developers can leverage 4sapi as an API gateway to unify backend traffic management. 1. Introduction As AI Agent systems move from prototype demos to real‑world business deployment, tool calling infrastructure has become a critical determinant of overall system stability. Released by Anthropic, the Model Context Protocol (MCP) quickly gained community attention as a standardized JSON‑RPC 2.0 protocol for AI models to discover, describe and invoke external tools. Despite its promising theoretical positioning, many engineering teams have gradually backed away from full‑scale MCP adoption and turned toward invoking native command‑line interfaces. This article avoids simplistic pros‑and‑cons comparison. It dissects ideal‑world protocol design against real‑world production constraints, helping engineers make rational tool‑chain architecture decisions for their Agent projects. 2. MCP Design Philosophy and Ideal‑World Capabilities MCP is built for standardized interoperability between AI agent clients and external tool servers. It defines complete JSON‑RPC 2.0 mess

MCP (Model Context Protocol) is how AI agents connect to tools. Claude Desktop uses it, Cursor uses it, and thousands of developers are building MCP servers to give AI access to their APIs, databases, and infrastructure. There's one problem: MCP has no security model. The protocol defines how a client talks to a server, but says nothing about what that server is allowed to do. No authentication between client and server. No authorization on which tools can be called. No audit trail of what happened. The spec assumes you'll handle all of that yourself. Most people don't. What Actually Goes Wrong I run a self-hosted server with Prometheus, Grafana, Ollama, Gitea, and a handful of other services. I wanted Claude Desktop to query all of them through MCP. The standard approach is to write a Python FastMCP server for each one — a few dozen lines per service, hardcode the API key, register the tools, done. That works until you think about what you've actually built: Every MCP server has full access to whatever its process can reach. Your Prometheus tool can also hit your Grafana API, your Gitea API, and anything else on localhost. There's no scoping. API keys live in environment variables or config files. If you have 9 MCP servers, you have 9 places where credentials sit in plaintext with no access policy. Nothing is logged. If Claude calls a tool that restarts a service or deletes data, there's no record of which tool was called, with what parameters, by which agent, at what time. There's no concept of read-only vs. write. A tool either exists or it doesn't. MCP doesn't know that query_prometheus is safe to call freely but restart_service should require approval. Tool composition creates emergent risks. When Claude has access to multiple MCP servers, it can chain calls across them. Server A reads sensitive data, Server B posts to an external API — Claude could combine them in ways neither server was designed for. These aren't theoretical risks. During development, I decla

When building Model Context Protocol (MCP) servers or AI agents that consume them, traditional API testing tools fall short. An MCP server isn't just a basic REST endpoint—it's a dynamic interface exposed to non-deterministic LLMs through stdio, HTTP, or SSE transports. Testing tool schemas, transient network failures, and agent behaviors usually requires writing a mountain of boilerplate. I built bubblemcp-test-kit to eliminate that friction: no backend accounts, no complex test setup, and zero instrumentation required. What is bubblemcp-test-kit? bubblemcp-test-kit is a lightweight, standalone testing toolkit designed specifically for MCP server developers and AI agent engineers. Key features include: Transport Agnostic: Work with stdio, HTTP, or SSE behind a unified API. Fluent Assertions: Native matchers tailored for MCP response structures and JSON Schemas. Mocking & Replay: Fabricate tool outputs locally or record real server runs to replay in offline CI environments. Agent Trace & Fault Injection: Test if your AI agent calls tools in the right order and handles errors properly. Quickstart Example You can run a complete mock test suite without spinning up a live server: import { createMockMcpClient , expectMcp , validateAgainstSchema , withRecording , createReplayClient , } from ' bubblemcp-test-kit ' // 1. Define your tool contract const healthCheckTool = { name : ' health_check ' , description : ' Reports service health ' , inputSchema : { type : ' object ' , properties : { service : { type : ' string ' } }, required : [ ' service ' ], }, outputSchema : { type : ' object ' , properties : { service : { type : ' string ' }, status : { type : ' string ' , enum : [ ' ok ' , ' degraded ' , ' down ' ] }, latencyMs : { type : ' number ' }, }, required : [ ' service ' , ' status ' , ' latencyMs ' ], }, } // 2. Set up a mock MCP client const mock = createMockMcpClient ({ tools : [ healthCheckTool ] }) mock . mockTool ( ' health_check ' ). resolves ({ service : ' weat

Inside the NEXUS AI App Builder: an agentic full-stack workspace, not a code generator Published: August 4, 2026 Category: AI Builder Reading time: 11 minutes Author: NEXUS AI Team Most "AI app builders" do one thing well: turn a prompt into a first draft. Ask for a second change, a real database, or a form that actually submits, and the illusion breaks. You are back in a normal editor, debugging code nobody on your team wrote. The NEXUS AI App Builder is built around a different assumption: the first draft is the easy part. The workspace has to survive edit five, edit fifty, a broken build, a schema change, and a handoff to a teammate or another AI agent, without you ever leaving the conversation. This post walks through how the Builder actually works: the agentic edit loop, the two ways to preview a change, visual iteration, sharing and remixing, the MCP handoff that lets coding agents use it directly, and how a Builder project becomes a deployed production app. What most AI builders actually give you Tool type Generates Stops short of One-shot text-to-code A first draft from a single prompt Verifying it runs, fixing its own errors, a second coherent edit Chat-based code snippets Functions and components you copy in Anything outside the snippet: routing, schema, deployment Visual UI builders A styled interface Real backend logic, a database, form submission that persists data NEXUS AI App Builder A real Next.js and Prisma app, verified, previewed, shareable, deployable Nothing on this list. It is the full loop, in one workspace. The pattern in the first three rows is the same: something hands you code, then the responsibility for making it actually work lands back on you. The Builder is built to keep that responsibility on the agent for as long as possible. It edits files and verifies its own work The Builder is not a single prompt-to-code call. It is an agent with bounded file tools that reads and edits your actual project files, the same way a developer would. Y

I have a small script, reply_comments.py , that pulls unanswered comments off my DEV.to articles and drafts replies to a markdown file so I can paste them in by hand. The API doesn't let a normal account post comments (that's its own bug I've written about before), so this draft-then-paste loop is the whole workflow. Every reply I've ever sent has come from reading the body field this script prints. Today I went looking for a bug distinct from everything already logged for this repo, and I ended up re-reading strip_html() , the function that turns a comment's raw body_html into the plain text I actually read: def strip_html ( h ): return re . sub ( r " \s+ " , " " , re . sub ( r " <[^>]+> " , " " , h )). strip () It does exactly one thing: strip HTML tags with a regex, then collapse whitespace. It's been in the file since the script was written and nobody had audited it on its own — every prior pass through this pipeline was about pagination, thread-depth walking, or dedup keys, never the text-extraction step itself. Here's the problem. DEV.to's API returns body_html as rendered HTML. A correct renderer has to HTML-entity-escape a commenter's own literal < , > , & , and quote characters, or they'd get mistaken for markup. So a comment that reads, in plain English: isn't it faster with a Q&A cache? Try List instead. comes back from the API as something like: <p> isn &#39; t it faster with a Q &amp; A cache? Try List &lt; String &gt; instead. </p> strip_html() 's regex only ever targets <[^>]+> — actual tags. It has no idea what to do with &#39; , &amp; , &lt; , &gt; . Those aren't tags, so the regex leaves them untouched. The whitespace collapse doesn't touch them either. What comes out the other end, into the exact field I read to draft a reply, is: isn&#39;t it faster with a Q&amp;A cache? Try List&lt;String&gt; instead. That's not a cosmetic nit. On a dev-focused comment section, & , < , and > show up constantly — generics, comparisons, "foo & bar," code snippets

A year ago, connecting a model to your tools meant writing glue for that model , in that framework , with that vendor's function-calling format. Swap the model and you rewrote the glue. In 2026, that pain is mostly gone, and the reason has a boring name: the Model Context Protocol (MCP) . MCP is worth understanding not because it's clever, but because it's winning — and the reason it's winning tells you where the industry's center of gravity is moving. What MCP actually is Strip away the branding and MCP is a small client–server contract for connecting language models to the outside world. A server exposes three kinds of things: tools (functions the model can call), resources (data the model can read), and prompts (reusable templates). A client — your IDE, your agent, your chat app — speaks the same protocol and can talk to any compliant server. The analogy people keep reaching for is USB-C, and it's accurate. Before USB-C you had a drawer full of proprietary chargers. MCP is the drawer-emptying moment for AI integrations: write the connector once, and any MCP-aware client can use it. Why "model-agnostic" is the whole point Here's the shift that matters. For most of the LLM era, your tooling was coupled to a model . If you built your agent stack around one vendor's function-calling quirks, you were locked in — a new, better model meant a migration project. MCP decouples the tooling layer from the model layer. Your filesystem server, your database server, your ticketing-system server don't know or care which model is on the other end. When a new flagship drops — and in 2026 they drop every few weeks — you point your client at it and keep your entire tool ecosystem intact. That's a strategic hedge, not just a convenience. In a market where the "best model" changes monthly, the durable asset is your integration layer , and MCP is how you stop rebuilding it. What to build with it Practical entry points, cheapest first: Wrap an internal system as a server. Your team's de

The bug that isn't a bug On Tuesday you attach a dead-letter queue to orders-queue . On Wednesday a batch of messages disappears and you ask Claude Code what happened. It answers immediately: orders-queue has no DLQ configured, so failed messages are dropped after the maximum receive count. That answer is wrong, and it is also not a hallucination. The assistant read a real snapshot of your AWS account. The snapshot was taken Monday. This is the failure mode that shows up once you give an AI assistant deterministic infrastructure context instead of letting it guess. Guessing produces answers that feel uncertain, and you treat them accordingly. A stale snapshot produces answers that feel authoritative, with real table names, real queue names, real ARNs. Nothing in the response signals that the underlying facts expired. Infrawise extracts your DynamoDB tables, Lambda configs, queue settings, database schemas, and code-to-table access patterns into a graph, then serves that graph to AI editors over MCP. Everything below is about the part nobody asks for in a feature list: what happens to that graph when it gets old. Why the context has to be cached at all The obvious fix is to never cache. Answer every question from a live account read. That does not survive contact with an actual session. A full infrawise analyze walks every enabled service, paginating through DynamoDB DescribeTable , Lambda configurations and their event source mappings, SQS queue attributes, SNS subscriptions and filter policies, Secrets Manager rotation state, S3 versioning and public-access configuration, ElastiCache clusters, CloudWatch log groups, plus schema introspection against Postgres, MySQL, or MongoDB, plus a local IaC parse, plus an AST scan of the repository. Every extractor is dispatched through a single Promise.all , so wall-clock time is bounded by the slowest one rather than their sum, but it is still seconds, not milliseconds. An assistant calls get_infra_overview at the start of a

If you’ve been building with Claude or Cursor for the last year, you’ve noticed a pattern. The code comes out clean. The logic is sound. But the interfaces? They look like 2015-era Bootstrap clones. Everything has the same rounded corners, arbitrary shadows that don't communicate depth, and linear animations that feel robotic rather than organic. AI agents are incredible at generating functional HTML and CSS, but they lack a fundamental concept: design intent. They can write the code to make a button blue, but they struggle to understand why that button needs a specific spring-based scale effect when pressed, or how its elevation should change relative to the background surface. They produce 'zombie' interfaces—functional, but lifeless and fundamentally broken for high-end production use. This isn't just an aesthetic problem; it’s a technical one involving accessibility, usability, and user agency. I recently started using something called the UI/UX Excellence Prover via Vinkius to close this gap. It doesn't generate code—that's not its job. Instead, it acts as a design unit test for your agentic pipeline. You aren't asking it to 'make it look better'; you are asking it to validate that the generated component meets 2026-era standards across six specific pillars. The Death of Flat Decoration The first thing I noticed in most AI-generated layouts is what I call "flat decoration." Agents love using box-shadow as an ornament. They'll add a shadow to every card just because it looks 'modern.' But shadows aren't decorations; they are spatial communication tools. A properly engineered interface uses elevation (levels 0 through 5) to communicate hierarchy. Level 0 is your base surface. Level 3 might be a modal overlay that physically sits closer to the user in Z-space. If everything has a shadow, nothing has importance. When you run an agent's output through the Prover ( UI/UX Excellence Prover ), it flags these arbitrary shadows. It forces the agent to define elevation se

There's an argument running about MCP right now. You've probably seen it: a 400-point thread called "MCP is dead?" with real token numbers in it, four connected servers eating 21,077 tokens of context before anyone asks a question. The argument is about what MCP costs. Almost nobody in it has measured what agents actually do with the data a tool returns. I ended up measuring that, not because I planned to, but because a maintainer refused to let me guess. The question nobody wanted to answer with opinions I contribute to CNCF Jaeger's MCP server. Last April I proposed exposing service performance metrics (latencies, call rates, error rates) as an MCP tool, and hit an immediate design fork: what shape should the output be? Option one, summary rows: pre-aggregated stats per service, compact, cheap. Option two, per-bucket time series: the raw points, roughly 720 of them per service at default resolution, expensive but complete. I asked which the maintainer preferred. The answer, verbatim, from the issue thread: This type of decision should not be based on opinion, but on benchmarks with a real agent troubleshooting some issues and using this MCP tool to access metrics, where you could do A/B testing of different output formats. Fair. So I built the A/B. The setup Everything below is public in jaeger-mcp-bench , including the harness, the tasks, the scorer, and a research log of everything that went wrong. The fixture is Jaeger v2 with the spanmetrics connector, hotrod generating traffic, and Prometheus behind it, snapshotted so every run sees identical metric state. In front of the metrics API sits a thin bench server with exactly one switch: --format=summary|series . No new semantics, just the shape of what comes back. Six troubleshooting tasks, and this part matters: three were chosen because I predicted summary would win them (point questions: current latency, ranking, threshold checks) and three because I predicted series would win (temporal questions: spike detect

Instacart introduced Blueberry, an AI-assisted incident response system that helps on-call engineers investigate production issues faster. It combines AI agents, operational data, and historical incident knowledge to generate grounded root cause hypotheses in Slack. It uses parallel subagents, MCP integrations, and incident history to reduce investigation time while keeping engineers in control. By Leela Kumili

Microsoft released a dedicated AI Gateway tier of Azure API Management in public preview, with a control plane built around models, MCP servers and tools rather than APIs. It fronts Foundry, Bedrock, Vertex AI and OpenAI behind one endpoint, with policy cards instead of XML. Architects welcomed the consolidation while questioning where the governance boundary sits. By Steef-Jan Wiggers

The Hidden Security Gap in Multi-Tenant MCP Servers When you build a multi-tenant SaaS application or an MCP (Model Context Protocol) server that serves multiple organizations, cross-tenant data leakage is one of the most dangerous vulnerabilities you can ship. A single missing organizationId filter in a database query can expose one tenant's data to another — and traditional security scanners like Snyk, Semgrep, and CodeQL don't catch these patterns. That's why I built mcp-tenant-isolation — a static analysis scanner with 57 deterministic rules specifically designed to catch tenant isolation failures in multi-tenant codebases. What Is Tenant Isolation? Tenant isolation ensures that data belonging to one organization (tenant) is never accessible to another. In a multi-tenant SaaS app, every database query, cache read, and file access must be scoped to the current tenant's organizationId . The most common failure looks like this: // VULNERABLE: No organizationId filter const users = await prisma . user . findMany ({ where : { role : ' admin ' } }); // SECURE: Tenant-scoped query const users = await prisma . user . findMany ({ where : { role : ' admin ' , organizationId : ctx . orgId } }); It looks obvious in isolation. But in a codebase with 100+ API routes, dozens of lib functions, and complex middleware chains, missing tenant filters are easy to miss in code review and impossible for traditional SAST tools to detect . Why Traditional Scanners Miss This Tools like Snyk and Semgrep are excellent at detecting: SQL injection XSS Dependency vulnerabilities Secret leakage But they don't understand tenant context . They don't know that organizationId is the tenant boundary. They don't track which functions require tenant guards. They can't tell you that prisma.user.findMany({ where: { role: 'admin' } }) is missing a critical tenant filter. mcp-tenant-isolation fills this gap with 57 rules across 7 categories: Rule Categories Category Rules What It Detects Database Queries

Okay, story time. If you've worked on a full stack app where the backend is Java/Spring Boot and the frontend is React, you know the drill. Someone changes something on one side of a contract and nobody tells the other side. Weeks later you're playing detective across five files trying to figure out who calls what. And it's not just REST endpoints. It's the scheduled job that quietly writes to the same table your API touches. It's the service that calls another service, which calls another service. It's the Kafka event your controller publishes that some completely unrelated listener is consuming three modules away. All of that is "the contract" too, it's just invisible unless you go looking for it. Now add AI coding agents into that picture. They're great at writing code in the file they're looking at. They're not great at knowing that the component they're editing calls an endpoint, which hits a controller, which calls a service, which calls a repository, which is also written to by a scheduled job at 2am, which also fires an event three other services are listening for. Agents see one file at a time. So they'll happily rename a field or change a return shape on one side and leave everything downstream of it completely unaware anything changed. I got burned by this enough times that I decided to build the map myself. That's how Contour happened, and then, once I realized AI agents needed to query that map directly instead of just reading it off my screen, Contour MCP happened right after. Let's get into it. The actual problem Working across a UI, a REST API, a service layer, a repository layer, a database, plus schedulers and events sitting on top of all of it, two things go wrong constantly. Agents (and honestly, humans too) edit one side of a flow without knowing the other side exists. People burn real time reconstructing a call chain by hand, jumping through five or six files just to make a change that should be simple. Both come from the same root cause. Nobod

Exactly a year ago we released SurrealMCP, a server you had to install and run in order to connect...

Almost every tool-governance layer I have looked at writes its log after the call returns. Some write it in a finally . Some batch it. Some hand it to a logging framework that flushes on its own schedule. That ordering quietly decides what your log can be used for. If the record is written after the body runs, then a record that is missing has two possible explanations, and nothing in the file distinguishes them: The call was never authorised, so it never ran. The call was authorised, ran, did its work, and the process died before the log line reached disk. Those are not close together. One is the control working. The other is an unlogged deletion. When someone asks you six weeks later what your agent was permitted to do at 03:14, "there is no line for it" answers nothing. So I wrote a small library that inverts the order. obstat obstat is an auditable decision record for agent tool calls. Nihil obstat — nothing stands in the way — was the formal clearance a censor granted in writing, before publication . That is the whole idea. from obstat import guard @guard ( resource = " doc:{doc_id} " ) def delete_document ( doc_id : str ) -> str : ... An agent asks to do something, a rule decides, and the decision goes to disk — written and fsync ed — before the tool body executes. If the process dies mid-call, the record still says what was authorised, for whom, against which resource, and why. record.decision() returns only after the fsync returns. Not flushed after, not deferred, not batched. Everything else in the library is convenience; this is the part an examiner relies on. The claim has a test, not a paragraph An architectural promise nobody can falsify is marketing. This one is checked by reading the log from inside the tool body — the one place where anything buffered, deferred, or written afterwards is invisible: def test_record_is_durable_before_the_body_runs ( workspace ): workspace ( ALLOW_ALL ) seen : dict [ str , list ] = {} @guard () def read_thing ( what : st

Introduction Artificial Intelligence has evolved far beyond answering questions and generating code. Modern AI systems can search databases, interact with APIs, read files, execute commands, access cloud services, and even coordinate multiple tools to complete complex tasks. This shift has given rise to AI agents - systems that don't just generate responses but can actively perform work on behalf of users. However, enabling an AI model to interact with external tools introduces a challenge. Every application, service, and API exposes its capabilities differently. Without a common standard, every AI platform would need custom integrations for every tool it wanted to support. This is where the Model Context Protocol (MCP) comes in. MCP provides a standard way for AI models to discover, understand, and use external tools, data sources, and services. Instead of building separate integrations for each AI model and every application, developers can expose capabilities through a common protocol that different AI clients can understand. In this article, we'll explore what MCP is, why it matters, how it works, and how it's changing the way developers build AI-powered applications. The Problem Before MCP Imagine you're building an AI assistant that needs to interact with: GitHub Slack Google Drive PostgreSQL Jira Notion Local files Internal company APIs Without a shared protocol, every integration becomes a custom implementation. For each tool, you need to define: Authentication API endpoints Request formats Response parsing Error handling Documentation Now imagine supporting multiple AI models. Every model may require different integration logic, increasing development effort and maintenance costs. This creates unnecessary complexity. What Is MCP? At its core, the Model Context Protocol (MCP) is a communication standard between AI models and external systems. Instead of hardcoding every integration, MCP defines a consistent way for an AI client to: Discover available tools U

I maintain an MCP server that generates music. One call takes anywhere from 40 seconds to three minutes, because there is a model rendering audio on the other end. That does not fit the shape MCP tools are usually written in: call it, get an answer, move on. Everything about the transport assumes the answer is close by. It is worth writing down what actually breaks when it isn't, because "my tool is slow" turns out to be three separate problems wearing one coat. What breaks The obvious first version is a single tool that kicks off the job and awaits the result. server . registerTool ( ' generate_music ' , { /* ... */ }, async ( args ) => { const task = await lacuna . music . generations . create ( args ) const done = await waitUntilReady ( task . id ) // three minutes later return { content : [{ type : ' text ' , text : JSON . stringify ( done ) }] } }) 1. You do not own the timeout. The MCP client does. Claude Desktop, Claude Code, Cursor and the rest each pick their own tool-call deadline, and none of them ask you what yours is. A tool that usually returns in 90 seconds and occasionally takes 200 will work on your machine and fail on someone else's, which is the worst possible failure distribution to debug. 2. If you hand the polling to the model, the model quits. The obvious fix is to return a pending task immediately and expose a get_generation tool so the agent can check on it. The agent will check on it. Twice. Maybe three times. Then it decides the job is wedged and tells the user "this seems to be taking a while, would you like me to keep checking?" — which is a reasonable thing for a helpful assistant to say and a terrible thing for a job that had 40 seconds left. You have converted a slow tool into an unreliable one. 3. Polling burns the context window. Every poll puts a full task object back in the transcript. Twenty polls of a JSON blob is real budget, spent entirely on the word pending . Three tools instead of one What ended up working is splitting the