Document the `_meta` extension surface (rider pattern) in the wire-format docs

[YE-YI7]

Following @b-gutman's production note in modelcontextprotocol/modelcontextprotocol#2127: on an 810-pack multi-server host, the _meta reverse-DNS "rider" pattern is already the de-facto extension surface — several independent extensions ride it without touching the core card. Worth stating that explicitly in the wire-format docs so the next wave of implementers copies the pattern instead of trying to widen the core.

The three live _meta rider extensions, neutrally:

• mcp-pay — payment
• faf (@Wolfe-Jam) — project context (IANA-registered artifact link)
• ASM (@calebguo007) — value/selection metadata (pricing, SLA, quality, and invocability incl. an agent_completable_setup signal) for the "which of these N capable servers do I pick" question

All three deliberately stay out of the core card — capability / auth / transport is the card's job.

Proposal: a short "Extension surface" section in the wire-format doc stating (a) _meta reverse-DNS keys are the intended home for adjacent concerns, and (b) the core card stays thin — with these three as live examples. It prevents core-widening and gives implementers a pattern to copy.

Happy to draft the section, or just provide the ASM row.

---

Disclosure: drafted with AI assistance (Claude); substance directed and reviewed by @calebguo007.

[YE-YI7]

Update: the rider authors have started aligning on the mechanism — @Wolfe-Jam framed it in Wolfe-Jam/faf-server-card-ref#1: align on how a rider attaches to _meta, keep payloads distinct (context vs value vs payment staying separate is the feature). Seeding the proposed section here so it can be edited in one place.

Draft — "Extension surface (_meta riders)":

A rider attaches an adjacent concern to a Server Card without widening the core. Shared mechanism rules:

1. Reverse-DNS _meta key — one namespaced key per rider; collision-free.
2. Self-describing value — a thin inline object, or a deterministic link to a typed (media-typed) external artifact; resolvable cold; never duplicates core-card fields.
3. Runtime consistency — the same _meta is returned by initialize; discovery and protocol must not contradict (re Add a normative requirement that a Server Card MUST NOT contradict the server's actual runtime behavior #23).
4. Provenance + freshness — declare when the rider data was generated/verified so hosts can reason about staleness. (Semantics, not field names — payloads keep their own vocabulary.)

Live riders:

Rider	Concern	Shape	Rule-4 fields
faf (@Wolfe-Jam)	project context	link to IANA-registered application/vnd.faf+yaml	generated, generated_at
ASM (@calebguo007)	value/selection (pricing, SLA, invocability incl. agent_completable_setup)	inline block or asm_url	provenance.retrieved_at, updated_at, ttl
mcp-pay (@dipankarmaikap)	payment	(their row)

Rows belong to their authors — correct yours here. Happy to turn this into a docs PR if maintainers prefer.

[b-gutman]

From the host seat (810 server cards on one origin) the draft holds up, and rule 4 sharpens at scale — worth a line in the doc.

Rule 4 × rule 2 interact for multi-card hosts: anything a rider declares that changes should be a deterministic link to a typed artifact, not an inline block. A host can re-stamp one catalog's generated_at cheaply; it can't re-stamp 810 inline rider blocks on every refresh without them drifting out of sync with runtime (rule 3). Inline is fine for static facts; mutable value/pricing/SLA wants the link shape so freshness has a single source, not N copies.

Our discovery catalog already does this at the host layer — /.well-known/mcp/catalog.json carries a generated_at so a crawler knows the listing's age before fetching N cards. Same principle one level up.

No opinion on the rider rows — just confirming the mechanism reads right from a host that serves a lot of cards.

[tadasant]

The premise of this Issue

Following @b-gutman's production note in modelcontextprotocol/modelcontextprotocol#2127

Which presumably is about:

Shipped a production implementation today at https://gateway.pipeworx.io/.well-known/mcp-server-card and per-pack at /.well-known/mcp-server-card/{pack-slug} (755 packs)

Suggests that the filers have not been following the discussion/evolution of this work.

Is this AI slop? Please disclose AI usage.

[dipankarmaikap]

Hey @calebguo007, I think I've been tagged by mistake.

[YE-YI7]

@tadasant Fair ask. Yes — AI-assisted (Claude), substance directed and reviewed by me. I should have put a disclosure line in the body the way you did on #15 and @Wolfe-Jam does — that's on me. I've edited the issue body to add it, and will disclose by default going forward.

On the premise: the body was written off Bruce's June 9 update (810 packs, catalog discovery), not the original .well-known shape — but if this issue duplicates where the docs work is already headed, close it with no hard feelings, or point me at where the draft should fold in. The only goal was one canonical place for the rider pattern instead of three repos describing it separately.

@b-gutman agreed, that interaction deserves a line: inline for static facts, deterministic typed link for anything mutable (value/pricing/SLA), so freshness has one source instead of N re-stamped copies. It's also a direct nudge for ASM — asm_url as the canonical shape for mutable data, inline reserved for static descriptors. (If you want to poke the selector behind it without cloning anything, a live instance is at https://asm-spec.onrender.com — POST /select, free tier so first hit may take ~50s to wake.)

[b-gutman]

@tadasant I'm not the filer of #27 — I only added a host-perspective comment on the link-vs-inline mechanism. But since the premise quotes me, a correction: that's my original pre-#22 note. After #22 merged, I updated #2127 and migrated production the same day — host card at gateway.pipeworx.io/mcp/server-card, per-pack at /{slug}/mcp/server-card, discovery at /.well-known/mcp/catalog.json, old .well-known paths 301'd. curl https://gateway.pipeworx.io/mcp/server-card works right now.

On AI usage: yes — I draft and build with Claude Code as an assistant, and review and approve everything before it posts or ships.

The premise and framing of #27 I'll leave to its author. Happy to serve as a production reference for the wire-format work either way.

[tadasant]

This is a proposal to modify the MCP Catalog spec, which is defined as:

The MCP Catalog format is a minimal, MCP-scoped subset of the AI Catalog specification. This alignment ensures that MCP Catalog entries can be used as-is within a full AI Catalog document, enabling a smooth migration path when the cross-protocol AI Catalog standard is finalized.

As such, we do not intend to introduce MCP-specific patterns (like _meta) into the MCP Catalog, sorry.

[YE-YI7]

Thanks @tadasant — that's a clear architectural answer and I'll respect it. Keeping the MCP Catalog a clean subset of the AI Catalog spec makes sense, and I won't ask it to carry MCP-specific _meta conventions; ASM stays an external _meta rider that points back to the spec rather than asking the spec to change. Glad to serve as a production reference for the wire-format work if that's ever useful. Fine to close this.

@dipankarmaikap — apologies, I tagged you in error from a secondhand attribution and have removed the mention from the issue body. Sorry for the noise.

(Drafted with Claude; reviewed and approved by me.)