Servers.com is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Servers.com 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 · 74/100Comprehension
55% of score · 81/100What we found
- The vendor has actively built for agents: an official Servers.com MCP server (listed on PulseMCP, 73 tools across 6 categories) ships with an AGENTS.md and an agent-oriented README that documents async-operation polling — an agent can discover and drive this API through a first-party integration, which is rare among infrastructure providers.
- An agent that reaches developers.servers.com gets a clean, complete OpenAPI spec: ~199 operations across ~33 resource groups, answer-first endpoints (method/URL/purpose lead), task-oriented descriptions, and 100% consistent snake_case naming with zero camelCase drift.
- Discovery via the marketing site is broken for the API: www.servers.com/llms.txt exists but is a 148KB site-wide dump of blog, events, and legal pages that never once links to the API portal — an agent relying on llms.txt would never find the actual API docs.
- Capability boundaries are unusually well documented: an explicit 2000 req/hour rate limit with X-RateLimit headers, a 100-result pagination cap, and per-feature limits (e.g. iPXE config max 64KB, incompatible with L2 Segments/Firewall) mean an agent knows the guardrails before it hits them.
- Error recovery is thin for autonomous use: errors return clean JSON codes and a status-code table exists, but there is no idempotency-key support and no Retry-After / 429 backoff guidance — an agent that hits a rate limit or transient failure has no documented recovery path.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Fix llms.txt to be API-focused: replace the 148KB marketing dump with a concise (<50KB) llms.txt that links to developers.servers.com, the MCP server's TOOLS.md, and core workflows, and add an llms-full.txt of the API reference. This is the single biggest discovery quick win.
- 02Add explicit error-recovery guidance (and idempotency-key support): for each common error state the fix — e.g. 'on 429, wait until X-RateLimit-Reset', 'on 412, poll operational_status until normal'. This closes the largest comprehension gap.
- 03Publish a .well-known/mcp.json pointing at the official Servers.com MCP server so agents can auto-discover it without a registry lookup.
- 04Provide multi-language request examples inline in the reference (official Go/Python/Ansible/Terraform clients already exist) rather than cURL-only, so agents can copy-paste in their target runtime.
- 05Cross-link and add the API reference portal (developers.servers.com) to the main site's sitemap.xml and robots.txt so the developer docs are discoverable from the primary domain.
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.
Auth is Bearer JWT tokens issued from the customer portal with read-only/read-write scopes; errors return machine-parseable JSON ({"message","code"}) plus an "errors" field on 422; a concrete rate limit (2000 requests/account/hour) is documented with X-RateLimit-Limit/-Remaining/-Reset headers; pagination is page/per_page (max 100) with GitHub-style WebLinking headers. No idempotency-key support is documented.