Most businesses already have something an AI agent could use: a data lookup, a quote, a document check or a reservation endpoint. Making that capability agent-ready does not mean replacing the service. It means giving the service a contract an agent can discover, understand and use without bypassing the rules that protect the business.
The difficult work sits around the endpoint. An agent needs to know what it can ask for, which inputs are valid, whether the operation costs money and what a retry will do. Those concerns can live at the edge while the backend keeps the HTTP interface it already has.
What “agent-ready” really means
A machine-readable schema is the beginning, not the finish. A useful agent contract describes the operation in terms of an outcome, accepts a bounded input and returns a predictable result. It also makes commercial terms and failure states explicit enough for software to act on them.
OpenAPI can provide much of the HTTP shape. MCP can expose the capability as a tool. Neither one, by itself, decides pricing, replay policy, settlement or what should happen after payment if the backend fails.
Start with one bounded capability
The best first capability has a clear unit of work and a result that is easy to verify. A company lookup or deterministic document check is easier to operate than a workflow that changes several systems. The narrower boundary also makes pricing and retries less ambiguous.
{
"name": "verify_company",
"description": "Verify a company registration and return evidence.",
"input": {
"country": "string",
"registration_number": "string"
},
"result": "verification_report",
"price": { "amount": "0.08", "currency": "USDC" }
}Descriptions should state what the caller receives, not repeat an internal route name. Inputs should carry useful constraints, and the result should have a stable shape that the agent can use in its next step.
Keep the protocol at the edge
An MCP call, a native HTTP request and a future commerce protocol can represent the same business capability. Adapters translate each surface into one canonical request, so the application does not accumulate protocol branches next to its business logic.
This is also where authentication and authorization should meet. The protocol identifies the caller and carries credentials; the merchant policy decides whether that identity may invoke this capability, with this scope and at this price.
Design for retries before launch
Agents retry after timeouts, and networks can lose a response after the backend has already completed its work. For read-only operations, a repeat may be harmless. For a purchase or reservation, the same behavior can create a second charge or side effect.
Give every commercial request a stable transaction ID. Reserve replay state before execution, and pass a stable operation key into any state-changing backend. The Gateway can prevent a payment proof from opening a new transaction; the backend key lets the business service return the original result when execution itself is retried.
A gateway cannot promise exactly-once execution inside an arbitrary backend. The merchant operation must participate by recognizing the same operation key on every retry.
Return outcomes an agent can use
Do not collapse validation, payment and delivery into one generic error. “Payment required” invites a payment step. “Replay blocked” tells the caller not to create another transaction. “Paid, not delivered” calls for recovery against the same transaction rather than another charge.
A compact receipt should carry a safe request reference, the capability, the payment state and the delivery outcome. Keep credentials, raw payment material and verbose backend responses out of anything the model may see.
A practical first release
Ship one capability through one current channel, with a schema, a clear price and an observable failure path. Test the happy path, a rejected input, a repeated request and a backend timeout after payment. When those outcomes are explicit, adding another adapter becomes controlled expansion rather than another backend rewrite.
The merchant keeps the important parts
The backend, pricing policy, settlement destination and customer relationship remain under merchant control. The agent-facing layer makes those existing capabilities safer to reach; it does not absorb the business into a new marketplace.
Frequently asked questions
Does an API need MCP to be agent-ready?
No. MCP is one way to expose tools and resources to AI applications. An API can be agent-ready through another protocol or through a direct agent integration. The important parts are discovery, a clear contract, authorization, safe execution and predictable outcomes.
Is OpenAPI enough for AI agents?
OpenAPI describes HTTP operations well. It does not fully define payment rules, replay protection, transaction state or agent authorization. Treat it as a useful source of API structure.
Should the AI agent call the backend directly?
It can for simple read-only operations. Paid and state-changing operations benefit from a control layer that can validate the request and manage payment and transaction state before the backend is called.
What is the safest first capability to expose?
Choose a bounded operation with a clear result and limited side effects. A read-only data request or a deterministic paid lookup is usually easier than a workflow that changes several systems.
Can existing APIs be adapted without rewriting them?
Yes. A protocol or commerce gateway can translate agent requests into the HTTP contract your backend already accepts.
Sources and further reading
- Model Context Protocol specificationmodelcontextprotocol.io
- x402x402.org
- Agent Payments Protocolgithub.com
- Agentic Commerce Protocolgithub.com
- Universal Commerce Protocoldevelopers.google.com
- Machine Payments Protocolstripe.com