veto

Turn existing OpenAPI services into tools AI agents can discover and call under your rules.

The model may request a call. Veto checks policy, requires approval for a destructive call, and resolves credentials before your API runs. Declared relations name a linked operation. A trace records the decision.

The model proposes. Veto decides. Your API executes.

Connect an MCP client, or embed the Go runtime. MCP, the CLI, eval, and a generated Go client share that runtime. The client calls the catalog through search, describe, and invoke. A hundred endpoints do not become a hundred tools. Your services stay where they already run.

brew install aiveto/veto/veto

go install github.com/aiveto/veto/cmd/veto@latest

brew does not need Go. go install needs Go 1.27.1. Binaries are on GitHub Releases. A release also pushes ghcr.io/aiveto/veto.

See veto in action

veto-demo is the full walk. Harbor sells home goods. Orders, customers, and billing are the APIs. The walk follows a customer from an order, holds a delete until a person approves it, and keeps the secret out of the trace. make demo runs the story. make mcp leaves Harbor listening and prints the config for Claude, Cursor, or ChatGPT.

This repo runs the relation, the held delete, and the redacted trace, then exits. No model key.

git clone https://github.com/aiveto/veto.git
cd veto
go run ./examples/two-apis

Someone asked who placed order 123.
orders.get returned customerId 7.
customers.get was called for 7 because the note said Order.customerId identifies customers.get.
orders.delete sent no HTTP until approved.
The trace left the secret out.

Related MCP server: MCP Toolshed

A delete waits

Agent requests the call                          -> pending ID; no upstream HTTP
Person accepts the form in the chat              -> one matching invocation
Host without that form: veto approve <id>        -> approved ID, then the agent submits it once

The approval is bound to the caller, the operation, and the parameters. Permission and confirmation run before credentials are fetched and before HTTP. An OPA allow does not skip those checks. A webhook or a command can notify your approval system. The server and veto approve share approval storage and signing configuration. confirmation: false in veto.yaml turns that gate off for the deployment. Unset leaves it on.

A per-caller limit stops a call before policy. Timeouts and retries apply to the call that is sent.

The next call is declared

relations:
  - schema: Order
    field: customerId
    to: customers.get

Search returns the related operation. Describe returns the note, such as Order.customerId identifies customers.get. The Go Follow API walks that link. MCP invoke runs one operation. Relations.

What the agent receives

The tool names are capabilities_search, capabilities_describe, and capabilities_invoke. Direct pins add a few operations beside those three. Grouped mode adds one tool per resource. Search matches the summary, tags, the path noun, and synonyms such as retire for delete. An overlay can add a word of your own.

Response shaping returns named fields and a bounded list, and marks pagination and truncation. A Go context pack holds rules, operation summaries, the conversation, relations, and a pending confirmation, inside a byte budget. The raw OpenAPI document stays out of the pack.

Connect your services

veto init writes veto.yaml for the OpenAPI files or URLs you name, and a relations.yaml stub if you do not have one. If veto.yaml is already there, init stops.

veto init orders.yaml customers.yaml

veto serve --stdio speaks MCP on stdin. Authenticated Streamable HTTP serves the same runtime to a remote client.

Credentials come from the environment, OAuth, a caller-supplied token, token exchange, a command that returns headers, or a Go provider that signs the request. The agent does not perform that login. Authentication.

Check it

Traces are OpenTelemetry. OTLP export is optional. The Go model and memory interfaces, and sequential flows, run in-process. They are not a durable workflow service.

veto validate --config testdata/veto.yaml
veto eval --config testdata/veto.yaml --case testdata/delete.yaml
veto serve --config testdata/veto.yaml --stdio

testdata/veto.yaml is already written, so these commands start at validate. eval runs the delete case in this repo. serve --stdio is the MCP process. A call needs an API that is still listening, which is what veto-demo keeps up.

Scope

Pre-1.0. Public APIs may change.

Setup guide | Current limits