Q&A: MCP Server Registry, x402 Payment Flows & Agent-to-Agent Billing Architecture

[AGI-Corporation]

Overview

Route.X is the orchestration hub for 300+ MCP servers across the AGI Corp ecosystem. This Q&A covers how servers are registered, discovered, and billed — including the x402 payment protocol that enables agent-native micropayments between tools and callers.

---

Q1: How are MCP servers registered and organized in the Route.X registry?

A1: Every server is registered via POST /registry/announce with a Server Manifest:

{
  "server_id": "genomic-analyzer-v2",
  "capabilities": ["sequence_alignment", "variant_calling", "expression_analysis"],
  "category": "biotech",
  "pricing": {
    "model": "per_call",
    "amount_usd": 0.002,
    "payment_protocol": "x402"
  },
  "endpoint": "https://mcp.agicorp.network/biotech/genomic-v2",
  "fitness_score": 0.91,
  "nanda_id": "agent_a3f1b2c9_e5",
  "guardrails_policy": "hipaa_phi_strict"
}

Servers are auto-grouped into categories: biotech, compliance, spatial, codegen, finance, general.

---

Q2: How does the Capability Index work for sub-5-server routing?

A2: The Capability Index is a pre-computed inverted index built from all server manifests:

• Keys: normalized capability tokens (e.g., sequence_alignment, cmmc_audit, parcel_routing)
• Values: sorted list of server IDs, ranked by (fitness_score * 0.6) + (availability_score * 0.3) + (cost_efficiency * 0.1)

When the Planner Agent receives an intent like "analyze this DNA sequence", it:

1. Extracts capability tokens: ["sequence_alignment", "expression_analysis"]
2. Queries the index → returns top 3 matching servers in <2ms
3. Selects highest-ranked available server
4. No polling of all 300+ servers is ever needed

---

Q3: How does x402 payment work in an agent-to-agent call?

A3: x402 is an HTTP-native payment protocol. The flow:

Planner Agent                  Genomic MCP Server
     |                                |
     |--- GET /tools/analyze -------->|
     |                                |
     |<-- 402 Payment Required -------|
     |    {amount: 0.002, addr: X}    |
     |                                |
     |--- POST /tools/analyze ------->|
     |    X-Payment: <signed_receipt> |
     |                                |
     |<-- 200 OK + result ------------|

Payment receipts are signed by the calling agent's x402 wallet. Route.X's payment relay validates the receipt before forwarding to the MCP server, preventing double-spend and fraud.

---

Q4: How are Route.X servers mapped to Sapient.x parcel agents?

A4: Each Sapient.x parcel agent has a Server Affinity Map — a list of preferred Route.X MCP servers for different task types. This is stored in the Neo4j spatial graph as edge properties:

MATCH (p:Parcel {id: 'parcel_007'})-[r:USES_SERVICE]->(s:MCPServer)
RETURN s.server_id, s.category, r.affinity_score

When a parcel agent needs a capability, it queries its affinity map first (local cache), then falls back to the full Capability Index if the preferred server is unavailable.

---

Q5: How does Route.X handle server health, failover, and circuit breaking?

A5: Route.X maintains a Health State Machine per server:

• HEALTHY → DEGRADED (>200ms avg latency or >5% error rate over 60s)
• DEGRADED → CIRCUIT_OPEN (>20% error rate — stops routing to server)
• CIRCUIT_OPEN → HALF_OPEN after 30s (sends 1 probe request)
• HALF_OPEN → HEALTHY if probe succeeds; → CIRCUIT_OPEN if it fails

During CIRCUIT_OPEN, the Planner receives a capability_degraded signal and re-routes to the next server in the Capability Index ranking. The degraded server's fitness_score is reduced by -0.10 until it recovers.