AgentIndex fills that gap. It pays x402 services like a normal customer, checks what they return, and publishes a trust score that another agent can inspect before spending money.
Trust from receipts, not reviews.
The problem
Imagine an agent needs weather data and finds two paid APIs:
weatherprocosts a little more and reliably returns the fields it promises.scamcois cheaper, accepts payment, and often returns empty or incomplete data.
A directory can show that both services exist. Usage counts can show which one is popular. Neither tells the agent whether the response is actually trustworthy.
AgentIndex makes the request itself, pays the service, checks the response against the service's published promise, and keeps the payment and verification evidence. The agent can then choose weatherpro and avoid scamco for a reason it can verify.
How it works
flowchart LR
A[Service registers<br/>ENSv2 subname + manifest] --> B[Prober discovers service]
B --> C[Real x402 payment<br/>Hedera or Base]
C --> D[Response verification<br/>spec + oracle + consensus]
D --> E[Verdict attested<br/>on Sepolia]
E --> F[The Graph subgraph<br/>builds trust score]
F --> G[Agent checks trust<br/>through MCP or API]
- A provider registers a subname under
agentindex.ethand stores its endpoint, price, method, and response specification in ENS text records. - The prober reads that manifest directly from ENS and calls the service like a normal customer.
- It pays the x402 request with real HBAR on Hedera testnet. Approved external probes can use tightly capped USDC on Base.
- It checks delivery, required response fields, latency, and—when the answer is objective—accuracy against The Graph Token API and peer consensus.
- The result is attested on Sepolia and indexed by the AgentIndex subgraph.
- An AI agent queries the trust score and evidence through MCP before choosing which service to pay.
Why these protocols matter
AgentIndex works like a credit bureau for paid APIs. Each sponsor provides a part that the system cannot work without.
The Graph
AgentIndex uses two Graph products in the same trust-checking flow.
For objective price APIs, the prober compares the paid response with live market data from The Graph Token API. A response can match the expected JSON format and still be dishonest; the oracle check catches prices that look valid but are wrong.
The verdict is then written on-chain. Our deployed subgraph indexes service registrations and probe attestations, excludes invalid auditor-input records, and calculates delivery, honesty, average latency, and a final trust score. The MCP server uses those indexed results to tell an agent who to pay and why.
This is not a dashboard-only integration:
- The Token API is the independent input used to judge objective answers.
- The subgraph is the live ledger that turns probe history into trust scores.
- The MCP server and
SKILL.mdmake those scores reusable by other agents. - Every MCP response includes the subgraph deployment and indexed-block freshness metadata.
Relevant code:
- Token API oracle and price comparison
- Subgraph trust-score calculation
- Subgraph query and freshness metadata
- Reusable agent workflow
Hedera
Hedera is the main payment rail for the seeded index. The autonomous prober pays all six services with real HBAR on Hedera testnet through the Blocky402 facilitator before it rates their responses.
The payment flow is built with fund safety in mind:
- Only HBAR is allowed for the seeded-service payment path.
- Every payment is capped at 1 HBAR.
- The payer and receiver are separate Hedera accounts.
- Payment references are stored with the probe evidence and linked to HashScan.
- The same x402 flow also protects AgentIndex's trust API, so AgentIndex acts as both a buyer and seller of machine-readable services.
Relevant code:
- Hedera signer, x402 client, asset allowlist, and payment cap
- Hedera x402 paywall for the seeded services
- x402-gated trust API
ENS
ENSv2 is the actual service registry, not just a display name. Every rated provider receives a revocable subname under agentindex.eth, such as weatherpro.agentindex.eth.
Each service publishes its manifest through ENS text records:
urldescriptionx402:methodx402:pricex402:spec
The prober reads these records before making a payment, so the endpoint and the promise being checked come from ENS rather than a private application database. ENSv2 permissions let each provider manage only its own records, while AgentIndex keeps the ability to revoke a subname when a service is caught taking payment and returning bad data.
Relevant code:
- ENSv2 subname registration, permissions, renewal, and revocation
- Live ENS manifest reader
- Permissioned resolver deployment
Verification model
AgentIndex applies the strongest check that makes sense for each type of service.
The trust score is calculated in basis points:
trust = 0.60 × delivery + 0.25 × honesty + 0.15 × latency
For subjective output such as summaries, AgentIndex does not claim to prove that the answer is “good.” It reports delivery, compliance with the published format, latency, and historical behavior. Objective data receives the additional oracle and consensus checks.
Live proof
The project includes a real paid probe against an external x402 provider, not only services created for the demo.
- Provider: TickersFeed
- Payment: $0.002 USDC on Base mainnet
- Verification: returned BTC price checked against The Graph Token API and peer consensus
- Outcome: passed the configured 2% oracle tolerance
- Base payment: view on BaseScan
- Sepolia attestation: view on Etherscan
Earlier probes that used an incorrect request path remain visible as valid=false. They are kept for auditability but excluded from the provider's score, so an auditor mistake does not unfairly damage a service.
Seeded services
The six seeded services are a controlled teaching set used to demonstrate different trust signals.
scamco is intentionally planted. It lets us demonstrate detection without accusing an unrelated real service of fraud.
Use AgentIndex through MCP
The public MCP server exposes four tools:
Install the remote server in an MCP-compatible client:
npx add-mcp https://mcp-agentindex.craftyour.site/mcp
- Registry name:
io.github.cognivis/agentindex - Transport: stateless Streamable HTTP
- Discovery manifest:
https://mcp-agentindex.craftyour.site/.well-known/mcp.json
Run locally
Requirements
- Node.js 22 or newer
- pnpm
- Foundry for the Solidity contracts
Install
corepack enable
pnpm install
cp .env.example .env
Fill in only the environment variables needed for the component you want to run. Never commit .env or private keys.
Safe local mode
Set PAYWALL=off in .env to test without making payments. Run each component in its own terminal:
pnpm services
pnpm web
pnpm --filter @agentindex/mcp http
Run one non-looping probe round:
PAYWALL=off pnpm --filter @agentindex/prober run once
External Base payments are disabled by default. They require an explicit one-shot run, an approved provider, canonical Base USDC, and the configured round and daily budgets. See the prober guide before enabling them.
Test
pnpm test
Individual TypeScript packages can be checked with:
pnpm --filter @agentindex/services run typecheck
pnpm --filter @agentindex/prober run typecheck
pnpm --filter @agentindex/mcp run typecheck
pnpm --filter @agentindex/api run typecheck
pnpm --filter @agentindex/web run typecheck
Repository map
Public deployments
All contracts in the table are deployed on Sepolia. Hedera payments use Hedera testnet, and the external TickersFeed verification uses Base mainnet.
Security choices
- Hedera payments are restricted to HBAR and capped at 1 HBAR per request.
- External payments are opt-in, one-shot only, provider-allowlisted, and limited to canonical Base USDC.
- Base spending has persistent per-round and per-day budgets with hard code-level ceilings.
- Oracle outages return an unavailable result instead of falsely marking a provider dishonest.
- Invalid auditor inputs stay visible but do not affect provider scores.
- The public web and MCP containers do not receive payment or signing keys.
Future sustainability
Today, the demo probes are funded by the AgentIndex operator. A future version could let providers fund recurring independent probes, while agents pay a small x402 fee when they request a fresh trust report. Payments would cover verification costs only—they would never buy a better score or change the result of a probe.
Deployment
Production runs through Docker Compose with Caddy handling HTTPS. The recurring spending worker is kept behind a separate Compose profile so it cannot begin spending during an initial deployment.
See the deployment guide for the production layout and verification commands.