An API can be machine-readable and still be unsafe for a machine to use.
This is the small problem behind Anvil.
The current fashion is to take an API specification, turn every operation into an MCP tool, attach a description, and declare the estate agent-ready. This works well in demonstrations because demonstrations have unusually cooperative APIs, unusually patient operators, and no audit committee.
Production is less obliging.
A refund endpoint is not safe because its JSON Schema validates. A queue is not a business operation because a broker permits a message. A POST is not retryable because the client library happens to have a retry option. A tool description does not become true merely because it is written in confident English.
Anvil starts from the opposite premise: exposing an API to an agent is a compilation and assurance problem, not a formatting exercise.
That distinction sounds semantic. It is architectural.
A formatter changes shape. A compiler establishes meaning, applies policy, rejects invalid states, and emits several outputs from one source of truth. Anvil is interested in the parts after the schema converter has finished: effect, risk, reversibility, confirmation, idempotency, retries, identity, approval, evidence, freshness, and the awkward question of whether the operation should be callable at all.
Generating a tool is easy. Generating the right to call it is the work.
An API description answers useful questions. It can say that an operation accepts an amount, returns a refund object, uses OAuth, and lives at a particular path. It rarely establishes the business facts an autonomous caller needs.
Does the amount use major or minor currency units? Does a successful HTTP response mean that the refund completed or that a job was merely accepted? If the connection fails after the upstream system commits, is repeating the request safe? Does an idempotency header exist, and is it honored across the failure window that matters? Does the caller have permission to invoke the operation, or merely the ability to reach it? Which errors are terminal? Which are safe to retry? Which require a human decision?
These are not documentation niceties. They determine whether automation is useful or merely fast.
The naïve tool-generation model collapses three different layers:
OpenAPI is usually strong on the first, variable on the second, and deliberately incomplete on the third. WSDL, proto, GraphQL SDL, OData metadata, Postman collections, and gateway exports have their own versions of the same gap. They describe an interface from a particular vantage point. None should be promoted into universal business authority.