The mechanism
Every modern request carries its protocol version and client capabilities inside params._meta. That makes the request understandable without a preceding negotiation session. Client information is useful for diagnostics but does not authenticate the caller.
Servers implement server/discover; a client may use it to inspect supported versions and capabilities before making other requests. Discovery is optional for a modern client that can handle an unsupported-version response directly. The server’s display name and instructions are self-reported information, not a security certificate.
ParcelOps begins with no client capabilities because our first lookup does not need user elicitation. Advertising a capability you cannot handle creates a false contract. The server should only ask for client features that the request actually declares.
Worked example
This is a complete 2026-07-28 JSON-RPC request fixture. The numeric ID correlates a response with this attempt. A discovery result includes resultType: "complete", supportedVersions, capabilities and cache hints. Inspect those fields before presenting a server’s tool list to a user.
{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{
"_meta":{
"io.modelcontextprotocol/protocolVersion":"2026-07-28",
"io.modelcontextprotocol/clientCapabilities":{},
"io.modelcontextprotocol/clientInfo":{"name":"parcelops-study","version":"0.1"}
}}}Practice: predict, inspect, explain
Offline exercise. Save the fixture in a scratch file and parse it with a JSON parser. Remove one required metadata field and predict which validation layer should reject it. Next imagine a result claiming the server is called “Trusted Administrator”. Does that change its permission to read private incidents?
Expected observation: a display name changes a label, while the authenticated origin and configured trust policy determine authority. Write an acceptance checklist for version compatibility, capability support and identity verification as three independent checks. No connection or account access is needed for this exercise.
Troubleshooting and trade-offs
A discovery response may be cached, so attach an observation time to diagnostics. A changed capability list should invalidate assumptions before the next invocation. If a host accepts an instruction embedded in discovery that asks it to export credentials, the problem is a trust-boundary failure, not successful discovery. Treat server instructions as lower-trust content subject to the host’s policy.
Interview practice
Why include capabilities on each request?
A stateless handler can determine the features available for that request without relying on a preceding session. Different requests may therefore declare different supported client features.
Can serverInfo establish trust?
No. It is self-reported display and diagnostic information. Trust depends on the configured server origin, software provenance, authenticated identity and authorization policy.
Completion check
Write the required metadata from memory and explain what discovery proves and what it cannot prove.
Sources and version notes
This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.