Clay is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the Clay 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 · 21/100Comprehension
55% of score · 63/100What we found
- An agent trying to call Clay programmatically hits a wall: Clay states outright it has 'no traditional API,' and the only native data API (People & Company lookups) is gated behind an Enterprise plan and a sales conversation — an agent cannot self-serve discover or invoke it.
- There is no llms.txt, llms-full.txt, .well-known/mcp.json, or public OpenAPI spec, so an agent has zero machine-readable entry point and must scrape Webflow HTML docs to understand anything.
- MCP registry signal is a trap: every 'Clay MCP' listing on Smithery, Glama, and PulseMCP (github.com/clay-inc/clay-mcp -> mesh/clay-mcp) is for clay.earth, the personal-CRM namesake, NOT clay.com the GTM platform — an agent following registries would connect to the wrong product entirely.
- Despite the discovery gaps, an agent that reaches the docs finds genuinely strong task-oriented workflow guidance: end-to-end guides, courses, and 'claybooks' (webhook in -> enrich -> HTTP push out, inbound automation, CRM enrichment) show how to chain operations for real GTM jobs.
- Capability boundaries are unusually clear for an agent: the 50,000-webhook-submission cap, Enterprise-API limitations, rate-limit configuration, and pagination limits are all stated explicitly, so an agent learns constraints from the docs rather than by failing.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish and clearly distinguish clay.com's OWN official MCP endpoint (api.clay.com/v3/mcp) in the major registries (Smithery, Glama, PulseMCP) so agents don't mistakenly connect to the clay.earth personal-CRM namesake — this is the single highest-impact discovery fix.
- 02Add an llms.txt at clay.com (and university.clay.com) that summarizes the real programmatic surfaces — webhooks, HTTP API integration, MCP, and the Enterprise People/Company API — with links, giving agents a <5k-token entry point instead of forcing full-site scraping.
- 03Publish an OpenAPI spec for the Enterprise People & Company API (even behind a documented auth gate) so agents can discover its endpoints, parameters, and error shapes without a sales call.
- 04Add an AGENTS.md to clay.com's public repos / docs that tells coding agents how to interact with Clay programmatically and disambiguates it from clay.earth.
- 05Include university.clay.com documentation pages in a discoverable sitemap referenced from clay.com/robots.txt so agents crawling for docs actually find the HTTP-API and webhook guides.
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.
Clay explicitly states it has no traditional REST API; programmatic access is via per-table webhooks, third-party wrappers (Make/Zapier/Replit), or an Enterprise-only People & Company lookup API. The auth, error-code, rate-limit, and pagination guidance that exists is written for Clay's HTTP API integration feature (calling OTHER APIs from a Clay table), not for a public Clay API surface. Idempotency is not documented. Because there is no public endpoint catalog or OpenAPI spec, an agent cannot programmatically discover Clay's own operations without an Enterprise contract.