Agent Readiness
A topic index covering the operational practices, signals, and patterns that make an API surface safely usable by autonomous AI agents rather than only by humans. Catalogs the specifications, identity layers, agent skill formats, and edge-layer signals that combine into a coherent agent-readiness posture, with a dimension model, JSON Schema, JSON-LD context, vocabulary, and example signal records for representative providers.
Limited machine-readable signal and partial portal coverage — documentation a human can read, but little a machine or agent can consume without scraping.
API Evangelist profiles Agent Readiness the way a machine reads it — 43 machine-readable artifacts across 15 APIs, pulled from the provider's own public surface and indexed so a developer, an analyst, or an AI agent can evaluate it against every other provider on the network.
Every provider in the network is reduced to the same set of machine-readable artifacts — OpenAPI contracts, event specifications, GraphQL schemas, runnable collections, pricing and rate-limit signals, security posture, OAuth scopes, and the agent surfaces (MCP servers and skills) that let software drive the API on its own. We profile them because the interface is the part of a company you can actually inspect: it is a truer signal of what a provider does than any marketing page. From those artifacts we compute the Kin Score — Agent Readiness scores 40.3/100 (thin), with a separate agent-readiness read of 17/100 (agent aware). The full breakdown is below, followed by every artifact we hold — each card links through to its machine-readable definition on apis.io.
Kin Score
This is the API Evangelist rating — a single, repeatable read computed from the artifacts on this page. Green fill is points earned; the red track is points possible, so every bar shows earned-versus-possible at a glance.
Kin Score
How this is scored →scored 2026-07-27 · rubric v0.5
How we profile Agent Readiness
Each block below is one kind of artifact we hold for Agent Readiness. For each we say what it is and why it earns a place in the profile, then list every one we've indexed — capped at two rows, scroll within the panel for the rest.
APIs 15
Each API is captured as its own OpenAPI definition — every operation, parameter, and response. This is the single most useful machine-readable description of what an API does, and it's what lets us score, lint, mock, and generate against it without asking the provider for anything.
Individual APIs this provider publishes, each with its own machine-readable definition.
Model Context Protocol (MCP)
An open JSON-RPC protocol that lets AI agents talk to tools, resources, and prompts through a uniform server surface. MCP is the most direct expression of "an API designed for a...
OpenAPI Specification
The dominant machine-readable contract for HTTP APIs. Presence of a public OpenAPI document — with examples, error schemas, security schemes, and rate-limit headers — is the sin...
AsyncAPI Specification
Machine-readable contract for event-driven APIs (webhooks, message brokers, streaming). Agent-readiness for event surfaces depends on whether the provider ships an AsyncAPI docu...
JSON Schema
The vocabulary that lets an agent validate request and response bodies against typed contracts. Published JSON Schemas (independent of, or embedded in, an OpenAPI) are a strong ...
Agent Skills
A community schema for publishing operational instructions an agent should follow when using a site or API. A provider that ships a `/skills/` directory with a skill index is si...
/.well-known/api-catalog (RFC 9727)
RFC 9727 defines `/.well-known/api-catalog` as the canonical machine entrypoint for discovering an organization's APIs, formatted as an RFC 9264 linkset. Presence of a catalog a...
HTTP Message Signatures (RFC 9421)
A cryptographic signature scheme for HTTP messages, used by the emerging web-bot-auth profile to let agents authenticate themselves to origins. Provider support for verifying or...
Web Bot Auth (draft)
IETF draft layering an "identified bot" profile on top of RFC 9421. A provider that publishes a directory of verified agent identities — or surfaces Web Bot Auth verdicts in its...
Content-Usage / AIPREF (IETF AIPREF WG)
The IETF AIPREF working group's effort to standardise machine-readable AI usage preferences (e.g. `Content-Usage: ai-input=y, ai-train=n`). A provider that publishes explicit AI...
Cloudflare Content Signals
Cloudflare's `Content-Signal` robots.txt directive, complementing the AIPREF drafts. Together they let an origin separate "crawl for search" from "use for AI input" from "use fo...
APIs.json
The APIs.json format describes a provider's API portfolio in one machine-readable document. Publishing `/apis.json` (or `/apis.yml`) at the site root is the agent-readiness equi...
OpenID Connect
Identity layer on top of OAuth 2.0. Agent-readiness for authenticated APIs depends on clear, discoverable OIDC metadata (`/.well-known/openid-configuration`) so agents can negot...
Stripe API (reference provider)
Reference provider for the agent-readiness signal set. Stripe publishes its full OpenAPI, ships idempotency keys, surfaces rate-limit headers, has a consistent error envelope, a...
GitHub REST + GraphQL API (reference provider)
Reference provider with arguably the most extensively-tooled developer surface on the web. Public OpenAPI, GraphQL schema, webhooks, conditional requests, explicit `X-RateLimit-...
Twilio API (reference provider)
Reference provider with strong agent-readiness signals on the messaging side — published OpenAPI, idempotency on resource creation, structured error codes, signed webhooks, stat...
Scroll within the panel for all 15 ·
GraphQL 1
Where a provider ships GraphQL, the schema is the contract. We profile it alongside the REST surface so the whole interface is legible in one place.
GraphQL schemas published by this provider.
Agent Readiness GraphQL API
Reference provider with arguably the most extensively-tooled developer surface on the web. Public OpenAPI, GraphQL schema, webhooks, conditional requests, explicit `X-RateLimit-...
GRAPHQLFeatures 6
The notable capabilities this provider advertises, captured as structured features so they can be searched and compared instead of read one landing page at a time.
Notable capabilities this provider offers.
Dimension Model
A nine-dimension scoring model covering specs, auth, idempotency, error semantics, rate-limit headers, dry-run, examples, MCP, and event contracts
Signal Schema
JSON Schema describing a single agent-readiness signal (provider, dimension, score, evidence URL)
Provider Aggregate
JSON Schema for a provider-level aggregate of signals across dimensions
JSON-LD Context
A JSON-LD context aligning agent-readiness signals with schema.org and common API vocabularies
Reference Examples
Example signal records for Stripe, Twilio, and GitHub illustrating how the model is applied in practice
Vocabulary
Controlled vocabulary of agent-readiness terms across operational and capability dimensions
Semantic Vocabularies 1
JSON-LD contexts give the data shared meaning across APIs. We profile them because semantics are what let a machine reconcile 'customer' here with 'customer' somewhere else.
JSON-LD contexts and semantic vocabularies used across these APIs.
Agent Readiness Context
JSON-LDSpectral Rules 1
Governance rulesets we run against this provider's specs — the automated checks behind parts of the score. Profiling them makes the quality bar explicit and re-runnable, not a matter of opinion.
Agent Readiness API Rules
SPECTRALJSON Schema 2
Standalone JSON Schema definitions describe the data models behind the API. We profile them so the shapes are validatable on their own — useful long after a single request is forgotten.
Standalone JSON Schema definitions for this provider's data models.
AgentReadinessProvider
JSON SCHEMAAgentReadinessSignal
JSON SCHEMAExamples 10
Real request and response payloads are what turn a spec from abstract into obvious — and they're one of the twelve things an agent needs to call an API correctly on the first try.
Example request and response payloads for these APIs.
Scroll within the panel for all 10 ·
Security Posture 2
Authentication, domain security, vulnerability disclosure, and trust-center signals — the evidence that a provider takes security seriously enough to document it. We profile it because you can't govern what you can't see.
Authentication, domain security, vulnerability disclosure, and trust-center signals.
Use Cases 5
What developers actually build with this provider — captured so the catalogue answers 'what is this for', not just 'what does this expose'.
What developers build with this provider.
Provider Self-Assessment
A team auditing their own API surface against a checklist of agent-readiness dimensions
Consumer Pre-Integration Review
An engineering team evaluating whether a third-party API can be driven by an autonomous agent before committing to integration
Procurement and RFP Scoring
A buyer scoring vendor APIs on a normalized agent-readiness rubric during procurement
Aggregator Indexes
A directory or marketplace ranking listed APIs by agent-readiness score to help agent developers pick safe surfaces
Standards Coverage Map
Mapping where each standard (OpenAPI, AsyncAPI, MCP, AIPREF, RFC 9727, RFC 9421) contributes to which dimension
Resources
Every other property we hold for Agent Readiness — documentation, portals, status pages, policies, and corporate surface — grouped by the job it does, following the integrator's arc from getting started to running in production.
Documentation 3
Reference material describing how the API behaves
Design & Contract 2
Pagination, idempotency, versioning, errors, and events
Build 2
SDKs, sample code, and the tooling you integrate with
Access & Security 2
Authentication, authorization, and security posture
← All providers · Data indexed from github.com/api-evangelist/agent-readiness · machine-readable index on apis.io