Front is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Front 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 · 71/100Comprehension
55% of score · 91/100What we found
- An agent can fetch clean markdown for any page by appending .md to the URL (content negotiation works site-wide), and every reference page embeds its full OpenAPI definition inline — making Front one of the most parse-friendly CRM API docs an agent will encounter.
- Discovery is well above average: a 397-entry sitemap, an open robots.txt that blocks no AI crawlers, a public OpenAPI spec repo (frontapp/front-api-specs covering Core + Channel APIs), and a community MCP server listed on Glama and PulseMCP all mean an agent can find the API through multiple independent paths.
- The llms.txt is genuinely useful — API-focused, split into Guides and API Reference sections, with per-endpoint descriptions and required scopes — but at 69KB it exceeds the ~50KB right-sizing threshold, so an agent ingests more index than it needs before reaching specifics.
- Endpoint docs are task-oriented and consistent: descriptions explain what you accomplish ("Import a message that was received by the channel"), every write endpoint states its required OAuth scope, and naming is uniformly snake_case with stable ID prefixes (acc_, cnv_).
- The two gaps are AGENTS.md (absent across all frontapp GitHub repos) and error-recovery depth: rate-limit 429 handling is well explained via reset headers, but there is no consolidated error-codes page giving agents fix steps for the broader error surface.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add an AGENTS.md to the frontapp/front-api-specs repo (and the org root) with API base URL, auth model, scope catalog, and pagination conventions — a near-zero-effort discovery win worth a full check on the v1.2 rubric.
- 02Trim or split llms.txt to land under ~50KB — e.g. keep the curated API Reference section and link out to a separate full index — so agents load a right-sized map instead of a 69KB dump.
- 03Publish a dedicated error-handling page that pairs each common HTTP/error code with an actionable recovery step (which parameter was invalid, when to retry, how to fix scope/auth failures), extending the strong 429 guidance to the rest of the error surface.
- 04Add a llms-full.txt (concatenated markdown of core guides + reference) so agents can grab the whole corpus in one fetch rather than crawling 397 sitemap entries.
- 05Document idempotency-key support (or explicitly state its absence) so agents can safely retry create operations without risking duplicate contacts, conversations, or calls.
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.
Strong execution documentation. Auth is Bearer token (API tokens) or OAuth2, with OAuth required for partner integrations acting on behalf of customers. Rate limits are documented in detail (50/100/200 rpm by plan, 120 rpm partner, 600 rpm server) with x-ratelimit-limit/remaining/reset response headers. Pagination is cursor-based via page_token with a _pagination response object. No idempotency-key support is documented.