Requests, discovery, and protocol versions

A client first discovers what a server offers. It can list tools, resources, and prompts, then call or read one of them using the declared contract.

Discovery is a runtime exchange, not a promise that every connected server has the same surface forever. A host can initialize a connection, learn the server’s advertised capabilities, list a category, and then make a request using one returned name and schema.

MCP uses JSON-RPC messages, but the SDK handles the wire details. Your application code registers capabilities and returns their results.

The protocol changes over time. A revision identifies the contract a peer supports. Current servers should document which SDK and protocol revision they target.

Keep three versions separate:

• the MCP protocol revision negotiated by peers
• the SDK package version used to implement a client or server
• your server application’s own release version

Upgrading an SDK can change application-facing APIs without changing your capability names. Changing the protocol can affect negotiation and wire behavior. Changing your server can alter tool semantics even when both other versions stay fixed.

This course targets the TypeScript SDK v2 line and the final 2026-07-28 protocol. The v2 server package is still marked beta while its API settles, so pin and review the version before production use.

Record all three versions in diagnostics. Test initialization, discovery, one valid call, one invalid argument, and an older supported peer before upgrading production. Avoid writing business logic against raw JSON-RPC details when the SDK already owns them; keep your capability handlers separable so an SDK migration does not rewrite the domain code.

Inspect one server’s startup or debug output and identify its protocol, SDK, and application versions. If one is absent, decide where you would expose it safely.