Your entire API platform. Just 3 MCP tools.
Your APIs are already built.
Point veto at your OpenAPI specs. An agent gets three tools: search, describe, and invoke. You name how the APIs connect. A delete waits until a person approves it.
No API rewrites. The agent does not get a tool for every endpoint.
See it yourself: Run the Harbor demo. Mara's order, the customer and invoice links, and a delete that waits.
100 endpoints. 1,000 endpoints. Still 3 MCP tools.
search → describe → invoke
- Search. Find the right API using natural language.
- Describe. Discover its schema and what to call next.
- Invoke. Execute it with built-in controls.
Your API catalog grows. Your agent's tool surface stays the same.
Your APIs are connected. Your agents should know that.
Ask: "Who placed order 123?"
orders.get → customerId 7 → customers.get
Veto uses declared relationships to guide the next API call. No guessed endpoints. No invented relationships. No loading the entire API catalog into context.
Agents can act. You stay in control.
Ask: "Delete order 123."
Veto holds the operation until a human approves the exact caller, operation, and parameters. When approval is required, the operation cannot proceed without it.
One OpenAPI catalog. Multiple ways to use it.
One catalog. One runtime. Consistent behavior across interfaces. Module github.com/aiveto/veto.
Get started
Already have OpenAPI specs? You're three commands away from your first MCP server.
brew install aiveto/veto/veto
veto init orders.yaml customers.yaml
veto serve --stdio
The setup guide has the block for Claude, Cursor, or ChatGPT.
See Veto in action
Harbor is a working example: orders, customers, billing, the links between them, and a delete that waits. make demo runs it over the CLI, then over MCP.
No model API key for the local example in this repo: go run ./examples/two-apis.
You already have the APIs. Give your agents a better way to use them.