[Proposal] Service Economics / Agent Service Manifest (ASM)

[calebguo007]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Summary

Agent Service Manifest (ASM) is an open protocol that gives AI agents
structured, machine-readable data to evaluate, compare, and automatically
select AI services — covering pricing, quality, SLA, and payment.

ASM is the missing layer between MCP (what a tool can do) and AP2 (how to pay).

Problem

When an agent faces multiple MCP-connected services that can fulfill the same
task, it has zero structured data to choose between them. No matter how smart
the model, unstructured pricing pages are uncomputable.

Proposed Solution

A lightweight JSON manifest (only 3 required fields) that services publish
alongside their MCP tool definitions, describing:

• Pricing: Multi-dimensional billing (12 dimension types)
• Quality: Benchmark scores with self_reported transparency flag
• SLA: Latency, uptime, rate limits
• Trust: 3-layer model (self-reported → third-party → Signed Receipts verification)

MCP Integration Path

We propose adding an optional x-asm field to MCP ToolAnnotations:

interface ToolAnnotations {
  // existing fields unchanged
  "x-asm"?: ServiceValueAnnotation;
}

This is fully backward-compatible — agents that don't understand x-asm simply ignore it.

Resources

• Spec + Reference Implementation: https://github.com/[your-repo]/asm-spec
• Paper: [link to paper when ready]
• SEP Draft: included in repo at sep/sep-asm-service-value.md

Discussion Questions

1. Is "service economics" a topic the MCP community wants to standardize?
2. Should value metadata live in ToolAnnotations (our proposal) or elsewhere?
3. What other dimensions beyond pricing/quality/SLA matter for agent selection?

Looking forward to the community's feedback!

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other