Coresignal is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Coresignal 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 · 60/100Comprehension
55% of score · 87/100What we found
- An agent can read Coresignal's docs almost entirely as clean markdown: the GitBook-hosted site exposes a per-page .md endpoint, a comprehensive API-focused llms.txt index, and a built-in `?ask=` query mechanism — near-ideal for LLM consumption.
- An agent discovering Coresignal for the first time would find an official, remote MCP server (mcp.coresignal.com) listed on PulseMCP and documented in-repo, letting it connect to company/employee/jobs data without wiring raw REST calls.
- Endpoint pages are strongly task-oriented — each API states what you accomplish ('Get a comprehensive view of any company…'), and the search→collect→enrich pattern, rate limits, credits, and response codes are all clearly tabulated.
- Discovery is dragged down by missing agent-standard files: no llms-full.txt, no .well-known/mcp.json, and no AGENTS.md in the coresignal-mcp repo — so an agent gets no single self-describing manifest and must assemble context from multiple pages.
- No first-party OpenAPI/Swagger spec is published; docs rely on Postman/cURL templates with placeholder values ({company_id}, {API Key}), so an agent cannot auto-generate a typed client and must infer request shapes from prose.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a first-party OpenAPI 3.x spec (e.g. docs.coresignal.com/openapi.json) covering the v2 Company/Employee/Jobs endpoints — this is the single highest-impact fix, enabling agents to auto-generate typed clients instead of parsing cURL templates.
- 02Add an AGENTS.md to the Coresignal-com/coresignal-mcp repo (and any client repos) summarizing auth, base URL, core endpoints, and the search→collect workflow so coding agents get instant context.
- 03Add a .well-known/mcp.json manifest advertising the remote MCP server and its tools, so MCP-aware agents can auto-discover it without a registry lookup.
- 04Replace placeholder example values ({company_id}, {API Key}) with realistic sample IDs and a runnable end-to-end request, so copy-pasted examples work with minimal edits.
- 05Serve an llms-full.txt (or link the .md bundle) and ensure the root robots.txt sitemap covers the docs subdomain, tightening the discovery surface for crawlers and agents.
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 characteristics are well documented: single API-key header auth, per-endpoint rate limits (requests/second), a full response-code reference with recovery hints, and dedicated pagination pages (search-after / Elasticsearch DSL). No formal idempotency keys, though bulk collect returns 409 on duplicate POSTs. Claims are documentation-only and would need live testing to verify.