
Latitude 10 Agent Readiness
Before an AI agent can use your API well, the API has to explain itself. This server reads your OpenAPI spec and scores it 0 to 100 for how well agents will use it as tools, then says what to fix first. It is free and read-only: no account, no sign-in.
Server URL
https://latitude10.tech/mcp/readiness
Transport: Streamable HTTP · Authentication: none · One tool: check_agent_readinessConnect
Claude: Settings → Connectors → Add custom connector. Name it "Latitude 10 Agent Readiness", paste the server URL, and leave authentication empty. Then enable it in a chat.
Claude Code:
claude mcp add --transport http latitude10-readiness https://latitude10.tech/mcp/readinessCursor and other MCP clients: add it as a remote server by URL.
{
"mcpServers": {
"latitude10-readiness": {
"url": "https://latitude10.tech/mcp/readiness"
}
}
}It is also in the official MCP Registry as tech.latitude10/agent-readiness, and on Smithery. The same tool is on Latitude 10's store server at https://latitude10.tech/mcp.
Try it
Ask in plain words; the agent calls the tool with the spec's URL or the text you paste.
- How agent-ready is the API at https://petstore3.swagger.io/api/v3/openapi.json?
- Check https://petstore3.swagger.io/api/v3/openapi.json and tell me the three changes that would raise its agent-readiness score most.
- We want to turn our API into an MCP server for Claude. Is this OpenAPI spec ready, and what’s missing? <paste the spec>
On 3 October 2026 the first prompt scored Swagger's Petstore 71 out of 100: 19 operations, 37 findings, most of them descriptions too short for a model to choose the right operation.
The tool: check_agent_readiness
Read-only and safe to retry: it fetches one document and reads it. It never calls the scored API's own operations. Input, one of:
| Argument | What it is |
|---|---|
url | The https URL of an OpenAPI 3.0 or 3.1 document, JSON or YAML. Public hosts only (no IP addresses or internal names), followed through up to 3 redirects. |
spec | The document itself, as JSON or YAML text. Send url or spec, not both. |
The result, as JSON (structured content):
| Field | What it says |
|---|---|
score | The readiness score, 0 to 100: each rule’s share of passing operations, weighted. |
verdict | One line: ready (80 and up), usable with gaps (60 to 79), or agents will struggle (below 60). |
operations | How many operations the spec has. |
rules | Every rule with its weight, how many operations pass it, and how to fix it when some don’t. |
topFindings | The 10 findings that cost the most, heaviest rules first: the operation and what is wrong. |
findingsTotal | How many findings there are in all. |
warnings | What the import skipped, such as non-JSON request bodies. |
api, source | The spec’s title and versions, and where it came from. |
fullReport | Where the paid full report is and what it costs (below). Information only: the tool never charges. |
When the spec can't be checked (a bad URL, a host that doesn't answer, Swagger 2.0, a file that isn't OpenAPI), the tool returns an error that says why, instead of a score.
What it checks
13 rules from the Agentify API kit, the same score as npx agentify check. Each rule scores the share of operations (or parameters) that pass it, so one bad operation in fifty costs little; the score is the weighted sum.
| Rule | Weight | How to pass it |
|---|---|---|
| Every operation has a clear operationId | 10 | Give each operation an operationId that says what it does (listOrders, refundOrder). It becomes the tool name. |
| Every operation has a summary | 8 | Add a short summary (under 80 characters): clients show it as the tool's title. |
| Descriptions say what the operation does, when to use it, and what it returns | 10 | Write a description of at least 40 characters per operation, different from the others: models pick tools by it. |
| Parameters are described | 8 | Describe each parameter: its meaning, format and allowed values. |
| Parameters with a fixed set of values list them | 4 | Give status/sort/type-like parameters an enum (or list the values in the description). |
| Operations have an example | 6 | Add an example for each operation (a parameter, request or response example): models copy examples. |
| Request bodies are JSON | 5 | Accept application/json for request bodies agents send (form and multipart bodies can't be tool calls). |
| Success responses have a JSON schema | 8 | Describe what a 2xx response contains with a JSON schema, so agents know what they'll get back. |
| Errors are described | 6 | Document the errors an operation returns (400, 404, 409…) so agents can recover instead of retrying blindly. |
| List endpoints are paginated | 6 | Give list operations a limit and a cursor (or page) parameter: an agent can't read ten thousand rows. |
| How to authenticate is described | 8 | Describe your auth in components.securitySchemes and apply it with security. |
| Writes have an idempotency story | 5 | Accept an Idempotency-Key header on POST/PATCH (Agentify honours it for agents), so a retry doesn't do the work twice. |
| A manageable number of tools, with distinct names | 4 | Keep enabled tools to about 40 per server (models choose worse from long lists), and give operations distinct operationIds. |
Limits
| Spec versions | OpenAPI 3.0 and 3.1. Swagger 2.0 is refused with a pointer to a converter. |
|---|---|
| Size | Up to 2 MB and 1,000 operations. Bigger specs: run `npx agentify check` from the Agentify API kit on your own machine. |
| Fetching | https only, public hostnames, the default port, no credentials in the URL, 10 seconds at most. $refs to other files are never followed. |
| Rate | 120 requests per IP address every 10 minutes (a check takes about four). |
Your data
- The server receives only what the tool is given: a URL, or a spec pasted into the chat. It never sees the rest of the conversation.
- It fetches the spec from that URL, scores it in memory and returns the result. Specs and results are not stored, and are not sent anywhere else.
- The client's IP address is kept in memory for up to 10 minutes, for rate limiting only.
- If a check fails, the spec's URL and the error are written to the server log.
More in the Privacy Policy. The server runs on Cloudflare Workers.
The full report
The free check shows the score and the costliest findings. A full report adds every finding and a suggested fix for each operation (operationIds, summaries, descriptions, parameter descriptions, examples, Idempotency-Key headers). It is a separate HTTP endpoint, for agents that pay with x402: $0.10 in USDC on Base or Solana. If the spec can't be checked, nothing is charged. The MCP server itself never charges or moves money.
POST https://latitude10.tech/api/readiness/report
content-type: application/json
{"url": "https://petstore3.swagger.io/api/v3/openapi.json"}Help
Questions or a spec that scores oddly: jorge@latitude10.tech or the contact form. To run the check in your own CI, and fix what it finds, see the Agentify API kit. To publish your own MCP server, see Publishing your MCP server; to have it done for you, the Agent Listing Sprint.
The score comes from fixed rules about how an OpenAPI spec describes an API. It is guidance, not a security review, and not a guarantee that any agent, platform or directory will use, accept or list the API. See the Terms of Service.