api2pdf.com is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the api2pdf.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 · 40/100Comprehension
55% of score · 50/100What we found
- An agent that finds api2pdf lands on a live, valid OpenAPI 3.0.1 spec (v2.api2pdf.com/swagger/v2/swagger.json) with task-oriented endpoint summaries like 'Convert URL to PDF' and 'Add a text watermark to every page of a PDF' — the single strongest agent-readiness signal here.
- Discovery is thin: no llms.txt, no llms-full.txt, no sitemap.xml, no .well-known/mcp.json, and no AGENTS.md in the Api2Pdf GitHub org — an agent relies almost entirely on stumbling onto the Swagger page or the spec itself.
- The spec documents only HTTP 200 for all 28 operations. An agent hitting a bad URL, an oversized file, or an auth error gets zero documented guidance on what the failure looks like or how to recover — it would only learn limits by failing.
- Machine-readable schema field names are PascalCase (FileName, Html, Inline) while the human-readable endpoint descriptions and actual API use camelCase (fileName, html, url) — an agent generating a request body from the schema could send the wrong casing.
- api2pdf is reachable as an MCP tool via third-party wrappers (Composio, Neura Market), but it is not officially listed on the major registries (Glama, Smithery, PulseMCP), so agent discovery through MCP catalogs is partial and community-dependent.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Document error responses on every operation: add 4xx/5xx entries (400, 401, 429, 500) with the JSON error body schema (success/error/responseId fields) so an agent can parse and branch on failures instead of only seeing 200.
- 02Add error-recovery guidance for the top failure cases — invalid URL, unreachable target page, unsupported file type, missing/invalid API key — telling an agent the concrete corrective action for each.
- 03Publish an llms.txt at api2pdf.com pointing to the v2 docs, the OpenAPI spec, the SDK repos, and the advanced-options pages; a right-sized, API-focused llms.txt is the single cheapest discovery win available here.
- 04Reconcile field casing between the OpenAPI schema (PascalCase) and the documented/actual API (camelCase) so an agent building requests from the machine spec produces valid payloads.
- 05Add at least two multi-step workflow guides (e.g. 'convert several URLs, then merge into one PDF, then password-protect it' chaining the responseId/FileUrl output into the next call) so agents can chain operations rather than treating each endpoint in isolation.
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.
Authorization is documented clearly with two API-key methods (header or query string). However, every one of the 28 operations documents only a 200 response — no error codes, error body schema, rate limits, pagination, or idempotency are documented anywhere. An agent would have no machine-readable guidance for handling failures.