Quick Reference Cards

1. Tool Design

• Name the tool from the user’s point of view.
• Prefer flat, concrete parameters.
• Keep descriptions short, specific, and operational.
• Return enough structure for the next step.
• Make failure messages suggest recovery, and list every problem at once.

→ ch06

2. Choosing: MCP, Local or Remote, Tool or Resource, Auth

Use the decision trees in Appendix L: should this be an MCP server, local or remote, tool/resource/prompt, which auth pattern, which client registration, and whether a tool needs approval.

3. 2026-07-28 in Five Lines

• No initialize: every request carries its version and capabilities in _meta.
• server/discover replaces the handshake’s answer; unsupported versions get -32022.
• No protocol sessions: cross-call state is a server-minted handle.
• The server never calls the client: it returns InputRequiredResult, and the client retries (MRTR).
• Change notifications arrive on subscriptions/listen; DCR, Roots, Sampling and Logging are deprecated.

→ Appendix A §Migrating, ch29

4. Release Gate

• auth tested end to end, including a 401 without a token
• approvals make sense and annotations are honest
• logs and alerts exist
• readiness means dependencies are actually usable
• one rollback path is rehearsed
• one hostile-path test has been run
• first release stays narrow on purpose

→ Appendix F, ch22

5. Common JSON-RPC Errors

→ Appendix A §Error Codes

6. Performance Reminders

• the cleanest optimization is often a smaller tool surface
• large responses cost both latency and tokens
• cache stable reads, not risky writes
• measure end-to-end workflow success, not just server latency

→ ch13

7. Multi-Tenant Safety

• tenant comes from trusted identity, not prompts
• cache keys include tenant and environment
• background tasks preserve tenant context
• logs are useful without leaking sensitive payloads

→ ch25

8. Incident Triage

• what failed?
• for whom?
• since when?
• what changed?
• what safe fallback exists?

→ ch24, Appendix E