A custodial email, a stablecoin wallet, a credential vault, and an agent-ready API — all at one @cai.com address.
Good checklist. On keeping tool descriptions static, I'd also pin them on the client side: hash each tool's name and description when someone approves the server, and re-prompt when the hash changes. Otherwise "static" only protects you from servers that behave. Same logic for annotations like readOnlyHint, the spec treats them as hints, so the real enforcement has to be your own scopes and server-side checks, which you already say in the last group.
Keeping tool descriptions static is the check I see skipped most, and it's easy to enforce: hash the tool list at release time and have a CI test fail if the served descriptions or schemas ever differ from the pinned hash. On rate limiting, limiting per tool and per IP still leaves room for one agent session to fan out across many cheap read calls, so a per-session budget on total calls helps too. And for "return only what the output schema promises", validating responses against the schema on the server before sending catches accidental leaks of internal fields when the underlying data model grows.
Cai
Solid list, especially the rate limiting and resource path traversal points. One area that could use more attention: provenance verification. When you discover an MCP server in a directory, how do you verify it was published by who it claims and hasnt been tampered with? For production agent workflows this is a real blind spot code signing plus identity attestation at the discovery layer would close it.