Skip to main content
RCP is a deliberate sibling of MCP and ACP, not a competitor. It reuses their proven JSON-RPC conventions so an implementer of one is instantly productive in another.

​
What RCP shares

JSON-RPC 2.0 framing

Requests with id, notifications without.

initialize + capabilities

A server advertises exactly what it supports; clients gate calls on capabilities.

_meta extensibility

Additive fields ride in _meta without breaking the wire.

Cursor pagination

The same opaque-cursor model, plus Markdown-first human text and reused MCP JSON representations where sensible.

​
Why retrieval needs its own protocol

The honest challenge: MCP already lets a server expose a search(query) → documents tool — why a second protocol? If retrieval were a single opaque function call, it would not deserve one. It is not. An MCP tool is a typed function (opaque name, one argument blob in, one content blob out); RCP is a domain contract over the retrieval pipeline. Six things a flat tool call cannot express — and that every client/server would otherwise re-invent as bespoke glue:
Transform → recall → fuse → rerank → diversify → cite, with each stage independently negotiated at initialize and driven either as one server-run retrieve or stage-by-stage in an agentic loop. A tool.call cannot expose candidateK ≥ topN ≥ k, MMR lambda, fusion strategy, or per-stage scores, and gives a client no way to discover that a tool even supports reranking.
candidateK ≥ rerank.topN ≥ k is a checkable constraint the wire enforces. In a tool call these are three undocumented integers whose relationship lives only in prose a model has to guess at.
A Hit carries a stable id, a score on a declared scale, confidence ∈ [0,1], granularity (unit/level), provenance, citation, and trust. Standard IR metrics (nDCG, Recall@k, MRR) apply directly and portably across engines. An MCP tool flattens all of this into rendered text, discarding the ranking structure fusion and offline evaluation depend on.
Dense and BM25 scores are not comparable; merging them correctly needs rank-level RRF. RCP defines this so a federating gateway can fan out and fuse. Independent MCP search tools return incomparable prose a client cannot fuse without knowing each tool’s internal scoring.
Recall-then-rerank is latency-shaped; RCP streams notifications/progress with stage labels and can emit incremental hits. A tool call is request/response — the caller waits for the whole pipeline blind.
Retrieved content is untrusted data moving toward an LLM’s context, dominated by indirect prompt injection. RCP carries trust.injectionSuspected/sanitized per hit; a generic tool’s text output has no place to put a per-passage trust signal. See Security.
The litmus test: if your need really is one opaque query → text call — no reranking, no fusion, no citations, no evaluation, no per-hit trust — then an MCP tool is the right tool; use it. RCP is for when retrieval is a system rather than a function, which is what production RAG has become. The two compose rather than compete: a gateway can even expose an RCP retrieve as an MCP tool for one-shot consumers — the structured protocol degrades gracefully to the flat one, but not the reverse. RCP gives the retrieval layer the same first-class, vendor-neutral contract that MCP gave tools and ACP gave agents.

See the whole stack

Where RCP, MCP, and ACP sit in a modern agent architecture.