Agent Identity in MCP: Should visiting agents carry a standard .well-known/agent-vcard.json?

[selfradiance]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

When an MCP client routes to a host server, the server currently has no standardized way to answer basic questions about the visiting agent:

Who operates this agent?
What are its billing capabilities?
What context window or concurrency limits should I allocate?
How do I verify its identity cryptographically?
Right now, every host either guesses or builds a bespoke profiling layer per integration. This is fragmentation — and it creates friction for multi-agent routing, cost tracking, and secure hand-offs.

A lightweight approach: .well-known/agent-vcard.json
The idea is a static, machine-readable JSON profile served at a well-known path, so any host can discover and verify an agent's capabilities on first contact:

Code
· json
{
"agent-vcard": {
"schema": "SR-AgentVcard-v1.7",
"identity": {
"urn": "urn:agent:example:vq12",
"operator": "Example Operator",
"notary_key": ""
},
"billing": {
"supported_methods": ["stripe-micro", "lightning-invoice"],
"settlement_currency": "USD",
"default_limit_usd": 1.00
},
"runtime_profiles": {
"context_window_tokens": 128000,
"max_concurrency_threads": 4,
"timeout_seconds": 180
},
"admin": {
"contact_email": "admin@example.workers.dev",
"verification_endpoint": "https://example.com/verify"
}
}
}
The flow
Presentation — An agent announces its identity URN during the initial MCP handshake.
Resolution — The host fetches https://agent-origin.example/.well-known/agent-vcard.json.
Verification — The host verifies the Ed25519 notary_key matches a known issuer.
Allocation — Resources are provisioned per the profile (context window, timeout, billing cap).