modelcontextprotocol/experimental-ext-tool-annotations

Watch

Sam Morrow 0be45d9b95

Record SEP-1913 feedback as cited open questions; clarify untrusted vs openWorldHint

Enrich the base extension docs so the early review history is preserved rather
than erased by the narrow first cut:

- trust-annotations.mdx: add a normative subsection distinguishing result-level
  untrusted from tool-definition openWorldHint (the SEP-1913 #711 distinction).
- open-questions.md: capture the sensitivity-field shape debate, enforcement-vs-
  advisory risk, per-block byte ranges, taint persistence, and sequence-shape,
  each attributed to the reviewer who raised it; add a Naming (under review)
  section for the contested field/extension names.
- related-work.md: add verified FIDES alternatives (Permissive IFC 2410.03055,
  AirGapAgent 2405.05175, CaMeL 2503.18813) and a schemes-vs-host-architectures
  distinction.
- decisions.md: log the scheme/architecture boundary and the feedback-capture
  decision.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

2026-06-16 10:29:11 +02:00

6.1 KiB

Raw Blame History

Open questions

Tracked here rather than in the spec drafts, so the drafts stay non-temporal.

Cross-cutting

Where does the policy-enforcement engine live across different user universes (cross-org, cross-domain)? Engines work well within one universe; cross-domain is the hard case. (IG 2026-05-28.)
Cross-domain integrity verification — is asymmetric crypto for domain identity in scope for a future extension, or out of scope entirely? CLI tools remain a persistent gap for enforcing these constraints.
evidenceRef.type registry — who curates the list of well-known profile types, and how do we coordinate with attestation SEPs (e.g. SEP-2787) so values don't collide?

trust-annotations

Shape of the sensitivity signal. Is sensitive: boolean the right single coarse signal, or does the narrow cut overcorrect? The SEP-1913 thread rejected a linear sensitiveHint: low|medium|high because sensitivity is set-theoretic, not a scale (@JustinCappos: medical results to a mail MCP and a card number to a payment MCP, but neither crossed). Reviewers then pushed for org-defined vocabularies (@olaservo, @Mossaka) and a class+regulatory pairing such as confidential:hipaa (@krubenok). Against that, @localden warned a baked-in taxonomy is hard to remove. Open: keep the boolean and let the data-class.v1 scheme carry the taxonomy, or also expose a structured escape hatch on the wire so regulated flows are expressible without a scheme?
Enforcement vs. advisory. A self-declared sensitive: true from a poorly-configured or malicious server could create a false sense of security (@localden). docs/trust-model.md puts verification in registries; is that enough without a normative client-side check path?
Content-block-level vs. result-level attachment — does the draft need a worked multi-result example before it's implementable? Per-block annotation with byte/codepoint ranges was requested so clients can highlight the flagged span, not just the whole result (@connor4312).
list_changed: confirmed response-level annotations don't participate; revisit only if trust vocabulary ever attaches to tool definitions.

Naming (under review)

These are explicitly unsettled and are being reviewed against the SEP-1913 record before any rename lands:

Umbrella name. The original SEP was "Trust & Sensitivity Annotations" — two axes (integrity and confidentiality). trust-annotations reads as the integrity half; does the name hide the sensitive (confidentiality) half?
untrusted vs openWorldHint. Same concept, different layer (result vs. tool definition). Share a name/vocabulary, or keep them deliberately distinct?
evidenceRef.type vs evidenceRef.scheme. The repo calls these values "schemes" (schemes/); the selector field is type. Align the field name?
evidenceRef itself. Its ancestor is @pshkv's decision_ref / attestation_ref / policy_profile. Is evidenceRef the clearest umbrella, or should the pointer name the kind of thing it references?

action-metadata

Coexistence vs. replacement of legacy destructiveHint / readOnlyHint / idempotentHint / openWorldHint.
Open strings vs. closed enums for destination / source / sensitivity.
Does requiresReview need a machine-readable reason for good client UX?

ifc-fides (scheme)

Inline _meta.ifc for low-friction adoption vs. always behind evidenceRef.
GitHub Enterprise internal repo visibility → public/private mapping (audience is the whole org, broader than collaborators; resolved host-side).
Reader-set resolution is host-side by design — confidentiality join across two private sources needs the intersection, which the opaque wire marker can't express. Is the 3-step host resolution enough, or do some hosts need a standard evidenceRef.ref shape to locate the originating system?

Parked (SEP-1913 umbrella)

maliciousActivityHint — killed in review on three grounds (@connor4312): it can't be resolved before execution for dynamic tools; a boolean gives no UX or ranges; and clients won't trust a server's self-report of its own maliciousness. If it returns, it is per-ContentBlock with spans, driven by the host's own detection, not a server-attested boolean.
Taint persistence across the store boundary — a label must survive round-tripping through storage: write a card number to a file, read it back, and the sensitivity label must not silently disappear (@JustinCappos). This is a propagation property no single response annotation can guarantee on its own; it needs the taxonomy and evidenceRef stable first.
Session-level propagation rules — escalation semantics and the sequence-shape gap: "this was call N in a flagged sequence" has no response annotation surface today (marras0914). A candidate evidenceRef scheme could carry a sequence assertion; tracked in schemes/README.md.

6.1 KiB Raw Blame History