The vocabulary of API management in the agentic era

A named, versioned view of your API for one consumer: which endpoints they see, which fields exist for them, how they authenticate, and what happens when something they depend on changes. Contracts are machine-checked on every commit.

One API usually needs several contracts. A mobile client, a partner integration, an internal service, and an AI agent each need a different subset of the same surface.

A change to an API that invalidates something a consumer already depends on — a removed endpoint or field, a narrowed type, a new required parameter, or a changed auth requirement. Whether a change breaks is a property of the contract, not of the diff.

The same commit can be breaking for one consumer and invisible to another, which is why the check runs per contract rather than once per repo.

The gap that opens between what an API specification claims and what the running code actually does. Drift accumulates whenever an endpoint changes and the hand-maintained spec does not.

Drift is why specs generated from code behave differently from specs maintained beside it: a generated spec cannot silently fall out of date, because it is rebuilt from the source of truth on every commit.

An open standard that defines how AI clients such as Claude, Cursor, and ChatGPT discover what a server offers and call its tools. It gives models a uniform way to reach external systems without a bespoke integration per client.

A server that exposes a set of tools to AI clients over the Model Context Protocol. For an API team it is a thin, curated layer in front of the API you already run, not a replacement for it.

Around 15 to 25 well-described tools beat an endpoint dump, because the model picks tools by reading their descriptions rather than by reading your API.

The hosted layer agents connect to instead of reaching an MCP server directly. Every tool call passes five checks in order: identity, tool scope, field redaction per contract, rate and quota, and an audit record with actor, tool, arguments hash, latency, and outcome.

One request from an agent or client through a hosted MCP server — the agentic equivalent of an API request, and the unit MCP usage is measured in.

A tool call is a production request against a real system, so it deserves the same authentication, authorization, rate limiting, and logging as any other production traffic.

A per-endpoint grade for whether an API is usable by an AI agent, scored across design, developer experience, AI readiness, security, and performance, with a concrete fix attached to each finding.

It answers a different question from spec linting. A spec can be valid and lint-clean while still being unusable by an agent: no descriptions, loose types, undocumented auth.

The rules and automated checks that decide what an API is allowed to expose, to whom, and how it is allowed to change — enforced in the pipeline rather than in review comments.

Testing that verifies an API still satisfies what its consumers depend on, rather than only that its endpoints respond. A contract test fails when a change breaks a specific consumer, even if the endpoint is healthy.

A generated set of hostile requests that probe how an API behaves under the inputs agents actually produce: wrong types, truncated JSON, extra fields, and nulls where a string is required.

It exists because agents fail differently from humans. An agent that half-understands your schema will send plausible-looking nonsense at full request rate.

The standard machine-readable description of a REST API: its endpoints, parameters, request and response schemas, and authentication. It is the format most API tooling reads and writes.

A spec is where an API pipeline starts, not where it ends. Having one says nothing about whether the API is documented, tested, governed, or safe to expose.