The honest part: auditing your own coverage will find gaps
Having all eight items above doesn't mean every endpoint is reachable from every surface. Building this checklist, we ran our own coverage audit — comparing every REST endpoint against what's actually callable from the MCP server, the ElizaOS plugin, the Solana Agent Kit plugin, and the x402 SDK — and found two categories of real gaps in our own API, not just a hypothetical:
- One endpoint (ranking a token's top traders by realized PnL) existed on the REST API but had no MCP/ElizaOS/Agent-Kit tool wired to it at all — a genuine miss, since the discovery text even mentioned it.
- Our sniper-detection feature (pre-confirmation deploy alerts) existed on the MCP server but was completely absent from the ElizaOS and Solana Agent Kit plugins — reachable from one agent framework and invisible to two others.
Both are fixed as of this post (2026-09-10) — the honest reason for mentioning it is that "agent-ready" isn't a one-time checkbox. New endpoints ship faster than SDK coverage does unless you build the audit into your release process, not just your initial launch.
FAQ
What does "agent-ready" actually mean for an API?
Machine-readable discovery (llms.txt + agents.json), an MCP server on a current spec, native plugins for the agent frameworks your buyers actually use (not just MCP), a keyless payment option like x402 for fully-autonomous agents, rate limits that return Retry-After and are queryable in advance, a real OpenAPI spec, structured errors with a code, and a low-friction free tier.
Why do AI agents fail against APIs that "have good documentation"?
Documentation written only for humans (prose, examples, FAQs) does not by itself let an agent branch reliably on a rate-limit response or enumerate capabilities. Structured errors, explicit limits, machine-readable discovery and a real schema make those decisions programmatic.
Is MCP enough, or do I need agent-framework plugins too?
MCP covers MCP clients (Claude Desktop, Cursor, Claude Code). It does not cover agents built with a framework like ElizaOS or Solana Agent Kit, which expect a native plugin with typed actions. If your users build autonomous agents on those frameworks, MCP alone leaves that audience unreached.
What's the difference between an API key and x402 for agent access?
An API key requires a human to sign up once and provision it into the agent's config — normal for most deployments. x402 lets an agent with its own funded wallet pay per call with no signup at all, which matters specifically for agents provisioning themselves at runtime with no human in the loop.
How do I check if my own API's SDK coverage has gaps?
Enumerate every REST endpoint from your OpenAPI spec, then grep each of your SDK/plugin source files for the actual path strings they call (not just method names — a stale doc comment can claim coverage a method doesn't have). Diff the two lists. It's mechanical work, but doing it once surfaces exactly the kind of silent gap described above.
Try it
MadeOnSol's full agent-tooling surface — MCP, ElizaOS, Solana Agent Kit, x402 — is documented at /mcp and machine-readable at /agents.json. A worked MCP tool call, and which tools an agent reaches with an API key versus keyless over x402, is on the AI agents solution page. A free key runs any of it at 200 calls/day: madeonsol.com/pricing.
September 2026 refresh
This checklist was tightened to separate MadeOnSol's own implementation lessons from unsupported industry-wide statistics. The current published MCP registry snapshot is 104 Solana tools + 68 Robinhood Chain tools (checked 2026-09-26), and the wording around llms.txt, agents.json and MCP revisions now describes them as practical discovery/versioning choices rather than claiming universal adoption or an unverified 90% token saving.
Sources: MadeOnSol MCP & SDK registry, OpenAPI, llms.txt, and agents.json.