Hi Product Hunt — I built ToolSeal after running into a small but important trust problem while working with MCP servers: the tools a server declares can change independently of the version or configuration a client thinks it is using. ToolSeal treats MCP capabilities like dependencies and gives them a lockfile. `toolseal lock` records a normalized `tools/list` declaration. `toolseal verify` recomputes the fingerprint and exits with code 2 when that declaration drifts. Because the normalized catalog is stored in `toolseal.lock`, ToolSeal can show exactly what was added, removed, or changed instead of only reporting a hash mismatch. The scope of v0.1 is intentionally narrow: ToolSeal detects **declared capability drift**. It does not prove that an MCP server binary is safe, that a tool behaves exactly as its schema claims, or that runtime execution is trustworthy. I’d especially value feedback on three things: * Where would you keep `toolseal.lock` — beside the MCP server, or beside the client configuration? * Would this be useful in your MCP CI/review workflow? * Which MCP client or runtime should ToolSeal integrate with next? The goal for this release is to validate whether the lockfile mental model is useful before expanding ToolSeal into anything larger.

ToolSeal v0.1

A lockfile for MCP server capabilities

A lockfile for MCP server capabilities