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

[YE-YI7]

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

[YE-YI7]

Thanks — I think this is exactly the right framing.

I agree that the economics layer is not just “how much does this cost?” In agent systems, pricing, quotas, rate limits, approvals, and risk controls often become the same operational boundary seen from different angles.

One thing I’m trying to make sharper in ASM is that value metadata should support a pre-call decision, not just post-call accounting. Before an agent invokes a tool, the client should be able to reason about questions like:

• Is this call within the user’s budget or spend cap?
• Is it within the service’s quota/rate-limit envelope?
• Does this action require approval because of cost, side effects, or risk?
• Is the pricing/limit/quality claim self-reported, verified, or stale?
• Should repeated calls trigger a checkpoint rather than silently continue?

So I agree: cost, rate, approval, and risk should probably travel together in the manifest. The manifest itself should not be the enforcement mechanism, but it can give clients and registries enough structured data to enforce local policy before invocation.

This also helps clarify where ASM should sit alongside MCP. MCP describes capability and invocation. ASM should describe the operational/economic envelope around using that capability.

I’ll likely revise the proposal to make this less “cost discovery” and more “pre-call operational constraints for value-aware and risk-aware selection.” Curious whether you think this belongs as explicit fields in the manifest, or as a policy layer that references manifest fields.