The problem I'm trying to solve

The MCP specification warns that tool descriptions "should be considered untrusted, unless obtained from a trusted server." But the ecosystem doesn't define what "trusted" means or how to verify it.

With 10,000+ MCP servers now published, I keep running into the same questions:

• Who actually published this server?
• Did the tool metadata change since my security review?
• What dependencies does it carry, and are any vulnerable?
• What capabilities does this tool require?

I couldn't find existing work that addresses this gap directly. ETDI covers runtime authorization well, but static provenance at publish/install time seems underspecified.

What I'm proposing

TBOM (Tool Bill of Materials): a signed manifest that binds an MCP server release to:

• Definition digests - SHA-256 over canonicalized tool metadata, enabling drift detection
• Artifact digests - Package integrity verification
• Provenance identifiers - Publisher identity via cryptographic signatures
• SBOM references - Links to CycloneDX/SPDX for dependency/vulnerability correlation
• Capability declarations (optional) - For policy enforcement

The core idea: extend SBOM thinking to the semantic layer that agents consume, not just the code layer.

Design decisions I'm uncertain about

1. Server-scoped vs. tool-scoped - I chose server-level manifests because that's how packages are distributed. But maybe individual tool attestations would be more useful?

2. Canonicalization - Using RFC 8785 (JCS) for deterministic hashing. Is this the right choice, or does the community prefer something else?

3. Signing model - I propose supplier/registry/enterprise signature roles. Is this overcomplicated for the current ecosystem maturity?

4. Registry integration - The spec suggests mechanisms, but I don't know enough about how the MCP Registry preview works to know if these are realistic.

What TBOM explicitly doesn't solve

I want to be upfront about limitations (Section 12 of the RFC covers this in detail):

• Doesn't verify tool behavior matches descriptions (semantic gap)
• Doesn't prevent malicious-but-signed tools
• Doesn't address key compromise scenarios
• Doesn't solve runtime attacks (that's ETDI's domain)
• Doesn't create trust from nothing, just makes existing trust verifiable

This is a transparency and integrity control, not a safety guarantee.

What I'm sharing

• RFC specification (30 pages, RFC 2119 conformant): [PDF](https://github.com/jlov7/tbom-rfc/raw/main/RFC/TBOM-Specification-v1.0.2-Draft-202602.pdf)
• Reference implementation: https://github.com/jlov7/tbom-rfc
• JSON Schema for TBOM v1.0.2
• Signing keys document schema
• Test vectors for interoperability

What I'm looking for

Genuinely: feedback. I've been working on this mostly in isolation and I'm sure there are gaps I can't see.

Specific questions:

• Does this overlap with something that already exists that I missed?
• Are the schema design decisions reasonable, or fighting against how the ecosystem actually works?
• Is this worth pursuing through the SEP process, or better as an independent standard?
• What's missing that would make this actually useful?

Happy to iterate based on input. Would rather get it right than get it published.