01
Choose one safe evaluation task
Use a job an evaluator should complete without a sales call, real billing risk, or production side effect.
Can an AI agent evaluate your product without guessing?
Run this teardown before you claim your developer experience is agent-ready, ship an MCP server by reflex, or mistake AI visibility for a usable evaluation path.
02
Start with public evidence
Give the agent only the public site, docs, API reference, and supported evaluation path. Do not fill gaps from founder knowledge.
03
Record the exact stop
Keep the prompt, URL, misleading claim, missing prerequisite, error, and failed recovery attempt. Agent-ready is not a vibe.
The checks that expose the expensive mistake.
Can it find the right source?
An agent needs a clear route from product promise to authoritative technical material.
- The product, docs, and API reference have stable, discoverable URLs.
- The homepage and docs agree on what the product does and who it is for.
- Public machine-readable surfaces, where useful, point to canonical sources rather than stale copies.
Common failure: Search finds a marketing claim, an old blog post, and three contradictory setup guides, so the agent starts by guessing.
Can it understand the contract?
The important boundaries must be explicit enough to act on without charitable interpretation.
- Prerequisites, auth, limits, pricing, and side effects are stated before the first request.
- Examples show expected output and what counts as a successful result.
- API errors distinguish invalid input, missing access, rate limits, and product constraints.
Common failure: The docs list endpoints but omit the conditions that make a request safe or meaningful.
Can it try the product safely?
A serious evaluation path separates experimentation from irreversible action.
- A sandbox, test mode, mock data, or dry-run path exists where the workflow needs one.
- The agent can tell whether it is touching live data, billing, or customer systems.
- Credentials and permissions follow least-privilege evaluation paths.
Common failure: The first useful test requires a production key, live customer data, or a charge card.
Can it recover and hand off?
Failures should return the next action, not merely a status code.
- Errors name the likely cause and a concrete recovery route.
- The docs explain what evidence support needs when a user is blocked.
- A human can reproduce the agent's last safe step and continue from there.
Common failure: The agent reaches an auth wall or a vague 400 response, then loops through irrelevant documentation.
Fix the first unsafe or ambiguous step.
Do not add an MCP server to paper over unclear docs, missing product boundaries, or a broken sandbox. Start with the earliest point where an agent cannot find the truth, make a safe attempt, or recover from a predictable failure.
When this is not enough
The Agent-Ready DX pass is one of seven areas in the Developer Adoption Audit. Use the full audit when the problem also crosses positioning, onboarding, documentation, measurement, and DevRel ownership.
Does agent-ready mean we need an MCP server?
No. MCP is a delivery choice, not proof of a usable developer experience. First establish that the product has a clear, safe evaluation path and an agent-shaped workflow worth supporting.
Does this promise visibility in AI answers?
No. It tests whether your public materials and product path are clear enough to be found and used correctly. Nobody can promise rankings inside a specific model or answer engine.
Can we run this without a sandbox?
Yes, but the result may expose that as a high-priority risk. Where real actions can create cost, data exposure, or irreversible changes, a safe test path matters.
Bring the evidence, not the hunch.
If the problem crosses positioning, onboarding, documentation, measurement, and team ownership, the Developer Adoption Audit joins it up.
Book an Audit Call