Strong proposal — the gap between "what a tool is named" and "what a tool actually does" is where most MCP security risks live today.

A few thoughts on how this interacts with the agent identity/trust layer:

1. Security metadata enables trust-differentiated access

With these fields declared, a server can make access decisions based on the calling agent's trust level combined with the tool's risk profile. Example:

• send_email with outcomes: ["irreversible"] + destination: ["external"] → only accessible to agents with trust level ≥ 4
• read_drafts with outcomes: ["benign"] + destination: ["none"] → accessible to any authenticated agent

This creates a risk matrix: tool security metadata × agent trust score = access decision. Without either dimension, you're either blocking everything or trusting everything.

2. Source provenance maps to agent attestation

The source field ("where returned data originates") has a natural extension: where does the agent originate? An agent with verified provenance (attested identity, behavioral history, cross-platform verification) calling a high-sensitivity tool is fundamentally different from an unknown agent making the same call.

Today 100% of ~2,000 scanned MCP servers lack authentication entirely (per the AIP ArXiv paper 2603.24775v1). This SEP, combined with agent identity verification, would close that gap.

3. Suggestion: add a requiredTrustLevel field

{
  "send_email": {
    "outcomes": ["irreversible"],
    "destination": ["external"],
    "sensitivity": ["personal"],
    "requiredTrustLevel": 4
  }
}

This would let tool authors declare the minimum trust level needed, making security metadata actionable rather than just informational. Trust providers (SATP, AgentScore, etc.) could then supply the verification.

Would be interested in collaborating on the trust-level extension if there's appetite for it.