Downstream systems like routers, gateways, and audit loggers often need to detect whether a tool’s schema changed between deployments. Rather than each system inventing its own JSON normalization and hashing logic, you can build stable fingerprints from FastMCP’s existing API surface. FastMCP does not define a single “contract hash” because the inclusion policy is necessarily application-specific: some systems care only about the input schema, others include the description, metadata, tags, or version. Instead, this recipe shows how to assemble a fingerprint payload from the parts you care about, then hash it deterministically.Documentation Index
Fetch the complete documentation index at: https://gofastmcp.com/llms.txt
Use this file to discover all available pages before exploring further.
The Recipe
The two key building blocks are:tool.key— FastMCP’s canonical component identity, encoding type, name, and version (e.g.tool:greet@1.0ortool:greet@)tool.to_mcp_tool()— the protocol-facing tool object that MCP clients see, including the input schema
Why tool.key?
tool.key is FastMCP’s canonical component identity. It encodes the component type, identifier, and version into a single string:
key rather than just the tool name ensures that two versions of the same tool produce distinct fingerprints, and that a tool and a resource with the same name cannot collide.
Why to_mcp_tool()?
to_mcp_tool() returns the protocol-facing representation — the shape that MCP clients actually receive. This matters because routers and gateways typically operate on the protocol layer, not FastMCP internals. The model_dump(mode="json", by_alias=True, exclude_none=True) call produces a clean, serializable dictionary using the MCP protocol field names.
Customizing the Payload
You own the inclusion policy. Add or remove fields depending on what constitutes a “contract” in your system:| Field | When to include |
|---|---|
inputSchema | Always — this is the core contract |
description | When documentation drift matters (e.g. LLM routing decisions depend on it) |
outputSchema | When downstream consumers validate response shapes |
annotations | When behavioral hints (read-only, destructive) affect routing |
_meta | When custom metadata drives policy decisions |
Detecting Schema Drift in CI
Store fingerprints as artifacts and compare between deployments:generate_manifest in CI after each build and compare against the previous run. Any differences indicate a schema change that downstream consumers should be aware of.
