Web3Auth is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Web3Auth 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 · 71/100Comprehension
55% of score · 100/100What we found
- An AI coding agent integrating Web3Auth is exceptionally well served: the docs (now at docs.metamask.io/embedded-wallets) open with an explicit 'For AI agents' banner pointing to /llms.txt, expose a .md version of every page via URL suffix or Accept: text/markdown, and ship a full llms.txt ecosystem with dedicated Embedded Wallets link and full-doc files following the llmstxt.org standard.
- Web3Auth ships purpose-built agent tooling that most APIs lack entirely: a dedicated agent-skill repo (github.com/Web3Auth/skill, Agent Skills format) covering SDK selection, auth flows, key-derivation rules, and migration tripwires, plus an official hosted MCP server (mcp.web3auth.io) that gives agents live doc search, examples, and SDK types.
- Comprehension is best-in-class: numbered quickstarts (Configuration → Providers → Connect users), realistic copy-pasteable multi-language code (npm/yarn/pnpm/bun, real hook names), consistent naming, clean Docusaurus heading hierarchy, and migration guides that even embed an LLM agent prompt.
- Discovery is dragged down because the legacy web3auth.io domain itself serves no llms.txt, llms-full.txt, or .well-known/mcp.json (all 404) and has only a stale 2024 marketing sitemap — an agent that starts at web3auth.io rather than the GitHub org or MetaMask docs sees almost none of the agent-readiness that actually exists.
- As a client-side SDK rather than a REST API, Web3Auth publishes no OpenAPI/Swagger spec, which is the single largest scored gap in discovery — expected for its architecture, but it means an agent cannot machine-read a canonical interface contract.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Serve an llms.txt (and llms-full.txt) directly at web3auth.io that redirects/links agents to the MetaMask Embedded Wallets docs, so agents landing on the brand domain aren't dead-ended by 404s.
- 02Add a .well-known/mcp.json discovery file (on web3auth.io and/or the docs domain) advertising the existing mcp.web3auth.io server, so agents can auto-discover the MCP endpoint instead of finding it only via search.
- 03Regenerate the web3auth.io sitemap.xml (currently stamped 2024-03-01, marketing-only) or 301 the domain's crawl surface toward the live Docusaurus docs sitemap so discovery reflects current documentation.
- 04Publish a machine-readable interface spec for the server-side verification and backend surfaces (even a small OpenAPI file) to give agents a canonical contract beyond the SDK method docs.
- 05Prominently cross-link the agent-skill repo and MCP server from the main SDK landing pages (not just GitHub) so agents that read the docs first are pointed to the agent-native tooling.
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.
Web3Auth is a client-side wallet/auth SDK (React, Vue, JS, Node, Android, iOS, React Native, Flutter, Unity, Unreal), not a REST API, so pagination, idempotency, and rate limits are largely not applicable. Authentication methods are documented extensively (social, passwordless, custom JWT, MFA), and error handling is documented via a dedicated JWT-error troubleshooting section with named failure modes and fix guidance. Network/environment constraints (Sapphire Devnet vs Mainnet, localhost origin rules, Node 22+) are clearly stated.