Veto

What veto does

The veto MCP server presents one MCP interface for APIs described by OpenAPI specifications. Instead of creating a separate agent tool for every endpoint, it gives the agent three stable operations: search for a suitable API action, describe its schema and next-call details, and invoke it.

This approach keeps the agent-facing tool surface fixed as the catalog grows. Existing APIs remain unchanged, while the runtime provides a common way to discover and call them. The same catalog can also be used from the command line, scripts, or generated Go code.

How it works

The veto MCP server can load multiple OpenAPI specification files into one catalog. An agent searches that catalog in natural language, inspects the selected operation, and then invokes it with the required information. The returned schema helps the agent understand what to call next.

Declared relationships between APIs guide multi-step work. For example, an order response can expose a customer ID; the agent can follow the configured relationship to search for and call the customer API. Veto relies on relationships declared in the API definitions rather than inventing endpoint links or loading the complete catalog into the model context.

Operations with approval requirements are held before execution. A person must approve the exact caller, operation, and parameters before the call proceeds. The runtime also records what ran while leaving secrets out of the record, according to the provided project description.

Setup and configuration

Install the command-line program with Homebrew, initialize it with one or more OpenAPI files, and start the MCP server over standard input and output:

brew install aiveto/veto/veto
veto init orders.yaml customers.yaml
veto serve --stdio

The repository's setup guide provides configuration examples for Claude, Cursor, and ChatGPT. Veto also exposes command-line forms for searching, describing, and invoking APIs, plus a JSON serving mode for scripts. Go callers can use the generated client supplied for the runtime.

Tools and capabilities

The three MCP tools are:

• Search: Find an API operation using natural-language intent.
• Describe: Inspect an operation's schema and determine what to call next.
• Invoke: Execute the selected operation under the runtime's controls.

The catalog can include multiple APIs, and links between services can support workflows such as resolving an order's customer or invoice. Approval gates can stop sensitive calls, including deletion operations, until a person reviews the request.

Limitations and notes

The veto MCP server requires OpenAPI specifications as its API catalog input. Its relationship-aware behavior depends on links declared in those definitions; it does not infer relationships from unspecified API behavior. The project description also indicates that agents receive the three catalog tools rather than individual tools for every endpoint.

Approval is not a general guarantee that every operation will pause: the relevant operation must have an approval requirement configured. The supplied material documents standard-input MCP serving and does not specify other transport modes, authentication mechanisms, or deployment environments.