webdriverio is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the webdriverio 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 · 14/100Comprehension
55% of score · 88/100What we found
- An agent trying to discover WebdriverIO programmatically hits a wall: there is no robots.txt, no llms.txt, no llms-full.txt, and no .well-known/mcp.json — every machine-readable discovery entrypoint returns 404, so an agent has nothing to anchor on beyond the human sitemap.
- Once an agent reaches the docs, comprehension is excellent (88/100): command pages lead with a plain-language 'what it does' description, then Usage, Parameters, realistic copy-pasteable examples, and Returns — a clean answer-first structure an agent can parse reliably.
- Examples are genuinely realistic and executable — real selectors ($('#myButton')), real values, multiple scenarios per command (offset clicks, right-click, long-press), and one-click 'Run Example' / 'View on GitHub' links to a live example-recipes repo.
- Capability boundaries are marked inline per parameter (WEB-ONLY, MOBILE-NATIVE-APP-ONLY, Desktop/Mobile), so an agent can tell which options work on which platform without trial-and-error failure.
- No AGENTS.md exists in the primary repo, but multiple community MCP servers are published (Glama, PulseMCP, several GitHub projects), so an agent searching MCP registries would find a way to drive WebdriverIO even though the project itself ships no first-party agent surface.
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 the site root summarizing the core browser/element/mock command surface with links to the API reference — the single highest-impact discovery fix and currently the biggest gap between the docs' quality and their agent-discoverability.
- 02Publish a robots.txt that explicitly allows AI crawlers (GPTBot, ClaudeBot, Google-Extended, CCBot) — right now the absence of any robots.txt reads as a discovery failure and leaves crawl policy ambiguous.
- 03Add an AGENTS.md to the webdriverio/webdriverio repo giving coding agents setup, config (wdio.conf), and test-run conventions — WebdriverIO is heavily used by coding agents and this is now table-stakes.
- 04Generate an llms-full.txt (Docusaurus supports this via plugins) so agents can ingest the full command reference as one clean markdown document instead of scraping hundreds of individual pages.
- 05Consolidate error handling and recovery into a dedicated 'Common Errors' page (element not found, not clickable, timeouts) with explicit fixes — recovery guidance exists but is scattered inside individual command 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.
WebdriverIO is a local Node.js browser/mobile automation framework, not a remote REST API, so traditional API execution characteristics (auth headers, rate limits, pagination, idempotency) do not apply. Errors surface as descriptive thrown JS exceptions (e.g. 'Element is not clickable at point (x, y)') and several command pages document the exact error strings plus recovery steps; cloud-vendor credentials (Sauce Labs, BrowserStack) are documented via the capabilities object rather than an API auth scheme.