Skip to main content
Every RAG stack reinvents the same wire: embed, rerank, retrieve, filter, cite. Swapping a vector database, adding a reranker, or wiring in a second knowledge base means rewriting glue code. MCP standardised tools; ACP standardised agents; nothing standardised the retrieval layer that grounds them. RCP is that layer — a small, versioned, JSON-RPC 2.0 contract that a powerful engine can fully express and a thin client can fully consume.
The obvious objection: MCP already lets a server expose a search(query) → documents tool — why a second protocol? Because production retrieval is a pipeline (recall → fusion → rerank → assemble), not one opaque call. A tool.call can’t negotiate candidateK ≥ topN ≥ k, expose per-stage scores, return structured comparable Hits (so nDCG/RRF work across engines), stream staged progress, or carry a per-hit trust signal against prompt injection — it flattens all of that into a text blob.If your need really is one opaque query → text call, an MCP tool is the right tool — and the two compose (a gateway can expose RCP retrieve as an MCP tool). See the full six-axis argument in RCP, MCP & ACP.
Retrieval-augmented generation (RAG) grounds a language model in your data instead of relying only on what it memorised in training. The loop is almost always the same four steps:
  1. Embed — turn text into a vector so that passages with similar meaning land near each other in space.
  2. Retrieve — given a query, find the nearest passages (by dense vectors, sparse keywords, or a hybrid of both).
  3. Rerank — re-score just the top handful with a slower, more accurate model, so the best passage rises to the top.
  4. Cite — return the winning passages with their sources, so whatever the model writes next is grounded and checkable.
RCP is simply the standard wire for that loop: a client asks an engine to embed / retrieve / rerank / cite, and any engine — in any language — can answer. You don’t need to know the underlying math to use it; every term above is defined in the glossary.
RCP is transport-free and language-agnostic. A server is any process that reads newline-delimited JSON on stdio or accepts HTTP POSTs. A client is anything that can send one.

​
The four pillars

Capability-negotiated

A server advertises exactly what it can do (embed, sparseEmbed, multiVector, rerank, retrieve, transform, graph, index, catalog). Clients gate calls on capabilities — no probing, no surprises.

SOTA-complete

Hybrid (dense + learned-sparse) search, ColBERT/ColPali late interaction, SPLADE, multi-stage rerank cascades, MMR diversification, contextual retrieval, GraphRAG (local/global/drift), agentic multi-hop, citations, streaming, and metadata filtering are all first-class.

Transport-free

JSON-RPC 2.0 over newline-delimited stdio or HTTP. If it can read a line and parse JSON, it can speak RCP.

Composable

A registry (rcp.json) or a catalog-capable aggregator lets a client target one backend (Selector) or fuse many (Federation).

​
Who is this for?

Engine authors

Implement one server and reach every RCP client.

Agent & IDE builders

Pull grounding context from any engine without bespoke adapters.

Platform teams

Federate several knowledge bases behind one uniform wire.

​
A ten-line taste

The whole protocol is JSON-RPC. Here is a retrieve round-trip:

​
Next

Architecture

Roles, the pipeline model, and how RCP sits beside MCP and ACP.

Quickstart

A working engine and client in under five minutes.