← LinkedIn demo

AILANG×utcp.io

AI agent-ready generated 2026-05-14
agent-ready privacy portable

utcp.io scored 4/10 on agent-ready.

The radar shows AILANG-readiness across three commercial concerns. High means utcp.io is already strong there; low means AILANG could meaningfully help.

Why agent-ready scored 4/10
  • Page references /.well-known/agent.json — the A2A agent card discovery endpoint. Worth only 1pt: it's bleeding-edge (A2A protocol new in 2026), no commercial site has adopted it yet — keep it as a moonshot bonus, not a baseline expectation.
  • Page references /openapi.json, /openapi.yaml, or an OpenAPI schema URL.
  • Page references an MCP endpoint such as /mcp/ or /mcp/sse.
  • Page links to public API documentation, Swagger UI, or ReDoc.
  • Page mentions webhooks, callback URLs, or event subscriptions — the most agent-callable backend pattern.
  • Page documents rate limits, throttling, or 429 handling — agents need to know how to back off.
  • Page references Server-Sent Events, text/event-stream, or a streaming endpoint — agents that read incrementally land here.
  • Page mentions a sandbox, test mode, or test environment — lets agents practise against fake state before touching production.
  • Page documents OAuth, JWT, bearer tokens, API keys, or access tokens — agents can't call the API without knowing how to authenticate.
  • Page mentions idempotency, idempotency-key, or idempotent requests — agents need this to retry safely.
  • Page mentions AG-UI (Agent-User Interaction Protocol) — streams 16 typed lifecycle/text/tool/state events from agent backend to frontend over SSE or WebSocket.
  • Page mentions x402 (Coinbase's signed crypto payment payloads) or Cloudflare's pay-per-crawl (crawler-price header for AI-crawler monetisation). Both revive HTTP 402 for agents — Cloudflare joined the x402 Foundation, so they're one umbrella signal.
  • Page mentions AP2 (Agent Payments Protocol) — Google + Mastercard + 60 orgs. Cryptographically signed Mandates (Intent + Cart) authorise agents to spend on a user's behalf with price/timing/condition bounds.
  • Page mentions UTCP (Universal Tool Calling Protocol) — MCP alternative. Tools described in a JSON UTCPManual, called via their native protocols (HTTP/gRPC/CLI).

Full breakdown ↓ · View rubric ↗

The site is for AI agent developers, application builders, and tool providers who want to enable direct and secure communication between AI agents and external tools or APIs.

UTCP is a lightweight, secure standard enabling AI agents and applications to discover and call tools directly using native protocols, without wrapper servers. It extends OpenAPI for agent-focused enhancements, offering a modular, plugin-based architecture for various communication protocols, reducing latency and integration complexity.
Universal Tool Calling Protocol (UTCP) AI Agents APIs Tool Providers OpenAPI Protocol Plugins

What AILANG Parse sees on utcp.io

Structural extraction — the same content an AI agent would consume from this page.

24 headings2 images21 lists3 tables9 links5 code samplesHTML parsing by AILANG Parse

9 sections — page skeleton

1 header 4 navs 1 main 1 article 2 footers

24 headings

Universal Tool Calling Protocol (UTCP) Why UTCP?​ The Problem with Current Approaches​ The UTCP Solution​ OpenAPI Compatibility​ Quick Start (5 Minutes)​

2 images

UTCP LogoUTCP Logo

21 list items

[Next](/next) [1.1](/) [1.0](/1.0) [0.1](/0.1) [Introduction](/) [For Tool Providers](/for-tool-providers) [Protocols](/protocols) [Security Considerations](/security) [Migration Guide - v0.1 to v1.0](/migration-v0.1-to-v1.0) [Migration Guide - v1.0 to v1.1](/migration-v1.0-to-v1.1) [API Specification](/api) Introduction
Show the full extract — what AILANG Parse pulled from this page
# Introduction | Universal Tool Calling Protocol (UTCP)


[Skip to main content](#__docusaurus_skipToContent_fallback)

[Image: UTCP Logo]

[Image: UTCP Logo]

[(link)](/)

[Docs](/)

[Tool Registry](/registry)

[RFC](/about/RFC)

[About Us](/about/about-us)

[Blog](/blog)

[1.1](/)

- [Next](/next)
- [1.1](/)
- [1.0](/1.0)
- [0.1](/0.1)

[...](https://github.com/universal-tool-calling-protocol)

[Discord](https://discord.gg/ZpMbQ8jRbD)

- [Introduction](/)
- [For Tool Providers](/for-tool-providers)
- [Implementation Guide](/implementation)
- [Protocols](/protocols)
- [UTCP vs MCP](/utcp-vs-mcp)
- [Security Considerations](/security)
- [Migration Guide - v0.1 to v1.0](/migration-v0.1-to-v1.0)
- [Migration Guide - v1.0 to v1.1](/migration-v1.0-to-v1.1)
- [API Specification](/api)

- Introduction

Version: 1.1

On this page

*Header:*
# Universal Tool Calling Protocol (UTCP)

Language Examples

UTCP is available in multiple languages - see [Python](https://github.com/universal-tool-calling-protocol/python-utcp), [TypeScript](https://github.com/universal-tool-calling-protocol/typescript-utcp), [Go](https://github.com/universal-tool-calling-protocol/go-utcp), and other implementations in the [UTCP GitHub organization](https://github.com/universal-tool-calling-protocol).

UTCP is a lightweight, secure, and scalable standard that enables AI agents and applications to discover and call tools directly using their native protocols - **no wrapper servers required**.

## Why UTCP?​

### The Problem with Current Approaches​

Most tool integration solutions force you to:

- Build and maintain wrapper servers for every tool
- Route all traffic through a middleman protocol
- Reimplement existing authentication and security
- Accept additional latency and complexity

### The UTCP Solution​

UTCP acts as a **"manual"** that tells agents how to call your tools directly:

Core Philosophy

*"If a human can call your API, an AI agent should be able to call it too - with the same security and no additional infrastructure."*

## OpenAPI Compatibility​

UTCP extends OpenAPI for AI agents while maintaining full backward compatibility. Where OpenAPI describes APIs for human developers, UTCP adds agent-focused enhancements: `tags` for categorization, `average_response_size` for resource planning, multi-protocol support (HTTP, CLI, gRPC, MCP), and direct execution instructions. Existing OpenAPI specs can be automatically converted to UTCP manuals without requiring API changes or additional infrastructure.

## Quick Start (5 Minutes)​

### 1. Install UTCP​

`# Example installation (Python)
pip install utcp utcp-http
# Example installation (Node.js)
npm install @utcp/core @utcp/http
# See language-specific documentation for other implementations
`

### 2. Expose Your First Tool​

**Option A: Discovery via existing OpenAPI spec**

**Generate OpenAPI endpoint**: `GET http://api.github.com/openapi.json`

**Option B: Add a discovery endpoint to your existing API**

**Add endpoint**: `GET /utcp`**Return your UTCP manual**:

`{
"manual_version":"1.0.0",
"utcp_version":"1.0.1",
"tools":[{
"name":"get_weather",
"description":"Get current weather for a location",
"inputs":{
"type":"object",
"properties":{"location":{"type":"string"}},
"required":["location"]
},
"tool_call_template":{
"call_template_type":"http",
"url":"http://localhost:8000/weather",
"http_method":"GET"
}
}],
"auth":{
"auth_type":"api_key",
"api_key":"${WEATHER_API_KEY}",
"var_name":"appid",
"location":"query"
}
}
`

### 3. Call Your Tool​

**Option A: Configure UTCP client**:

`{
"manual_call_templates":[{
"name":"weather_api",
"call_template_type":"http",
"url":"http://localhost:8000/utcp",// Or http://api.github.com/openapi.json, the openapi spec gets converted automatically
"http_method":"GET"
}]
}
`

**Option B: Convert OpenAPI spec to UTCP manual manually**

`asyncdefconvert_api():
asyncwith aiohttp.ClientSession()as session:
asyncwith session.get("https://api.github.com/openapi.json")as response:
            openapi_spec =await response.json()
    converter = OpenApiConverter(openapi_spec)
    manual = converter.convert()
print(f"Generated {len(manual.tools)} tools from GitHub API!")
return manual
`

Then save that to a text file and load it with the text configuration:

`{
"manual_call_templates":[{
"name":"github_manual",
"call_template_type":"text",
"file_path":"./github_manual.json",
}]
}
`

**Call the tool**:

1. Initialize UTCP client with configuration
2. Discover tools from weather API
3. Call `get_weather` tool with location parameter
4. Receive weather data response

**That's it!** Your tool is now discoverable and callable by any UTCP client.

## Key Benefits​

| Benefit | Description |
| --- | --- |
| **🚀 Zero Latency Overhead** | Direct tool calls, no proxy servers |
| **🔒 Native Security** | Use your existing authentication and authorization |
| **🌐 Protocol Flexibility** | HTTP, MCP, CLI, GraphQL, and more |
| **⚡ Easy Integration** | Add one endpoint, no infrastructure changes |
| **📈 Scalable** | Leverage your existing scaling and monitoring |

## How It Works​

1. **Discovery**: Agent fetches your UTCP manual
2. **Learning**: Agent understands how to call your tools
3. **Direct Calling**: Agent calls your API directly using native protocols
4. **Response**: Your API responds normally

## Supported Protocols​

UTCP supports multiple communication protocols through plugins:

| Protocol | Use Case | Plugin | Status |
| --- | --- | --- | --- |
| **[HTTP](/protocols/http)** | REST APIs, webhooks | `utcp-http` | ✅ Stable |
| **[CLI](/protocols/cli)** | Command-line tools | `utcp-cli` | ✅ Stable |
| **[Server-Sent Events](/protocols/streamable-http)** | Streaming data | `utcp-http` | ✅ Stable |
| **[Text Files](/protocols/text)** | File reading | `utcp-text` | ✅ Stable |
| **[MCP](/protocols/mcp)** | MCP interoperability | `utcp-mcp` | ✅ Stable |

[View all protocols →](/protocols)

## Architecture Overview​

UTCP v1.0 features a modular, plugin-based architecture:

### Core Components​

- **[Manuals](/api/core/utcp/data/utcp_manual)**: Tool definitions and metadata
- **[Tools](/api/core/utcp/data/tool)**: Individual callable capabilities
- **[Call Templates](/api/core/utcp/data/call_template)**: Protocol-specific call instructions
- **[UTCP Client](/api/core/utcp/utcp_client)**: Tool discovery and execution engine

### Plugin System​

- **Protocol Plugins**: HTTP, MCP, CLI, etc.
- **Custom Protocols**: Extend with your own communication methods
- **Tool Repositories**: Pluggable storage for tool definitions
- **Search Strategies**: Customizable tool discovery algorithms

[Learn more about the architecture →](/api)

## Who Should Use UTCP?​

### 🛠️ Tool Providers​

You have APIs, services, or tools that you want AI agents to use:

- **Existing API owners** - Expose your REST APIs to AI agents
- **SaaS providers** - Make your services AI-accessible
- **Enterprise teams** - Enable internal tool usage by AI systems

[**Get started as a tool provider →**](/for-tool-providers)

### 🤖 Tool Consumers​

You're building AI agents or applications that need to call external tools:

- **AI agent developers** - Give your agents access to external capabilities
- **Application builders** - Integrate third-party tools seamlessly
- **Enterprise developers** - Connect to internal and external services

[**Get started as a tool consumer →**](/implementation)

## UTCP vs Alternatives​

| Feature | UTCP | MCP | Custom Wrappers |
| --- | --- | --- | --- |
| **Infrastructure** | None required | Wrapper servers | Custom servers |
| **Latency** | Direct calls | Double hop | Variable |
| **Security** | Native | Reimplemented | Custom |
| **Protocols** | Multiple | HTTP streaming | Single |
| **Maintenance** | Minimal | High | Very high |

[**Detailed comparison with MCP →**](/utcp-vs-mcp)

## Next Steps​

### For Tool Providers​

1. **[Read the provider guide](/for-tool-providers)** - Learn how to expose your tools
2. **[Choose your protocol](/protocols)** - Select the right communication method
3. **[Implement your manual](/implementation)** - Add UTCP to your existing API
4. **[Secure your tools](/security)** - Implement proper authentication

### For Tool Consumers​

1. **[Read the implementation guide](/implementation)** - Learn how to build UTCP clients
2. **[Explore protocols](/protocols)** - Understand available communication options
3. **[Check examples](https://github.com/universal-tool-calling-protocol)** - See real-world implementations
4. **[Join the community](https://discord.gg/ZpMbQ8jRbD)** - Get help and share experiences

### Migration from Other Systems​

- **[From UTCP v1.0](/migration-v1.0-to-v1.1)** - Upgrade to v1.1
- **[From UTCP v0.1](/migration-v0.1-to-v1.0)** - Upgrade from legacy v0.1
- **[From MCP](/protocols/mcp)** - Migrate from Model Context Protocol
- **[From custom solutions](/implementation)** - Replace existing tool integrations

## Community & Support​

- **[GitHub Organization](https://github.com/universal-tool-calling-protocol)** - Source code and issues
- **[Discord Community](https://discord.gg/ZpMbQ8jRbD)** - Real-time help and discussions
- **[Tool Registry](https://utcp.io/registry)** - Discover available tools
- **[RFC Process](/about/RFC)** - Contribute to the specification

---

**Ready to get started?** Choose your path:

- 🛠️ [**I want to expose my tools**](/for-tool-providers)
- 🤖 [**I want to call tools**](/implementation)
- 📚 [**I want to learn more**](/protocols)

*Footer:*
[Edit this page](https://github.com/universal-tool-calling-protocol/utcp-specification/tree/main/versioned_docs/version-1.1/index.md)

Last updated on **Nov 30, 2025 (2025-11-30T22:48:57.000Z)**

[Next
For Tool Providers](/for-tool-providers)

- Why UTCP?

The Problem with Current Approaches
The UTCP Solution
- The Problem with Current Approaches
- The UTCP Solution
- OpenAPI Compatibility
- Quick Start (5 Minutes)

1. Install UTCP
2. Expose Your First Tool
3. Call Your Tool
- 1. Install UTCP
- 2. Expose Your First Tool
- 3. Call Your Tool
- Key Benefits
- How It Works
- Supported Protocols
- Architecture Overview

Core Components
Plugin System
- Core Components
- Plugin System
- Who Should Use UTCP?

🛠️ Tool Providers
🤖 Tool Consumers
- 🛠️ Tool Providers
- 🤖 Tool Consumers
- UTCP vs Alternatives
- Next Steps

For Tool Providers
For Tool Consumers
Migration from Other Systems
- For Tool Providers
- For Tool Consumers
- Migration from Other Systems
- Community & Support

*Footer:*
Docs

- [Overview](/)
- [Implementation Guide](/implementation)
- [UTCP vs MCP](/utcp-vs-mcp)

Community

- [Discord](https://discord.gg/ZpMbQ8jRbD)
- [GitHub](https://github.com/universal-tool-calling-protocol)
- [Issues](https://github.com/universal-tool-calling-protocol/utcp-specification/issues)
- [Discussions](https://github.com/universal-tool-calling-protocol/utcp-specification/discussions)

Specification

- [Repository](https://github.com/universal-tool-calling-protocol/utcp-specification)
- [Releases](https://github.com/universal-tool-calling-protocol/utcp-specification/releases)

Resources

- [Blog](/blog)
- [Registry](/registry)

About

- [About Us](/about/about-us)
- [Hall of Fame](/hall-of-fame)
- [RFC](/about/RFC)
- [Contact the Founders](/cdn-cgi/l/email-protection#1d77687c735d7f786b7871336e727b696a7c6f78)
- [Impressum](/about/impressum)

Copyright © 2026 UTCP Contributors. Licensed under Apache-2.0, except API reference docs (api/**) under MPL-2.0.

page preview · the URL we fetched https://www.utcp.io/ ↗
Screenshot of utcp.io

Couldn't render a preview for this site. Open the URL in a new tab ↗

Screenshot via thum.io

utcp.io scored 4/10 on agent-ready. AILANG opportunity is therefore 6/10. Here's where it would land first.

REST + MCP + A2A + OpenAPI in one command

ailang serve-api takes your typed AILANG functions and exposes them as REST endpoints, MCP tools, A2A skills, and OpenAPI 3.1 docs simultaneously. One module, four agent surfaces.

ailang serve-api --port 8092 --mcp-http \
  pricing.ail catalogue.ail
-- POST /api/pricing/quote, MCP at /mcp/,
-- A2A at /.well-known/agent.json, OpenAPI at /api/_meta/redoc.
→ AILANG docs

Contract-verified tool calls

Every tool an agent can call has a contract. Bounds, refusal paths, type signatures — proven before the agent ever sees it. The agent cannot exceed the tool's declared authority.

func placeOrder(item: SKU, qty: int) -> Receipt
  requires { qty > 0, qty <= 10 }
  ensures  { result.total > 0.0 }
-- the MCP server exposes this with its contract intact.
→ AILANG docs

An MCP server for your own docs and tools

Generate an MCP server from your typed AILANG functions; the docs MCP exposes a submit_feedback tool so agents can flag issues back to the maintainer. The language and its consumers stay on the same wire.

-- The AILANG docs MCP server lets Claude / Cursor / any
-- MCP client query the language directly:
--   stdlib_search "URL encoding"
--   submit_feedback "..."
→ AILANG docs

How this page was made

func sketchSite(url: string<pii>, topic: Topic) -> Sketch
  ! {Net @limit=1, AI @limit=5, FS @limit=4, Process, Declassify}
SignalTopicResultPointsAILANG primitive
agent.json referencedagent-ready0/1ailang serve-api generates A2A agent cards automatically — bonus if you're an early adopter
openapi.json referencedagent-ready2/2ailang serve-api generates OpenAPI 3.1 from Hindley-Milner type signatures
MCP endpoint referencedagent-ready2/2ailang serve-api --mcp-http exposes typed functions as MCP tools
Public API docs linkedagent-ready2/2ailang serve-api hosts Swagger + ReDoc at /api/_meta/ by default
Webhooks documentedagent-ready2/2ailang serve-api handles webhooks as typed handler functions with effect-tracked side effects
Rate limits documentedagent-ready0/2Capability budgets — Net @limit=N is the symmetric server-side primitive for what agents see as rate limits
Streaming / SSE endpointagent-ready2/2std/stream — ssePost and Stream effect handle event-source endpoints with typed event types
Sandbox / test environment offeredagent-ready0/2ailang --ai-stub plus mock effect handlers — deterministic, capability-scoped fakes for any effect, including Net and AI
Authentication documentedagent-ready0/2std/jwt for verification, IFC labels (string / string) to keep credentials out of public sinks at the type level
Idempotency keys documentedagent-ready0/2Pure functions are idempotent by construction; requires/ensures contracts express idempotence as a static guarantee
AG-UI streaming protocolagent-ready0/1std/stream — the AG-UI event lifecycle (RUN_STARTED → TEXT_MESSAGE_CONTENT → TOOL_CALL_RESULT → RUN_FINISHED) is a textbook sum type. ADTs + exhaustive pattern matching make every event-type branch a compile error to skip.
HTTP 402 agent payments (x402 / pay-per-crawl)agent-ready0/1Net @endpoint-scoped capability budgets bound payment destinations; requires { amount <= budget } gates the payload; IFC labels keep the signed payment key out of public sinks. Same primitives cover x402 payload signing and Cloudflare's crawler-price negotiation.
AP2 Agent Payments Protocolagent-ready0/1Mandates ARE contracts. requires { intent.price <= mandate.maxPrice } + ensures { cart.total <= intent.price } is a one-to-one translation of an Intent/Cart Mandate into AILANG. Z3 can verify the bounds at compile time.
UTCP tool-calling protocolagent-ready1/1Typed function signatures are the manifest. ailang serve-api emits the same metadata as a UTCPManual (name, input/output schema, native endpoint) — direct-call discovery without a proxy server.
End-to-end encryption documentedprivacy0/2IFC labels (string) force decryption to flow through a typed boundary; the compiler refuses to publish sealed values without explicit declassification
Compliance certifications citedprivacy0/2requires/ensures contracts express machine-verifiable claims; capability budgets bound audit-trail effects; effect rows leave nothing un-declared
Data minimisation languageprivacy0/2Capability scoping — each Net call declares its endpoint in the effect row, so "doesn't sell" becomes a type-system-enforceable claim, not a marketing one
Third-party domains restrainedprivacy0/2Capability scoping — each Net call declares its endpoint in the effect row
Data residency / on-prem languageprivacy0/2Three-runtime deploy — same module runs in WASM (browser), Cloud Run, and native CLI
Single-vendor LLM languageportable2/2std/ai multi-provider — switch from Anthropic to Gemini to OpenAI without rewriting
Multiple AI providers citedportable0/2std/ai — one Step API across Anthropic, OpenAI, Gemini, OpenRouter, Ollama, and custom-package providers
Cross-runtime / deployment portabilityportable0/2Effect handlers as runtime adapters — same .ail runs as WASM in the browser, a Cloud Run container, and a native CLI; only the handlers change
BYO key / model-agnosticportable0/2AILANG WASM — the full interpreter ships as a browser bundle, so caller-held keys (BYOK), offline apps, and embedded demos all work client-side