Roadmap

What's actually done vs. what's still open, across the protocol design and the reference SDK. RCP is v0.1, in active design.

Protocol (design)

GET <manifest-url> → { rcpVersion, auth, tools[] } manifest format.
Two roles defined — Client and Server, no third “host” layer, no persistent connection.
Auth — three modes specified: none, header, oauth2 (same RFC stack MCP’s own auth uses).
Resolvers — a client-side-only mechanism for values that must never reach the model.
Client-injected headers — attaching headers with no manifest correspondence at all.
Security & trust principles adapted from MCP’s.
oauth2 — designed, not implemented by any SDK yet.
Per-tool auth overrides — specified in the schema, but no SDK actually executes it yet.
A skills/resources-equivalent primitive — deliberately out of scope for v0.1.
Open questions: rcpVersion in the body vs. a header; the default when a resolver can’t produce a value; a naming convention for commonly-resolved params; whether a server ever needs to push a manifest-changed notification.

discover() — fetch, schema-validate, version-check, strip resolver-bound params.
call() — template rendering, resolver filling, auth + header attachment, response mapping.
Auth: none, header.
Resolvers.
Client-injected headers.
Pluggable logging (silent by default; never logs secrets, headers, bodies, or resolved values).
describeManifest() — human-readable printout of what a server is asking for.
oauth2 — throws a clear “not implemented” error rather than doing nothing.
Per-tool auth overrides — throws a clear “not implemented” error rather than using the wrong credentials.

defineTool() + t.arg() — build a manifest tool entry in code from a zod schema.
zod → params derivation (type, required, description).

39 tests passing (schema, template engine, response mapper, client, server).
Clean tsc --noEmit, tsup build (ESM + CJS + .d.ts).
End-to-end example (examples/basic) verified working live.
API docs for both entry points (docs/client.md, docs/server.md).
Architecture diagrams (root README).
Lint/formatting setup (eslint/prettier) — flat eslint.config.js (typescript-eslint recommended) + .prettierrc.json, wired to lint/format/format:check scripts.
Published to npm — rcp-sdk is live.
Pushed to a GitHub remote — hasanraiyan/rcp.

examples/express — an Express REST API + one route serving an RCP manifest via defineTool(). Server-only; no AI/model code.
examples/openai-client — discovers a manifest and runs an OpenAI tool-calling loop against it. Client-only; no Express/FastAPI code. Installs rcp-sdk from the real npm package.
Framework adapters (rcp-sdk/adapters/openai, /gemini, /langchain, ...) so the manifest-to-tool-schema conversion currently hand-rolled in examples/openai-client doesn’t have to be re-derived by every consumer — tracked in issue #1.
A Python/FastAPI server example — would double as proof that an RCP server needs no SDK in any language.

A second-language reference SDK (e.g. python/) — the repo is structured to support this, but nothing has been written.
Any tooling around the skills/resources idea, if it turns out to be needed.
A CLI (e.g. rcp inspect <url> wrapping describeManifest()) — not planned, just a natural extension if it’d be useful.