Extension proposal: io.modelcontextprotocol/display-templates

README.md

@@ -43,6 +43,7 @@ See [docs/decisions.md](docs/decisions.md) for the decision record and
 | :--- | :--- | :--- | :--- |
 | [`io.modelcontextprotocol/trust-annotations`](specification/draft/trust-annotations.mdx) | Draft skeleton | **Primary extension.** A small, scheme-agnostic client-facing data-classification vocabulary (`sensitive`, `untrusted`) on result `_meta`, plus an optional `evidenceRef` pointer slot that carries richer payloads out-of-band. | Python SDK: [`kapil8811/mcp-trust-annotations`](https://github.com/kapil8811/mcp-trust-annotations) (138-test suite, healthcare demo, LLM usability study). |
 | [`io.modelcontextprotocol/action-metadata`](specification/draft/action-metadata.mdx) | Draft skeleton | `inputMetadata` / `returnMetadata` / outcome classifiers (incl. `requires_review`) on `ToolAnnotations`, describing where inputs go, where outputs originate, and what real-world effects a tool can cause. | Originally [SEP-2061 (Action Security Metadata)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2061) by [@rreichel3](https://github.com/rreichel3) — closed 2026-06-13 in favour of this extension; worked example `read_drafts` / `list_inbox` / `send_email`. |
+| [`io.modelcontextprotocol/display-templates`](specification/draft/display-templates.mdx) | Draft | Call-side display `template` on `Tool` `_meta` (branch-scoped inside `oneOf`/`anyOf` subschemas) and result-side server-rendered display `text` on content-block `_meta`: one legible line for the human watching, compact encodings for the model. Includes normative rendering semantics and a call-side omission indicator. | Python (stock SDK 2.x): [`maxiboch/soundboard`](https://github.com/maxiboch/soundboard) — mixer / cue transport / SFX-synth server plus a renderer implementing the normative substitution, branch-matching, and omission-indicator rules. |
 
 Each extension is proposed in its own pull request so it can be reviewed and
 graduate on its own clock.

docs/decisions.md

@@ -164,3 +164,10 @@ capable but are not universally implemented, so they cannot be the floor —
 layering the two gives universal actionability without capping what advanced
 hosts can do. This also answers the "boolean vs. richer taxonomy" tension from
 SEP-1913 review: it is not either/or, it is both, at different layers.
+
+- 2026-08-04 — display-templates: wire carrier is the extension-namespaced
+  `_meta` key (`io.modelcontextprotocol/display-templates`), not new
+  `ToolAnnotations`/`Annotations` fields: matches the trust-annotations
+  precedent in this repo, follows SEP-2133's independent-graduation path,
+  and is the only carrier that survives the Python SDK 2.x strict models,
+  which strip unknown annotation keys at both serialization ends.

docs/open-questions.md

@@ -70,6 +70,19 @@ record before any rename lands:
 - Open strings vs. closed enums for `destination` / `source` / `sensitivity`.
 - Does `requiresReview` need a machine-readable *reason* for good client UX?
 
+## display-templates
+
+- **Branch-key spelling.** Should the branch-scoped key inside `oneOf`/`anyOf`
+  subschemas be spelled `x-mcp-display-template`, following the
+  [SEP-2356](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2356)
+  precedent for schema-embedded extension keywords, rather than the reverse-DNS
+  spelling in the draft?
+- **Result-side attachment point.** Per-content-block only, or also permitted at
+  the `CallToolResult` level (one string per result) for servers whose results
+  are multi-block but whose human summary is singular?
+- **Inner key naming.** `template` / `text` versus more explicit spellings
+  (`callTemplate` / `displayText`).
+
 ## ifc-fides (scheme)
 
 - Inline `_meta.ifc` for low-friction adoption vs. always behind `evidenceRef`.