Crossbeam is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Crossbeam 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 · 82/100What we found
- An agent looking to act on Crossbeam data would find a first-class, purpose-built path: an official Crossbeam MCP server with 9 clearly described, task-oriented tools (find_overlaps, get_account_context, find_partner_recommendations, etc.), native connectors for Claude/ChatGPT/Glean, and a public changelog at developers.mcp.crossbeam.com. This is well ahead of most APIs.
- The REST API itself is documented as a Postman-published collection at developers.crossbeam.com — rich with ~25 curl examples, OAuth2 flows, cursor pagination, and 429 handling — but there is NO publicly accessible OpenAPI/Swagger spec (the Swagger UI at api.crossbeam.com is just the default petstore placeholder; the real spec returns 403). An agent can't machine-ingest the REST surface without scraping Postman.
- Discovery is uneven: crossbeam.com serves a well-formed llms.txt and an AI-friendly robots.txt (explicitly allowing GPTBot, ClaudeBot, PerplexityBot, Google-Extended), but the llms.txt is marketing/company-focused with only a single link to developer resources — an agent gets the sales pitch, not the API map.
- The docs live across three disconnected surfaces (marketing site llms.txt, Postman REST reference, Intercom help center for MCP) with no unifying index. There is no llms-full.txt, no .well-known/mcp.json, and the sitemap covers only marketing pages, so an agent has to already know where to look.
- Comprehension is strong where docs exist: the MCP help article and Postman reference lead answer-first, use clean heading hierarchy, and include multiple step-by-step setup and integration workflows plus realistic example prompts.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a public OpenAPI/Swagger spec for the REST API (or replace the placeholder petstore Swagger UI at api.crossbeam.com with the real Crossbeam spec). This is the single biggest discovery gap — the openApiSpec check carries the most weight and would move an agent from 'scrape Postman' to 'ingest a spec'.
- 02Add an API-focused llms.txt (or an /llms.txt on developers.crossbeam.com) that maps the REST endpoints and MCP tools with descriptions, instead of the current company/marketing-oriented file. This directly upgrades both llms.txt quality and token efficiency.
- 03Add a .well-known/mcp.json advertising the already-live MCP server so agents can auto-discover it, rather than only finding it via help-center prose or third-party registries.
- 04Consolidate error recovery guidance: pair each documented error code (401/403/429) with an explicit remediation step (e.g., 'on 429, back off using Retry-After'), and note idempotency behavior for write operations.
- 05Expose the API documentation pages in a sitemap and publish an llms-full.txt so the full REST + MCP reference is crawlable as clean markdown from a single entry point.
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 REST API documents OAuth2 auth, JSON error responses (401/403/429), cursor-based pagination, and rate limits (including that calls count toward Record Export limits). Idempotency keys are not mentioned. These are documented claims only — verifying live behavior requires a full Discry Audit.