How Fast Should an MCP Tool Call Be?

How Fast Should an MCP Tool Call Be?

There is no number in the Model Context Protocol specification that says a tool call must finish in under a set number of milliseconds.

What exists instead is a set of default timeouts buried in each SDK, and those defaults are what actually determine whether your agent feels responsive or hangs.

The practical question a developer building an MCP server needs answered is not "what does the spec require" but "what will silently fail on me, and when."

That answer differs by SDK, by client, and by whether your call sits on the interactive hot path or runs in the background- the same question anyone building on Wati's MCP server has to answer for their own WhatsApp tools.

In this guide, we cover the real timeout defaults across the TypeScript and Python SDKs and Claude Desktop, what counts as "fast enough" for a hot-path versus a background call, and why chained tool calls compound latency faster than a single call would suggest.

What "Fast Enough" Actually Means

Forget a single number and think in three bands, depending on where the call sits in the user's workflow.

Hot-path interactive calls, the ones a person is actively waiting on mid-conversation, should aim for 200ms and treat 1 second at the 95th percentile as the real target. Normal interactive calls can run 1 to 5 seconds without harming the experience, as long as the interface signals that work is happening rather than sitting silently.

Anything past roughly 5 seconds needs progress updates, and anything approaching the client's configured timeout needs either a longer explicit timeout or a move to an asynchronous task pattern with polling.

None of these bands comes from a formal MCP performance requirement. They come from how people experience waiting on a call, and from the practical ceiling set by client-side timeouts. Sixty seconds appears in SDK defaults constantly, but it should never be treated as a target: it marks where things fail, not where they should land.

The Timeout Defaults You're Actually Building Against

Every layer between the model and your server carries its own default, and the shortest one in the path wins.

Sources: MCP progress and cancellation specification, TypeScript SDK protocol source, Python SDK transport docs, and a reported Claude Desktop execution limit.

The habit worth building is to check the host, not only the SDK. A server-side timeout increase is wasted effort if the client you're targeting has its own shorter cutoff that fires first.

Use Progress Notifications for Long-Running Calls

MCP lets a server send notifications/progress while a long call runs, tied to a progressToken the client supplied in the request. This tells the client "work is still happening," and in principle, it can be used to reset the timeout clock.

In practice, that reset is opt-in and often off. The TypeScript SDK defaults resetTimeoutOnProgress to false, so unless a developer explicitly turns it on and the server emits regular updates, progress notifications do nothing to extend the deadline.

Even when it is enabled, maxTotalTimeout should be set as a hard wall-clock cap so progress cannot stretch a call indefinitely. Treat progress as reassurance that a call is alive, and treat cancellation plus an async task handle as the real mechanism for work that legitimately outlives a single request.

Why Chained Tool Calls Feel Much Slower Than They Should

A single tool call rarely tells the real story. Most agent workflows chain several calls together, and the user-perceived total is roughly the sum of tool execution time, MCP transport and serialization overhead, and the model's own reasoning between calls, plus any retries.

That transport overhead is small per call, but it compounds. One 2026 comparison put MCP overhead at 50 to 150ms per call against roughly 20 to 50ms for a direct cached HTTP request.

Across ten serially dependent calls, even the smaller figure adds half a second to a second and a half, before model inference is counted at all. The same dynamic shows up at batch scale: one comparison logged about 50 seconds to pull 500 records via a direct API, compared with roughly 25 minutes for the same workload run through chained MCP calls.

That number reflects a chatty, sequential design more than the protocol itself, but it is a useful warning against building tools that force ten calls where one would do.

How to Reduce MCP Tool Call Latency

None of these requires waiting on a protocol change; they are server design choices available today.

• Cache discovery and stable reads: cache tools/list and similar results per the server's own ttlMs hints, and reuse a warm session instead of reconnecting and rediscovering tools on every turn.
• Narrow the result before it ships: add filters, limit parameters, and date bounds so a tool returns only what the next reasoning step needs, rather than a full dump the model has to sift through.
• Avoid chatty tool surfaces: one search-and-summarize style tool beats a list-ids call followed by a separate detail call per item.
• Use Explicit State Handles: Use explicit state handles for multi-step workflows, such as a cart ID or a job ID, instead of retransmitting or reconstructing large state on every call.
• Trim tool-definition overhead: every registered tool costs tokens on every turn, whether or not the model calls it, so expose only what the client actually needs.
• Set deliberate budgets: a per-call timeout tied to the operation's own service target, a separate maxTotalTimeout hard cap, and instrumentation that separates model time from transport time from server execution time.
• Use Direct API Calls for Ultra-Fast Paths: For a genuinely hot, sub-200ms, deterministic path, consider a direct pooled API call instead of MCP, and reserve MCP for discovery and broader integration coverage.

Set the Right Latency Targets for WhatsApp

Latency budgets matter differently depending on what a WhatsApp tool is doing. A send-template call that a support agent is waiting on mid-conversation belongs firmly in the hot-path band: aim for the sub-second target, and make sure the caller sees a clear result rather than a silent wait.

A list-conversations or get-contact lookup used to build context can tolerate a couple of seconds, since it usually happens before the model composes its reply rather than while a human watches a spinner.

The Wati MCP server exposes named WhatsApp actions rather than raw database calls, which is itself a latency decision: fewer, more purposeful tools mean fewer chained round-trip per task. When you connect Wati's MCP server to Claude, the client's own timeout defaults apply on top of whatever your server does, so it is worth checking both ends rather than assuming the server's speed is the whole story.

Latency also intersects with trust. A tool that fails slowly, or times out without a clear error, is harder for an agent to recover from than one that fails fast with a useful message; Wati's MCP security writeup digs into what a tool should hand back when something goes wrong, which matters just as much as how fast it responds when nothing does.

Chaining several WhatsApp actions in one turn multiplies both the latency risk and the failure surface, and the walkthrough for building a WhatsApp AI agent in ten minutes shows a chain short enough to stay inside a sane p95 budget.

Set a Latency Budget That Works

MCP doesn’t define a universal latency target, so the right benchmark depends on how the tool is used. Aim for fast responses during interactive calls, account for client and SDK timeouts, and avoid unnecessary chained calls that introduce delays.

For WhatsApp MCP workflows, purposeful tools and clear latency budgets can keep agent interactions responsive without sacrificing functionality.

Want to see MCP in action? Book a Wati demo to explore WhatsApp MCP tools and see how they perform in real time.