The Problem It Solves
Want your AI agent to call an API? With most protocols, you first need to build a wrapper server, set up new authentication, deploy new infrastructure, and maintain another piece of software. That's the "wrapper tax"—and it adds up fast.
Without UTCP
Every tool needs its own proxy server. Each server consumes 50–200MB of memory, adds a network hop, requires its own authentication setup, and is one more thing that can break at 2 AM.
Got 20 tools? That's 20 wrapper servers to build, deploy, monitor, and maintain. Your API already works perfectly—but now you need to build a middle layer just so AI can use it.
The "wrapper tax." More servers, more latency, more maintenance.
With UTCP
The agent reads a UTCP Manual—a JSON document that describes your API's endpoints, parameters, and authentication. Then it calls your API directly. Same endpoints, same auth, same everything.
No wrapper servers. No middleware. No extra infrastructure. Four steps: discover the manual, learn the tools, call them directly, handle the response.
Zero infrastructure. Direct connection. Your API, agent-ready as is.
How It Works at Runtime
- Write a UTCP Manual (or auto-convert an existing OpenAPI spec). This JSON document describes your API's tools, endpoints, parameters, and authentication—everything an agent needs to call it directly.
- Host the manual at a discoverable URL or provide it directly to the agent client. No server to deploy—it's just a JSON file.
- Agent receives a user request that needs your API. ("What's the weather in Tokyo?" or "Create a new support ticket.")
- Agent reads the manual. It fetches your UTCP Manual, learns what tools exist, what parameters they need, and exactly how to call them via the Call Template.
- Agent calls your API directly. It constructs a standard HTTP request using the Call Template—filling in parameters, headers, and auth tokens. No proxy, no wrapper, no middleman.
- Your API responds normally. It receives a standard HTTP request identical to any request from a human developer—and returns its normal response.
- Agent answers the user. It parses the API response and incorporates the data into its answer. One hop, no translation layer, no extra latency.
Where UTCP Shows Up
UTCP is the natural fit when you have existing APIs and want AI agents to use them without adding infrastructure. Here's where it makes the biggest difference.
Existing REST APIs
Your API already works. UTCP describes it in a JSON manual so agents can call it directly—same endpoints, same authentication, same rate limits. No changes to your API required.
"We pointed UTCP at our existing API docs and agents could use our service within hours."
CLI Tools
Internal command-line tools become agent-accessible through UTCP CLI templates. Agents invoke scripts, run builds, and execute commands—all through the same protocol.
"Our deployment scripts are now callable by AI agents through UTCP CLI templates."
Microservices
Each microservice gets its own UTCP manual. Agents discover and call services directly using their native protocols—HTTP, gRPC, WebSocket—without any proxy layer.
"Our 30 microservices became agent-accessible by adding UTCP manuals—no new infrastructure."
Legacy Systems
Systems that already have APIs (even older ones) can be made agent-ready by describing them in a UTCP manual. No need to build new middleware or modernize the API first.
"Our 10-year-old API got agent access without touching a line of legacy code."
OpenAPI Migration
If you already have OpenAPI specifications, UTCP can auto-convert them. Your existing API docs become agent-callable manuals instantly.
"We converted our OpenAPI spec to a UTCP manual automatically—zero manual work."
Hybrid with MCP
UTCP includes an MCP plugin, so you can access the MCP ecosystem's 10,000+ tools while keeping your own APIs on UTCP. Best of both worlds, no compromises.
"We use UTCP for our APIs and MCP tools for ecosystem access—same client, no conflict."
Why It Matters
Think of UTCP like calling someone directly instead of going through a switchboard. The call is faster, simpler, and nothing gets lost in translation.
With a v1.0 specification and actively developed SDKs, UTCP delivers zero infrastructure overhead—$0 in additional server costs. Response times of 50–200ms (25–50% lower latency than MCP) because there's no middleman—single hop instead of double. Your existing authentication, rate limiting, and monitoring stay exactly as they are.
UTCP supports multiple protocols through a plugin architecture: HTTP for REST APIs, CLI for command-line tools, SSE for streaming, and even MCP as a fallback for ecosystem access. You're not locked into one communication pattern.
The philosophy is simple: describe tools, don't wrap them. If your API already works, UTCP makes it agent-ready without adding complexity.
Key Concepts in Plain Language
- UTCP Manual: A JSON document that describes your API—its endpoints, parameters, authentication, and how to call it. Think of it as an instruction manual that AI agents can read.
- Direct Calling: Agents talk directly to your API using its native protocol. No proxy server, no translation layer, no middleware. The agent calls your API the same way a human developer would.
- Plugin Architecture: UTCP supports different protocols through plugins: HTTP, CLI, SSE, Text, and MCP. Each plugin teaches the agent how to communicate using that specific protocol.
- Call Templates: Each tool in a manual has a call template that tells the agent exactly how to invoke it—the URL, the method, where to put the parameters, and what authentication to use.
- OpenAPI Conversion: If you already have an OpenAPI spec documenting your API, UTCP can automatically convert it into a UTCP manual. Instant agent access.
- MCP Interop: UTCP includes an MCP plugin that lets agents access MCP tools through the UTCP client. You don't have to choose one or the other.
The Standard
UTCP lets agents call any API using its native protocol. No wrappers, no overhead, no new infrastructure. Your APIs become agent-ready as they are—describe them once, call them directly.
What It Looks Like
A UTCP Manual is a JSON document that describes your API so agents can call it directly. Here's a weather API example:
{
"name": "weather_api",
"version": "1.0",
"description": "Get current weather data",
"tools": [
{
"name": "get_weather",
"description": "Get current weather for a city",
"inputSchema": {
"type": "object",
"properties": {
"location": { "type": "string" }
},
"required": ["location"]
},
"callTemplate": {
"call_template_type": "http",
"url": "https://api.example.com/weather",
"method": "GET",
"parameters": {
"query": { "city": "{{location}}" }
}
}
}
]
}
The agent reads this manual, understands the tool, and calls your API directly—same endpoint, same authentication, no wrapper server needed.
How to Apply This
- • Start with your existing APIs—UTCP works with what you already have, no changes needed
- • Create a UTCP Manual (JSON document) that describes your API's endpoints, auth, and parameters
- • If you have OpenAPI specs, auto-convert them to UTCP format—it detects endpoints, parameters, and security schemes automatically
- • Choose UTCP when latency and infrastructure cost matter most; choose MCP when you need the largest ecosystem of pre-built tools
- • Use both together: UTCP for your own APIs (direct, fast), MCP for ecosystem tools (via the UTCP MCP plugin)
- • SDKs are available in Python, TypeScript, Go, and Rust—pick your language and install the core package plus protocol plugins
- • UTCP and MCP aren't rivals—they solve different problems. UTCP is the direct line; MCP is the ecosystem hub
What to Watch Out For
Honest Limitations
- • UTCP's ecosystem is small compared to MCP (~285 GitHub stars vs MCP's 10,000+ servers). If you need access to a wide variety of pre-built tools, MCP has a much larger catalog.
- • UTCP is community-driven with a small core team (~7 contributors) and not governed by the Linux Foundation. It doesn't have the same backing from Google, Microsoft, and OpenAI that MCP does.
- • Clients need to handle more complexity—multiple protocols, diverse auth schemes, and varied response formats. The SDKs help, but there's inherent complexity in direct calling.
- • No centralized registry like MCP's ecosystem. Tool discovery is still maturing, though utcp.io/registry is growing.
- • If you need MCP-specific features like resources and prompts (not just tools), UTCP doesn't offer equivalents. Use MCP directly for those.