IPGeolocation is Good to agents.
Discry independently scored how well an AI agent can discover and understand the IPGeolocation 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 · 81/100Comprehension
55% of score · 94/100What we found
- An agent evaluating IPGeolocation would find it exceptionally easy to consume: docs expose raw Markdown versions (.md URLs), per-API OpenAPI specs in both YAML and JSON, plus 'Copy Markdown URL', 'Run in Postman', and 'Open in ChatGPT' actions — deliberate agent-first tooling that is rare in the wild.
- Discovery is strong across the board: a well-structured llms.txt AND llms-full.txt, an unrestricted robots.txt (no AI-bot blocks), a complete sitemap listing every documentation page, an official OpenAPI repo (github.com/IPGeolocation/openapi), and an official MCP server listed on PulseMCP, Glama, and the site's own /integrations/mcp page.
- Comprehension is near-perfect (94/A): endpoints lead with task-oriented purpose, examples use real IPs (91.128.103.196) across 10 languages with copy-paste blocks and live response previews, naming is consistently snake_case, and the error table explains the exact cause of each 400/401 so an agent can self-correct.
- The two discovery gaps are low-effort: there is no /.well-known/mcp.json (404) and no AGENTS.md in the primary repos — an agent relying on those conventions specifically would miss them, even though the equivalent information exists elsewhere.
- Multi-step workflow guidance is the softest comprehension area: the core docs are largely per-endpoint, so an agent chaining operations leans on the include/fields patterns and the separate Guides/Integrations pages rather than dedicated end-to-end tutorials.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add a /.well-known/mcp.json declaring the official MCP server's tools and auth — the MCP server already exists, so this is a pure discovery win that closes a 1-point gap and signals MCP support to agents checking the well-known path.
- 02Publish an AGENTS.md in the main SDK/MCP repositories (and ideally at the docs root) summarizing auth, base URL, credit model, and common error recovery — this is a rising standard and the only remaining discovery fail besides mcp.json.
- 03Add 2-3 dedicated end-to-end workflow guides (e.g., 'Enrich a signup: look up IP → check VPN/proxy threat_score → branch on risk') to lift multiStepWorkflows from partial to pass; the building blocks (include, fields, bulk) are already documented but not stitched into task narratives.
- 04Surface an explicit rate-limit / 429 section in the primary IP Geolocation API error table (the MCP server already documents 429 and Retry behavior) so agents hitting quota limits get first-class recovery guidance without consulting the MCP repo.
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 are well documented. Auth is via an apiKey query parameter, with optional Request Origin (CORS) authorization on paid plans. Errors are machine-parseable JSON with descriptive messages and a detailed HTTP status table (400/401/405/413/415/423/429/499/5XX) explaining the specific cause of each condition. Rate/quota limits are documented as daily credit limits (1,000 requests/day on Free) plus a paid-plan surcharge model, with an X-Credits-Charged (and conditional X-Successful-Record) response header. Bulk lookups accept an `ips` array (POST, up to 50,000 IPs) rather than cursor/offset pagination, so pagination is not applicable; idempotency keys are not mentioned.