Skip to main content

Protocol Interoperability

IICP is not trying to replace every agent or tool protocol. It helps software find a capable provider first, then lets the right tool, agent, or transport protocol do its own job.

IICP is a protocol-neutral intent-resolution, provider-eligibility and execution-selection control plane. It selects a provider using live policy and operational evidence, then hands execution to MCP, A2A, an OpenAI-compatible endpoint or another supported binding.

New to the category? Start with the AI mesh architecture or the AI agent discovery guide.

Current IAIP and AIDIP Internet-Drafts cover materially overlapping discovery and selection functions. They are work in progress, not IETF endorsement. See the public reviewer brief and feature, evidence-maturity and chronology comparison.

The simple picture

Execution protocols do the work

MCP, A2A and compatible APIs define how a selected service is used.

IICP selects an eligible provider

A client resolves an intent using capability, health and policy evidence.

The payload remains direct

After selection, the client uses the provider's execution protocol without sending the task through the directory.

Protocol stack

NeedIntent + constraints
SelectionIICP ← proposed narrow role
ExecutionA2A / MCP / HTTP API / IICP peer
TransportHTTP / QUIC / WebSocket / TCP

What the comparison is testing

The open standards question is whether independent implementations need shared semantics for the transition below, or whether existing discovery and execution protocols already cover it adequately.

Intent + required constraints
  → eligible candidates
  → selected provider + execution binding
  → bounded dispatch authorization

Ranking algorithms, model architecture, marketplace policy and commercial terms are outside this minimum.

Public evidence maturity and chronology

The dated comparison scores public evidence from 0 to 4 for each dimension. A score of 0 means no reviewed public evidence for that dimension; 4 requires a detailed contract plus independently maintained implementations or externally governed interoperability evidence. The scores are not added into a winner ranking.

WorkSpecificationSecurityImplementationConformanceIndependentGovernance
IICP333312
IAIP210001
AIDIP210001
A2A434234
MCP434244
DNS-AID330001

MCP and A2A have stronger independent implementation and governance evidence than IICP, while IICP has more same-project implementation and conformance evidence than the reviewed individual Internet-Drafts. Different protocol roles remain different even when their evidence is mature.

Protocol chronology

MCP, ANP, AGNTCY, A2A, AIDIP's initial discovery draft and the DNS-AID predecessor were public before IICP's first public draft on 27 October 2025. IAIP, AIPF and IACP followed it.

Mechanism chronology

IICP's initial intent-routing draft predates IAIP -00 and AIDIP's intent-selection extension. Its current explicit provider-eligibility vocabulary postdates both February 2026 drafts. Dates do not prove invention, influence or ownership.

Each rating and date has a rationale and primary source in the machine-readable comparison.

MCP

Model Context Protocolbinding

Tool / context provision · Client → Server

MCP defines an interoperability boundary for tools and increasingly agent-backed systems. IICP selects an eligible provider before execution through MCP or another supported protocol.

Binding pattern

Two directions: (1) IICP proxy as MCP tool — route LLM tasks to the IICP mesh from any MCP client. (2) MCP server as IICP node — register any MCP server with the IICP directory and become discoverable by intent URN.

A2A

Agent2Agent Protocolbinding

Agent coordination · Peer-to-peer

A2A defines agent task exchange and lifecycle behavior. IICP can select an eligible provider before a direct A2A interaction.

Binding pattern

A pre-normative IICP binding demonstrates selection followed by direct A2A execution. It is not enabled as a default or an A2A compatibility claim for every implementation.

IAIP

Intent-based Agent Interconnection Protocoloverlap

Intent gateway · Agent ↔ Gateway

IAIP also defines registration, capability validation, intent resolution, matching, selection and forwarding at an Agent Gateway. This is direct overlap with IICP's proposed narrow role.

Binding pattern

No binding is claimed. The projects need a field-level comparison of gateway payload paths, trust, selection results and failure semantics before asserting a distinct boundary.

AIDIP

AI Agent Discovery and Invocation Protocoloverlap

Discovery and invocation · Client ↔ Registry / Agent

AIDIP defines agent metadata, capability and intent-based discovery, ranked candidates and a REST invocation interface. Its July 2026 revision materially overlaps IICP discovery and selection.

Binding pattern

No binding is claimed. IICP must show whether policy eligibility and bounded dispatch authorization are separable additions rather than duplicate discovery machinery.

DNS-AID

DNS for AI Discoveryinput

Discovery input · DNS publisher → Consumer

DNS-AID publishes agent connectivity and capability-document references with SVCB, DNS-SD and optional DNSSEC/DANE support.

Binding pattern

IICP can treat DNS results as candidate and provenance input. DNS publication alone does not prove current availability, caller-policy eligibility or dispatch authority.

MCP ↔ IICP integration guide

Two patterns, five minutes each. No rewrite of your existing MCP server.

A — IICP proxy as an MCP tool (planned)

Route LLM tasks to the IICP mesh from any MCP-compatible client (Claude Code, Cursor, Continue, etc.). Planned: the proxy will present as an MCP tool named iicp_task. Today the shipped consumer surfaces are the OpenAI-, Ollama- and Anthropic-compatible APIs (direction B below).

How it works
1Your MCP client sends a tools/call with tool name iicp_task and an intent argument.
2The IICP proxy translates the call into an IICP CALL message, discovers the best available node for the intent via the directory, and submits the task.
3The response arrives as the MCP tool result — your client code is unchanged.

MCP tool call (your client sends this):

{
  "tool": "iicp_task",
  "arguments": {
    "intent": "urn:iicp:intent:llm:chat:v1",
    "messages": [{ "role": "user", "content": "Summarise this paper..." }],
    "qos": "interactive"
  }
}

The proxy discovers a node and returns:

{
  "content": [{ "type": "text", "text": "The paper argues that..." }],
  "node_id": "eu-worker-03",
  "latency_ms": 210
}

The proxy listens on localhost:9483 by default — in the reserved IICP proxy band, deliberately distinct from Ollama's 11434so the two run side by side. Point your Ollama/OpenAI/Anthropic-compatible tool's base URL at localhost:9483 (the proxy answers all three shapes), or override with IICP_PROXY_PORT. The proxy is part of the unified iicp-client (one component: node + query + proxy — shipped in Python, TypeScript, and Rust). See Using the proxy to install and start it.

B — Join the IICP mesh as an MCP server provider

Any existing MCP server can become a discoverable IICP node in three steps. IICP clients that discover urn:iicp:intent:mcp:tools/call:v1 will route tasks to your server automatically.

IICP is currently in Beta. You can join and test it if its current scope fits your use case. Registration calls https://iicp.network/api/v1/register. Install a published SDK (pip / npm / cargo install iicp-client) and run iicp-node serve.
1

Register your MCP server

Send a POST to the directory with your public endpoint and MCP tool list. The directory assigns a node_token — save it.

curl -X POST https://iicp.network/api/v1/register \
  -H "Content-Type: application/json" \
  -d '{
    "node_id": "my-mcp-server",
    "region": "us-east",
    "endpoint": "https://my-server.example.com",
    "capabilities": [{
      "intent": "urn:iicp:intent:mcp:tools/call:v1",
      "models": ["mcp-bridge"],
      "max_tokens": 4096
    }],
    "limits": { "max_concurrent": 4, "tokens_per_min": 10000 }
  }'
# → 201 {"node_token": "...", "node_id": "my-mcp-server", ...}
2

Send heartbeats every 30 seconds

Nodes not seen for 90 seconds are marked unavailable.

# Python (add to your server startup)
import httpx, asyncio, os

TOKEN = os.environ["IICP_NODE_TOKEN"]

async def heartbeat_loop():
    async with httpx.AsyncClient() as client:
        while True:
            await client.post(
                "https://iicp.network/api/v1/heartbeat",
                headers={"Authorization": f"Bearer {TOKEN}"},
                json={"node_id": "my-mcp-server", "status": "available"},
                timeout=5.0,
            )
            await asyncio.sleep(30)
3

Handle incoming IICP task requests

IICP clients POST to POST /v1/task on your endpoint. Extract the MCP tool name from the intent URN, dispatch to your MCP server, and return the result.

# Minimal FastAPI bridge — add to your existing MCP server
from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel
import httpx, re, os

app = FastAPI()
TOKEN = os.environ["IICP_NODE_TOKEN"]

class IicpTask(BaseModel):
    task_id: str
    intent: str          # "urn:iicp:intent:mcp:<tool>:v1"
    payload: dict        # {"tool_name": str, "arguments": dict}
    auth: dict           # {"node_token": str}

@app.post("/v1/task")
async def handle_task(task: IicpTask, authorization: str = Header(...)):
    if task.auth.get("node_token") != TOKEN:
        raise HTTPException(401)

    # Extract tool name from intent URN
    # urn:iicp:intent:mcp:<tool_name>:v1  →  <tool_name>
    tool_name = task.payload.get("tool_name") or re.search(
        r"urn:iicp:intent:mcp:(.+):v1", task.intent
    ).group(1)

    # Dispatch to your MCP server (JSON-RPC 2.0)
    async with httpx.AsyncClient() as client:
        resp = await client.post(
            "http://localhost:3000/mcp",   # your MCP server
            json={
                "jsonrpc": "2.0", "id": task.task_id,
                "method": "tools/call",
                "params": {"name": tool_name, "arguments": task.payload.get("arguments", {})},
            },
        )
    result = resp.json()

    if "error" in result:
        return {"status": "error", "error": {"code": "backend_error", "mcp_error": result["error"]}}
    return {"status": "success", "result": result["result"]}

@app.get("/iicp/health")
async def health():
    return {"status": "available", "node_id": "my-mcp-server"}

That's it. Your MCP server is now discoverable in the IICP mesh under urn:iicp:intent:mcp:tools/call:v1 — clients can find it via GET /api/v1/discover?view=public&intent=urn:iicp:intent:mcp:tools/call:v1.

MCP tool → IICP intent URN mapping

MCP tool nameIICP intent URN
(any tool, generic dispatch)urn:iicp:intent:mcp:tools/call:v1
bashurn:iicp:intent:mcp:bash:v1
read_fileurn:iicp:intent:mcp:read_file:v1
write_fileurn:iicp:intent:mcp:write_file:v1
web_searchurn:iicp:intent:mcp:web_search:v1
computer_useurn:iicp:intent:mcp:computer_use:v1

Custom MCP tools use the pattern urn:iicp:intent:mcp:<tool_slug>:v1. Slashes in tool names are permitted (e.g. tools/call). Full mapping details are listed in the MCP binding spec.

Security note: IICP prohibits MCP tools that give remote callers shell access or filesystem write access to the host node unless the node explicitly advertisesallow_remote_inference: true and the caller is a verified CIP participant. The bash and write_file intents follow the documented urn:iicp:intent:mcp:<tool>:v1 pattern, but IICP routers MUST refuse them unless the security policy is explicitly configured. See node setup for policy configuration.
⚠ A2A and ACP binding patterns are scoped but not yet implemented — no spec or prototype exists yet.

Binding status: documented = spec exists; planned = scoped, in the backlog; research = exploratory, no spec yet. Propose a new binding via email ↗.