Axelar Network is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the Axelar Network API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.
SCORED UNDER RUBRIC 1.2 · A full re-launch under Discry Score 2.5 — a new behavioral instrument, not comparable to these scores — is in progress.
Discovery
45% of score · 24/100Comprehension
55% of score · 85/100What we found
- An agent that reaches docs.axelar.dev finds genuinely strong comprehension material: task-oriented descriptions ("To call a contract on chain B from chain A..."), typed SDK signatures for estimateGasFee, live Remix examples, and real on-chain transaction links — this is documentation written to be understood, not just referenced.
- Error recovery is a standout: the execution-error page enumerates failure scenarios (insufficient gas, reverted destination logic, expired nonce) and gives each an explicit 'two options to recover' / 'what to do next' path with links to transaction-recovery guides — exactly the self-correction guidance an agent needs.
- An agent trying to DISCOVER Axelar programmatically hits a wall: no llms.txt, no llms-full.txt, no .well-known/mcp.json, no AGENTS.md in the GitHub org, and no listing in any major MCP registry. Discovery scored F despite the docs themselves being high quality.
- There is no publicly downloadable OpenAPI/Swagger spec. The developer surface is SDK-first (AxelarJS) plus smart-contract methods, so an agent cannot ingest a machine-readable contract of the API — it must read prose and code samples.
- robots.txt allows all crawlers and a complete sitemap (sitemap-0.xml, daily lastmod) enumerates every doc page, so an agent that already knows the docs URL can crawl the full surface cleanly — the gap is purely in agent-native discovery signals, not in openness.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add an llms.txt at docs.axelar.dev root: a right-sized, API-focused index linking the GMP overview, AxelarJS query API, gas service, Interchain Token Service, and the execution-error/recovery pages. This is the single highest-impact discovery fix and would move the F discovery grade materially.
- 02Publish an AGENTS.md in the primary repos (axelar-docs, axelarjs-sdk, axelar-examples) so coding agents get repo-specific build/integration context — a rising standard the org currently misses entirely.
- 03Generate and host llms-full.txt (concatenated markdown of the developer docs) — the MDX source already exists on GitHub, so this is largely a build-step addition and would give agents a single-fetch comprehension path.
- 04List an Axelar MCP server (or the Axelarscan REST APIs) in Glama / Smithery / PulseMCP so agents discovering capabilities through MCP registries can find Axelar at all.
- 05Add a concise capabilities/limitations overview (supported chains, rate limits for Axelarscan APIs, known constraints) as a single page — today an agent must infer boundaries from scattered L2 caveats and security notes.
Execution coverage · INFORMATIONAL, UNSCORED
Whether an agent can actually complete a call and recover from errors is the deeper Audit layer — documented here, but not part of the Discry Score.
Execution characteristics for the on-chain surface (GMP, gas service, Interchain Token Service) are documented well — a dedicated execution-error page maps failure messages to concrete recovery steps and Ethers.js error fields, and estimateGasFee exposes typed gas parameters. However, there is no traditional API-key/rate-limit/pagination/idempotency documentation because the core developer surface is an SDK plus smart contracts rather than a REST API.