Skip to main content
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.

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.0 or tool:greet@)
  • tool.to_mcp_tool() — the protocol-facing tool object that MCP clients see, including the input schema
Combine them into a payload, serialize deterministically, and hash:
The fingerprint is stable across process restarts as long as the tool’s name, version, and input schema remain the same.

Why tool.key?

tool.key is FastMCP’s canonical component identity. It encodes the component type, identifier, and version into a single string:
Using 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:
Common variations:

Detecting Schema Drift in CI

Store fingerprints as artifacts and compare between deployments:
Run 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.