Freshworks is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the Freshworks 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 · 38/100Comprehension
55% of score · 54/100What we found
- An agent that already knows the URL finds a complete, well-organized REST reference: every core CRM object (contacts, accounts, deals, leads, lists, activities) has create/view/list/update/upsert/bulk/clone/delete endpoints with realistic curl examples and consistent snake_case fields.
- An agent trying to DISCOVER the API programmatically is largely blind: no llms.txt, no llms-full.txt, no .well-known/mcp.json, and a near-empty sitemap.xml (two URLs). The robots.txt allows all crawlers, so the docs are reachable, but there is no machine-readable map to them.
- There is no official OpenAPI/Swagger spec — a developer-community thread explicitly asks why none exists. An agent cannot auto-generate a client or validate payloads against a contract; it must scrape the HTML reference.
- The entire CRM API reference is a single JavaScript-rendered page of ~350KB (~88K tokens) with no overview or progressive disclosure, so an agent must load the whole document to understand any one capability — a severe token-efficiency tax.
- Positive signals on the agent ecosystem side: Freshworks ships an official AGENTS.md (freshworks-developers/fw-dev-tools) for coding agents, an official Developer MCP server, and Freshdesk MCP servers are listed on PulseMCP and Smithery — so agent tooling exists even though the core docs aren't agent-optimized.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an llms.txt at the docs root that names the API, summarizes core CRM capabilities, and links to the contacts/accounts/deals/leads reference sections — the single highest-leverage discovery fix, currently a flat 404.
- 02Publish an official OpenAPI 3.x specification for the Freshsales CRM API so agents can generate typed clients and validate requests instead of scraping a single HTML page (the community has asked for this directly).
- 03Break the monolithic single-page reference into per-resource pages with a concise overview, or expose a clean markdown version, to cut the ~88K-token cost of understanding the API and fix the broken progressive disclosure.
- 04Add at least two or three multi-step workflow guides (e.g. 'create contact → add to list → attach a deal → log an activity') — the docs currently cover endpoints in isolation with no guidance on chaining them for real tasks.
- 05Upgrade the error table from descriptions to recovery guidance (e.g. how to handle 429 back-off, which parameter triggered a 400) and populate the near-empty sitemap.xml with the actual documentation URLs.
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.
The Freshsales CRM REST API documents token-based API-key auth (Authorization: Token token=...), a JSON error envelope ({"errors": {"code", "message"}}) with an error-code table, a flat 1000 requests/hour/account rate limit (no rate-limit header names specified), and page-based pagination on listing endpoints. Idempotency keys are not documented, though upsert/bulk_upsert endpoints exist. These are documented claims only; live behavior requires a full Discry Audit.