Governance starts with a capability inventory

The mechanism

A capability catalog is useful when it describes what tools can actually do. Record each server’s owner, source, version, execution boundary, data destinations and permitted effects. A marketplace listing or a familiar logo is not an approval decision.

Separate discovery from admission. A host may be able to discover a server that organizational policy does not permit it to execute. Review dependency updates and changes to tool schemas, descriptions and implementations because each can alter behavior without changing a friendly server name.

This handbook proposes governance records; it does not claim that a particular enterprise product enforces them. Map every proposed control to a real mechanism, accountable owner and test before calling the integration governed.

Worked example

This is a catalog template for the synthetic server. “Proposed” is intentional. Fill in observed package versions and approval evidence only after review. A useful inventory is small enough to keep current and precise enough to revoke one capability.

{"server":"parcelops-study","owner":"to_be_assigned",
 "source_review":"pending","protocol":"2026-07-28",
 "tools":[{"name":"lookup_incident","effect":"read synthetic fixture"}],
 "network_destinations":[],"credential_requirement":"none",
 "admission":"proposed","review_evidence":null}

Practice: predict, inspect, explain

Offline exercise. Add an update that introduces a write tool and a new outbound destination. Decide which catalog fields change, who reviews them and what negative tests must run before admission. Then describe revocation: how does an already-running host learn that a capability is no longer allowed?

Expected observation: approval is a lifecycle, not a one-time checkbox. A schema diff alone may miss implementation changes, while a source review alone may miss a misconfigured runtime. Link the inventory to actual artifacts and configuration versions.

Troubleshooting and trade-offs

If no one owns a server, incident response and updates become ambiguous. If allowlists match only display names, a renamed or impersonated service can confuse policy. Use stable configured identities and artifact provenance. Avoid broad claims such as “enterprise secure” unless the report identifies enforcement, coverage and remaining gaps.

Interview practice

Completion check

Produce a change-review record for one new capability, with a concrete revocation path.

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.

• Official documentation: Client best practices
• Official documentation: Security best practices
• Official documentation: Local server security