The Server Card WG is standardizing how a client discovers and connects to a server — capabilities, auth, transports, primitives — via .well-known/mcp.json (SEP-1649). My question is about the layer right next to it: once an agent has several servers that can each do the job, what does it use to choose among them?

That economic metadata — pricing, quality benchmarks, SLA, payment — isn't standardized anywhere today. I checked how big the gap is before raising this: I audited 14,519 entries across 5 MCP registries/directories (incl. the full MCPCorpus dataset). 0 expose pricing + SLA + quality + payment together in machine-actionable form. So an agent that can connect to 5 servers still has to parse 5 HTML pricing pages to pick one. In a 3-frontier-LLM test, top-1 selection accuracy off raw provider HTML was 64–72%, vs. 100% off the same data as structured fields.

I prototyped the value layer as a small JSON-Schema "value label" served at .well-known/asm — deliberately parallel to .well-known/mcp.json (MIT, runs in 60s: https://github.com/calebguo007/asm-spec). But I'd rather not maintain a parallel protocol if this belongs inside an existing effort.

The actual question: is value/economic metadata (pricing/quality/SLA) in scope for the Server Card, or intentionally out of scope?

• In scope → I'd contribute the value-layer schema into the Server Card work rather than keep a separate .well-known/asm.
• Out of scope by design → also useful to know; I'll keep it as an MCP-compatible extension the card can point to via one field.

Happy to bring the audit data + schema to a Server Card WG meeting if that's the right venue. Mainly trying to avoid reinventing something the WG already plans to cover.