MCP vs UTCP: we timed both on the same 10 tools

Short answer: MCP adds about half a millisecond per tool call compared with UTCP, and neither protocol makes your tool definitions smaller. On the same 10 tools, a UTCP call took a median of 0.161 ms, a plain HTTP call took 0.162 ms and an MCP call took 0.632 ms. A language model inference takes seconds, so that difference will not noticeably change your agent's responsiveness. Your decision should depend on which clients consume the tools, rather than on latency characteristics.

This post documents the experimental setup, the measurements, the context consumption of each format and a practical decision rule. It also lists the scenarios we could not test.

Should you pick MCP or UTCP for your tools?

Pick MCP when your tools must work in other people's AI clients. Pick UTCP when you control the agent runtime and your tools already speak plain HTTP. Publishing both is technically inexpensive, but it doubles the maintenance responsibility for your team.

Your situation	Pick	Why
Tools used from desktop assistants and IDEs you do not own	MCP	Those clients speak MCP
Internal agent you build, tools are existing REST endpoints	UTCP	No extra server to run
You need one server to hold credentials and policy	MCP	The server sits in the middle by design
You want zero added hops per call	UTCP	The client calls the tool directly
Unsure	MCP first	Wider client reach, and UTCP can describe MCP tools too

What are MCP and UTCP?

MCP is the Model Context Protocol, an open standard that lets AI clients discover and call tools through a server. Anthropic donated it to the Linux Foundation, where it is a founding project of the Agentic AI Foundation, according to IT Brief's report on the donation.

UTCP is the Universal Tool Calling Protocol, an open standard where a JSON manual tells the client how to call each tool's native interface. The client then calls the tool directly, with no protocol server in between, as Nordic APIs describes the design.

A tool manual is a JSON document listing each tool's name, description, input schema and the call template that says how to reach it. Both protocols publish one. They differ in what the manual points at.

The UTCP project describes MCP as one of several protocols a manual can wrap. Its own comparison page lists an MCP plugin for gradual migration. That page is the project's own material, so treat its claims as the vendor view.

How did we test them?

We built one backend with ten order and customer tools, then exposed it two ways. An MCP server wrapped each tool. A UTCP manual described the same tools and pointed straight at the backend.

Item	Setting
Hardware	Apple M2, everything on 127.0.0.1
MCP	@modelcontextprotocol/sdk 1.32.2, Streamable HTTP, stateless, JSON responses
UTCP	@utcp/sdk 1.2.0 with @utcp/http 1.1.14
Tools	10, each with a description and three inputs
Calls	2,000 timed calls after 200 warm-up calls, per target, three runs
Baseline	A plain fetch POST to the same backend route

The backend returns a small JSON body with five rows. The UTCP client prints a log line on every call, so we silenced the console during timing. Without that, logging would dominate the result.

One design choice favors UTCP. Our MCP server follows the SDK's stateless pattern and builds a fresh server object for every request. A long-lived session server would likely do better. Read the MCP number as an upper bound for this setup.

How much latency does each protocol add?

A UTCP call matched a plain HTTP call within noise, and an MCP call cost about 0.47 ms more at the median. Using the median of three runs, direct HTTP took 0.162 ms, UTCP took 0.161 ms and MCP took 0.632 ms.

Target	p50, run 1	p50, run 2	p50, run 3	Median of runs	p95, median of runs
Direct fetch	0.162 ms	0.158 ms	0.189 ms	0.162 ms	0.321 ms
UTCP client	0.171 ms	0.154 ms	0.161 ms	0.161 ms	0.270 ms
MCP client	0.731 ms	0.632 ms	0.629 ms	0.632 ms	1.816 ms

MCP is about 3.9 times slower per call in this lab. Does that matter? It sounds large until you set it beside the model. A language model call usually takes hundreds of milliseconds to many seconds. Half a millisecond is invisible next to it.

A SoftwareSeni explainer puts MCP's extra overhead at 25 to 100 percent over direct calls, without naming the benchmark behind that range, in its integration write-up. Our relative gap is larger because our tool does almost no work. Consider a real tool that queries a database for 20 ms, such as an order lookup. The relative gap shrinks to a rounding error, because the tool's own work dominates the whole call.

Does either protocol shrink your tool definitions?

No. For the same 10 tools, the UTCP manual was 6,783 bytes and the MCP tools/list response was 6,052 bytes. The UTCP manual is somewhat larger because every tool additionally carries a call template containing its endpoint address and HTTP method.

Format	Bytes for 10 tools	Bytes per tool	Rough tokens at 4 bytes each
UTCP manual	6,783	678	about 1,700
MCP tools/list	6,052	605	about 1,500

The token column is our estimate from a four-bytes-per-token rule of thumb, not a tokenizer count. The ratio between the two formats is the useful part. Both land within 12 percent of each other.

The practical lever for reducing your context bill is loading fewer definitions into the prompt at any one time. The UTCP client SDK includes a searchTools call that returns only matching tools. We saw it return all ten tools for the query "order", because every tool matched. Our earlier post on how an MCP connector spends context before you type covers the same problem on the MCP side.

How do the two calls actually flow?

An MCP call passes through your server. A UTCP call goes from the client directly to the tool. That single architectural difference explains the latency gap and most of the operational trade-offs between them.

MCP flow:

1. The client sends a tools/call request to the MCP server.
2. The server validates the arguments against its schema.
3. The server calls your backend and wraps the reply as MCP content.
4. The client unwraps the content and hands it to the model.

UTCP flow:

1. The client reads the manual once and caches the tool list.
2. The client builds the HTTP request from the call template.
3. The backend replies, and the client returns the JSON to the model.

The extra server in MCP is also the natural place to put shared controls, which is an organizational benefit that a raw latency number cannot capture. Rate limits, audit logs and credential handling can live in one place. In UTCP, each client holds the call template and any auth it needs, so those controls move to your API gateway or into each agent.

What does the code look like?

Defining one tool in MCP means registering a handler. Defining it in UTCP means adding an entry to a manual.

MCP, using the TypeScript SDK:

server.registerTool('get_order', {
  description: 'Fetch one order by id',
  inputSchema: { id: z.string() },
}, async ({ id }) => {
  const r = await fetch(`https://api.example.com/orders/${id}`);
  return { content: [{ type: 'text', text: await r.text() }] };
});

UTCP, as a manual entry served from /utcp:

{
  "name": "get_order",
  "description": "Fetch one order by id",
  "inputs": { "type": "object", "properties": { "id": { "type": "string" } }, "required": ["id"] },
  "tool_call_template": {
    "call_template_type": "http",
    "http_method": "POST",
    "url": "https://api.example.com/orders",
    "content_type": "application/json",
    "body_field": "body"
  }
}

The UTCP entry needs no new process. Your existing API serves the manual. The MCP version needs a running server and an SDK dependency, but it gives you a typed handler where you can add checks.

How do security and credentials differ?

MCP keeps secrets on the server. UTCP spreads them across the clients that call the tools. Neither approach is inherently safer. Each one relocates the security responsibility to a different component.

With MCP, the model's client never sees your API key. The server holds it and applies it to backend calls. If the server is exposed on the network, though, anyone who reaches it can call every tool. Our measurements of MCP servers that bind every interface found that mistake common.

With UTCP, the call template can carry auth settings, so the client needs the credentials. That arrangement is acceptable for an internal agent your organization operates. It is a poor fit for software distributed to customers, because every customer's agent would require its own credential.

Two controls help in both designs:

1. Give each tool the narrowest scope it needs, following the least privilege principle that NIST defines. A read-only order lookup should not share a key with refunds.
2. Log every call at the backend, not only in the agent, so you can audit what ran.

What happens when the tool list changes?

Adding a tool is a deploy in both protocols. In MCP, you register a handler and restart the server. In UTCP, you edit the manual. Clients that cached the old list will not see the new tool until they refresh.

Why does this matter in practice? Plan for it, for example by adding a version field. Version your manual or server, and tell clients how often to re-read the list. A stale cache makes an agent claim a tool does not exist, which looks like a model bug and wastes debugging time.

What did we not test?

We evaluated a single machine, one small payload and the TypeScript SDKs exclusively. That leaves several important limitations you should understand before making a decision.

• Remote networks. On a real network, round-trip time dominates. Both protocols add one HTTP exchange per call, so the gap would stay near 0.5 ms while each call grows to tens of milliseconds.
• Streaming. We timed plain request and response calls. Long-running tools and streamed output behave differently in each protocol.
• Other SDKs. Python and Go SDKs for both protocols may perform differently.
• Client behavior. We called both protocols from scripts. We did not test how Claude, ChatGPT or an IDE assistant handles each one.
• Adoption. We found no independent count of UTCP users. The evidence for UTCP adoption comes mostly from the project's own pages.

How should you migrate or run both?

Start with MCP if outside clients matter, and then add a UTCP manual for your own agents only when the extra network hop actually shows up in a performance trace. Do not build both on day one.

1. List the clients that will call your tools. If any is a third-party assistant, build the MCP server first.
2. Keep your business logic in the REST API. Both wrappers should stay thin and contain no business rules, because duplicated logic in two wrappers inevitably drifts apart over time.
3. Generate the UTCP manual and the MCP registrations from one tool list, as our lab did with a shared definitions file. This keeps the two from drifting.
4. Trace one real workflow. If tool calls take under 1 ms of a multi-second turn, leave the architecture alone.

If you already run an MCP server, test it against the checks in our earlier notes on exposed bind addresses and stateless transport. Security and state matter far more than 0.5 ms.

Final verdict

Choose MCP for reach and UTCP for control. The 0.47 ms latency gap in our lab is real, but it is a tiny slice of an agent turn. Tool definition size is a tie. The deciding questions are who calls your tools, where you want credentials and policy to live, and how many servers you want to run.