Anvil

Import the gateway you already run

Most enterprise APIs don’t live in a git repo. They live behind a gateway, and the gateway holds details the spec leaves out: which auth plugin fronts an operation, which scopes a product grants, where quotas apply, and which requests get rewritten in flight.

Anvil inventories the catalog of APIs behind your gateway — its estate — then lets you adopt selected APIs through the same approval-gated compiler path as a hand-written OpenAPI file. Five offline adapters read explicitly documented interchange shapes. Kong declarative config is direct; WSO2 accepts its native apictl export apis directory, per-API ZIP/project, or standalone api.yaml. Apigee, MuleSoft, and API Connect currently require the normalized documents described in the import guide.

ApigeeKongWSO2MuleSoftIBM API Connect

# 0. Verify the accepted bytes and proof tier before preparing an export
anvil estate support apigee

# 1. Inventory, audit, and create a triage plan — without compiling an API
anvil estate inventory payments.apigee.normalized.yaml --vendor apigee
anvil estate audit payments.apigee.normalized.yaml --vendor apigee
anvil estate plan payments.apigee.normalized.yaml --vendor apigee \
  --gateway-id apigee-org-prod --init-selection estate-selection.yaml \
  --out estate-adoption-plan.json

# 2. Pair one selected API with its real contract and gateway URL
anvil estate import payments.apigee.normalized.yaml --vendor apigee --api payments \
  --gateway-id apigee-org-prod --strict-identity \
  --revision 12 --environment prod \
  --spec payments.openapi.yaml --gateway-url https://api.example.com/payments

Anvil safely opens supported ZIP/JAR containers: it refuses path traversal, symlinks, and decompression bombs. The archive reader is not a semantic translator—native Apigee proxy XML, Mule application JAR internals, and IBM x-ibm-configuration OpenAPI are not decoded by those adapters today.

If the adapter can’t fully read a gateway policy, it flags that policy for a human and holds the affected API back from shipping. Findings are owned by an API, route, or content-addressed artifact when the export proves that boundary, so one bad WSO2 project does not poison an unrelated selected API; genuinely estate-global parse or archive failures still fail closed. Nothing is ignored. What lands is an ordinary bundle, and the approval gate still stands between the API and the agent. New to this? Export your gateway, vendor by vendor →

An estate has 800 APIs. An agent should see five.

1. 01 The estate

   Roughly 800 APIs remain behind the gateway.

2. 02 Inventory

   List the whole catalog cheaply before compiling anything.

3. 03 Import

   Bring in only the handful of APIs that matter.

4. 04 Capabilities

   Group related operations into review-sized units.

5. 05 The agent

   Expose only the few approved operations it needs.

fig 10 · 800 APIs in the estate, five in the agent's hands

A production gateway holds hundreds of APIs, and almost none of them belong in an agent’s hands. Anvil is built for that ratio. inventory gives a bounded, filterable operator view; audit evaluates the complete estate; and plan creates a resumable, coordinate-aware triage queue. You then import the handful that matter, group their operations into review-sized capabilities (a capability is a set of related operations, like Refunds or Payments), and leave the other 795 where they are, behind the gate. How Anvil operates at scale →

Any spec in. Aligned tools out.

Enterprises don’t lack APIs — they lack agent-safe ones. A payments spec says a refund moves money; a WSDL says a transfer can’t be undone. That information is in the spec, but hand-written wrappers usually drop it. Anvil compiles it in.

1. Input Any supported spec

   OpenAPI, Swagger, GraphQL, gRPC, SOAP, Postman, Discovery, or a gateway export.

2. 01 Compile

   Parse, classify, and validate every operation.

3. 02 AIR

   Hold effect, risk, idempotency, auth, and approval in one shared model.

4. Gate Approve deliberately

   Unapproved operations never reach a generated surface.

5. Out Project together

   Generate the CLI, MCP server, skill, and harness hooks from that same contract.

fig 01 · one spec in, four aligned tools out — regenerated together, so they cannot disagree

Everything on the right is generated from the one model in the middle. Nobody hand-writes the CLI, the MCP tool descriptions, or the skill — so nobody can forget that a refund needs an idempotency key (a token that makes a repeated call safe: run it twice, it still counts once) in one place but not another.

The problem isn’t writing wrappers. It’s keeping them in sync.

Any team can wrap an API for one demo. The failure mode arrives six months later, when the CLI wrapper retries a payment the MCP wrapper wouldn’t, and the runbook says a third thing.

1. Drift Separate wrappers guess

   The CLI, MCP tool, and runbook can assign different retry and confirmation rules to one refund.

2. AIR One contract decides

   Anvil records the refund as financial, irreversible, and idempotency-key protected once.

3. Align Every surface agrees

   The CLI, MCP tool, and skill regenerate with the same confirmation, key, and retry behavior.

fig 02 · the drift problem — alignment is the product, not the code generation

Start with what you haveA 2004 WSDL and yesterday’s OpenAPI compile the same way. No rewrites, no SDK migrations, no wrapper team.Safety is compiled inWhat a call does, how risky it is, and whether it’s safe to repeat — all read from the spec and enforced by the runtime, not asked for in a prompt.Approval is the gateNothing reaches an agent until a human approves it. If the spec later changes in a way that loosens safety, that’s blocking — not a comment in a diff.Enforced in the harnessThe same contract installs as Antigravity, Claude Code, and Codex hooks that refuse unsafe calls before a token is spent.

Where enterprises point it first

Payments & billing

A refund is a financial, irreversible mutation — money moves and you can’t take it back. Anvil reads that from the spec, and every generated tool enforces it: the call refuses to run without confirm: true and an idempotency key, and it’s never retried automatically.

anvil compile stripe-payments.yaml --manifest payments.anvil.yaml \
  --human-approval unsafe --out generated/payments

anvil inspect generated/payments
# payments.refunds.create   mutation · financial · irreversible
#   confirmation: required (human approval)   idempotency: required

With --human-approval unsafe, the generated hooks — scripts the agent harness runs before each tool call, in Antigravity, Claude Code, and Codex alike — escalate the refund to a person; a model-supplied confirm: true can’t clear the gate.

Legacy core systems

The core banking system speaks SOAP, and it’s not getting rewritten this decade. Anvil compiles multi-file WSDL directly — the twenty-year-old spec becomes typed, gated agent tools with the same safety contract as the newest OpenAPI service.

anvil compile core-banking.wsdl --manifest banking.anvil.yaml --out generated/banking

No modernization project as a prerequisite. The spec you have is the input.

HR & PII

For an HCM system, reads are useful and mostly harmless — compensation changes are neither. Approve the reads broadly, gate the writes individually, and mark the sensitive mutations human_approval: true in the manifest so no agent can self-approve a salary change.

hcm.anvil.yaml

operations:
  updateCompensation:
    confirmation: { required: true, human_approval: true }

Customer messaging

An outbound SMS can’t be unsent, and a timeout doesn’t mean it wasn’t delivered. Out of the box, Anvil classifies sends high-risk — they demand confirmation and are never auto-retried. Then one line of manifest turns “please don’t re-run this” into a guarantee:

comms.anvil.yaml

operations:
  sendSms:
    idempotency: { strategy: required_request_key }

Now every generated tool requires an idempotency key, and a nervous agent re-issuing the call is a duplicate-suppressed no-op instead of a second text to your customer.

Three rings, one contract

Hooks make enforcement cheap and early; the runtime makes it inescapable. Every check lives in the innermost ring that can enforce it — the outer rings buy speed and human escalation, never correctness.

1. Core Runtime executor

   Authoritative and fail-closed: confirmation, idempotency, retries, egress, and redaction.

2. 02 Generated CLI and MCP

   Only approved operations exist on either callable surface.

3. 03 Harness hooks

   Fail-open preflight catches problems early and can escalate to a person.

4. Human Approval tier

   A model cannot clear an operation that is configured to require human approval.

fig 04 · defense in depth — hooks are the outer ring, never the only ring

One contract, enforced in Antigravity, Claude Code, and Codex — and visible to every MCP client.

Proof, not promises

The quality of the generated MCP server and skill is not asserted — each bundle demonstrates it about itself, with every record bound to the bundle’s content hash so stale evidence can never masquerade as current:

• anvil selftest boots the generated mock and MCP server, then invokes every approved tool over the real MCP transport — arguments reach the wire faithfully, confirmation gates refuse before any side effect, and non-idempotent mutations are never auto-retried.
• anvil conformance proves the skill, CLI, and MCP tool list agree — same operations, same handles, and a skill that documents the exact posture the runtime enforces. A skill that under-states a gate fails here.
• anvil simulate drives the full safety matrix through a deterministic simulator, then deliberately weakens each safety control and proves the surface catches the mutant.
• anvil certify is the static gate: byte-level surface agreement plus semantic checks (sibling operations may not share one description).
• anvil benchmark scores agent-task completion — tool discovery, parameter satisfiability, call success — and gates CI with --check.

On the public-corpus gauntlet (5,500+ operations across Stripe, GitHub, Jira, Twilio, Slack, Coda, Zendesk, TM Forum, Coupa, Workday, Zoho, Oracle OPERA, and a 2004-era SOAP service), fully-driven bundles pass every lane — Coda: 72/72 selftest, 136/136 conformance, 504/504 simulation cells with 4/4 safety mutants killed, 134/134 benchmark tasks.

Malleable by declaration

You never edit generated code and never fork the vendor spec. One declarative manifest layer reshapes the whole surface — rename operations, remodel a blocked end-user OAuth estate to per-caller token exchange with a single auth: { type: oauth2_on_behalf_of } line, enforce idempotency keys, replace a raw SQL passthrough with a constrained read-only query template — and anvil refine proposes evidence-gated improvements (descriptions, examples, intent phrases) that apply back to the model, never to one surface. Recompile, and the CLI, MCP server, and skill move together.

The loop

1. 01 Compile

   Turn the source specification into one complete bundle.

2. 02 Inspect

   Read risk, approval state, and the next safe action.

3. 03 Enrich

   Supply evidence for gaps the source could not prove.

4. 04 Approve

   Open only the operations whose contract you inspected.

5. 05 Release

   Run static assurance and executable evidence, then prepare an operator deployment plan.

fig 09 · the loop: compile, inspect, enrich, approve, release

# 1. Compile a spec into a full bundle (CLI + MCP + skill + hooks)
anvil compile <spec> --manifest <manifest> --out <dir>

# 2. Orient, then read every operation's effect, risk, and idempotency
anvil status <dir>
anvil inspect <dir>
anvil lint <dir>

# 3. Target the residue, then expose only what you have inspected
anvil distill <dir> --as-enrich-plan --write /tmp/anvil-enrich-plan.json
anvil approve <dir> <operation-id>

# 4. Package and statically assure the complete bundle, then exercise it
anvil package skill <dir>
anvil certify <dir>
anvil selftest <dir>
anvil conformance <dir>
anvil simulate <dir>

# 5. Verify the generated durable-write contract offline
anvil deploy ledger <dir> --project <project-id> --database <firestore-database>

# 6. Prepare the gated deployment plan; this makes no cloud call
anvil publish <dir> --env prod
anvil status <dir>  # planned · operator-action-required

Mutations that can’t be safely repeated land as review_required — held for review, not exposed until a human approves them. That refusal is the point. certify proves static byte and contract coherence; the three following commands add executable evidence without changing the bundle digest. The compatibility verb publish requires all four fresh records for that digest and records their evidence snapshot in a plan. A non-production plan can explicitly waive incomplete executable evidence with --allow-incomplete-evidence; production fails closed. A plan never means deployed or live.

Where to go next

Set up in one sitting

Install Anvil is the copy-paste path from a fresh clone to a working anvil command — three commands, a version check, and a first compile to prove it runs.

Compile your own spec

The playground runs the real compiler in your browser — paste an OpenAPI document and watch every operation get classified. Nothing is uploaded.

For enterprises

The conversion playbook: pilot one API, template the pipeline, and map Anvil onto the governance you already run.

Start Here

What Anvil is and the Quickstart get you from a spec to an aligned bundle.

Operate it safely

Operating Anvil is the progressive-disclosure manual: the compile → enrich → approve → release loop and the safety rules.

Connect Gemini Enterprise

Choose Custom MCP or Agent Gateway, keep sign-in, MCP OAuth, gateway IAM, and upstream credentials separate, and use the supported project/location matrix.

Design notes

Hooks and plugins shows how the safety contract ships into Antigravity, Claude Code, and Codex.