RCP vs MCP
Not a replacement for MCP — a narrower protocol for a narrower, much more common case.
MCP is the right answer when you want rich, stateful capabilities — resources a user browses, prompts a user picks, elicitation or sampling mid-call, a long-lived connection. That power has a cost: implementing an MCP server means implementing JSON-RPC, a transport, and the base protocol’s negotiation flow, even if all you actually have is “call this REST endpoint with this shape.”
RCP is deliberately not trying to be MCP-but-open-source. It’s for the much narrower case: “I have a REST API. I want an AI application to call some of its endpoints as tools, and I don’t want to run anything besides my existing API plus one more route that returns JSON.” If you outgrow that, reach for MCP instead — that’s a real signal, not a gap RCP tries to fill.
| RCP | MCP | |
|---|---|---|
| Connection | Stateless HTTP request | Persistent session |
| Roles | Client, Server | Host, Client, Server |
| Transport | Plain HTTP | JSON-RPC over stdio or Streamable HTTP |
| Server requirement | Your existing REST API, or a static JSON file | A dedicated protocol server |
| Hiding a param from the model | Resolvers — a client-side mechanism, nothing declared on the wire | No equivalent — inputSchema is plain JSON Schema, every property is model-fillable |
| Resources / Prompts / Sampling / Elicitation | Out of scope for v0.1 | Supported |
| Best fit | You already have endpoints to expose | Rich, stateful capabilities |
When to use RCP
- You already have a REST API and just want a model to call a handful of its endpoints.
- You don’t want to stand up or operate a separate protocol server — the manifest can be one more route on the API you already run, or even a static JSON file behind a CDN.
- Every call is naturally one-shot: fetch, call, get a response back. Nothing needs the model to browse a list of resources or pick from prompt templates mid-conversation.
- You need to keep a value — a tenant id, the current user, an internal key — completely out of the model’s hands. That’s what resolvers are for.
- You want any client to be able to integrate by reading JSON, with no SDK dependency required on the server side at all.
When to use MCP instead
- The model needs to browse resources (files, records, search results) as a distinct concept from calling a function.
- You want to offer prompt templates the user selects, not just tools the model invokes.
- A call needs to pause mid-flight and ask the user something (elicitation), or the server needs to sample the model itself.
- The integration benefits from a long-lived, stateful session rather than independent stateless requests.
What RCP borrows from MCP on purpose
- The same three auth tiers —
none,header,oauth2— and the same RFC stack foroauth2, so a client that already speaks MCP’s OAuth flow needs no new logic to also speak RCP’s. - The same security posture: registration is consent, tool descriptions are untrusted content, secrets are client-side only.
- The same explicit-over-implicit stance on version negotiation.
What’s explicitly out of scope for v0.1
- Resources, Prompts, Sampling, Elicitation, Roots — if real demand shows up, these would be additive, opt-in extensions layered on the same manifest+HTTP model, not a rewrite of it.
- A bidirectional/streaming transport. Every RCP interaction is a plain request/response over HTTPS.
- A server-side SDK requirement. The spec is fully defined by “does
GET <manifest-url>return valid JSON matching the schema.”
See the full breakdown of what’s built and what’s still open on the RCP roadmap.