Windsor.ai is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Windsor.ai 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 · 55/100Comprehension
55% of score · 90/100What we found
- An agent crawling windsor.ai is explicitly welcomed: robots.txt carries a dedicated 'Welcome AI crawlers' block that Allows GPTBot, ClaudeBot, PerplexityBot and ChatGPT-User full access — discovery-friendly by design, not by accident.
- Windsor.ai ships a real, structured 37KB llms.txt with an overview, product/destination sections, security details and a direct link to the full API docs — one of the better llms.txt files in the category, and it makes core capabilities agent-legible in seconds.
- The API reference reads like it was written for agents: task-oriented endpoint descriptions, realistic Python + JavaScript examples with plausible values, a clean JSON error table, and explicit rate limits — comprehension scores an A (90).
- The single biggest discovery gap is the absence of any public OpenAPI/Swagger spec. An agent that wants a machine-readable contract for the query-param API has nothing to consume and must scrape the HTML docs — this alone caps the discovery score at D.
- There is a hosted Windsor MCP server (mcp.windsor.ai) with native one-click apps in the Claude directory and ChatGPT, plus an ADK integration — but no AGENTS.md in the public windsor_mcp repo and no /.well-known/mcp.json on the main domain, so agent-native discovery signals are only partially in place.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a public OpenAPI 3.x spec for the Connectors API (endpoints, the api_key param, date/data filtering operators, _renderer, and the /fields and /connectors discovery routes). This is the highest-impact discovery fix and would move discovery from D toward B.
- 02Add an AGENTS.md to the windsor-ai/windsor_mcp repo (and other primary repos) so coding agents get setup, auth (OAuth 2.0), and usage context directly in the repo.
- 03Serve a real /.well-known/mcp.json and a working /llms-full.txt on windsor.ai itself (both currently soft-404 to the homepage) — the machine-readable docs already exist at mcp.windsor.ai, so mirror or redirect them from the apex domain.
- 04Expand error documentation from cause descriptions into explicit recovery steps for the top errors (e.g. 'on 429, back off using the Retry-After / quota-reset header'; 'on 400, verify the connector slug and that requested fields exist via /{connector}/fields') so agents can self-correct.
- 05Add 2-3 explicitly labeled end-to-end API workflow guides that chain operations with error handling (discover connectors → fetch fields → build a filtered query → handle rate limits), rather than leaving multi-step usage implied across single-call examples.
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 documentation is strong for a data-retrieval API: a machine-parseable JSON error envelope ({error:{code,message}}) with a full HTTP status/error-code table, explicit rate limits (600 req/min, 10,000 req/day) with reset headers, and plan-tiered refresh controls. No pagination scheme or idempotency support is documented — the API returns a full JSON data array filtered by date/field parameters rather than paging.