File an issue
Report a spec ambiguity, an SDK bug, or a gap in the docs. Ambiguities in a
protocol spec are bugs — please report them.
Open a pull request
Fix a typo, tighten wording, add a test, or implement a feature. Small,
focused PRs merge fastest.
Ways to contribute
Implement an engine
Wrap your retrieval stack behind an RCP server and it works with every RCP
client. Prove it with the conformance suite.
Write an SDK
A new language binding is the highest-leverage contribution. Mirror the
existing SDKs — same wire, same method names, same errors.
Sharpen the spec
Clarify normative language, add examples, or close an edge case. The
specification is the source of truth.
Improve the docs
Every page in this site is an MDX file under
docs/. Fix a rough
explanation, add a diagram, or write a guide.Repository layout
The single source of truth is the spec and schema at the repo root; everything else follows from them.Local setup
Each SDK is self-contained and dependency-free. Build and test the one you are changing:std::expected). The Python and
Node SDKs need only their language runtime — no compiler, no packages.
The bar for a change
Every change must keep the four SDKs byte-for-byte interoperable. Before you open a PR:1
Run the conformance suite
Point the runner at your engine over stdio or HTTP. A reference engine must
pass 10/10.
2
Cross-drive the other SDKs
If you touched the wire, confirm a client in one language still drives a
server in another. The SDK test suites already include cross-language cases.
3
Update the spec and schema together
A wire change is not done until
spec/rcp-1.0.md and schema/rcp-1.0.json
both describe it — and the docs are regenerated.4
Keep it additive
Within RCP/1, new behaviour must be capability-discovered, never a
breaking change. See Governance.
Have an idea that changes the wire? Open a discussion issue before writing
the code. Governance explains how proposals move from
idea to spec — and how to ship vendor-specific behaviour today via
_meta
without changing the spec at all.