Add AgentServices — x402 paid data APIs for AI agents

[vbkotecha]

Provider: AgentServices

Homepage: https://agentservices.to
Category: Agent Tooling
Submitted by: Vendor

What is AgentServices?

AgentServices is a platform of paid data APIs for AI agents. 54 services spanning finance, market intelligence, and analytics, with x402 per-call micropayments on Base and an official MCP server (37 tools, registered on the MCP Registry at to.agentservices/agentservices, v5.3.0).

Why it fits

AgentServices exists specifically to give AI agents self-serve access to data endpoints with machine-readable discovery (OpenAPI spec, MCP server, agents.json route) and frictionless per-call payments via x402. Agents receive HTTP 402 responses with payment requirements, settle in USDC on Base, and get their data — no API keys, no subscriptions, no dashboards.

Evidence

All entrypoint URLs were live and verified on 2026-07-13:

• Homepage: https://agentservices.to (200)
• OpenAPI spec: https://agentservices.to/openapi.json (200)
• MCP endpoint: https://agentservices.to/mcp (live, registered on MCP Registry)
• x402 manifest: https://agentservices.to/.well-known/x402 (200)
• agents.json: https://agentservices.to/agents.json (200)
• Health: https://agentservices.to/health (200)

One provider per PR per contributing guide. YAML follows the existing data/providers/ format.

[Olorinm]

Thanks for the submission — the service is real (I verified the MCP Registry entry to.agentservices/agentservices and probed openapi.json, /.well-known/x402, agents.json — all answer), and an x402-native service is genuinely interesting here: as of today, account-less pay-per-call services are explicitly in scope (candidate-pool.md — account-less services). To make this mergeable, please fix:

1. Validate fails: entrypoints.mcp_registry is not a defined field (npm run validate reports it — please run it). Move the registry link into notes:.
2. File location: new providers now enter the candidate pool — data/candidates/agentservices.yaml (promotion to the index after a passing M1 run + evidence review).
3. Status corrections (per data/fields.yaml rubrics + the account-less mapping):
   • self_serve_signup, api_key_self_serve → not_applicable with a note. There is no account or key system; "no signup needed" is a different (good!) fact than "signup is self-serve".
   • versioning_policy → unknown unless you publish a written versioning/deprecation policy. A semver field in openapi.json is not a policy (rubric is explicit on this).
   • automation_permitted → evidence must be a terms/AUP/policy page with the decisive clause quoted in notes; an MCP endpoint is not terms evidence. If you have no published terms, unknown.
   • idempotency: keep not_applicable only if the data endpoints are strictly read-only — say exactly that in the note (x402 settlement itself is a write path, so precision matters).
4. Minor: pricing pointing at the homepage — prefer the machine-readable /.well-known/x402 if that's where per-call prices live.

Happy to run M1 as soon as this lands in the pool — for an x402 service the runner uses the credential-less variant (the documented 402-with-payment-requirements from the correct endpoint counts as a pass).