Aviator MCP server: three tools, legacy path

A working connector the vendor has already labeled legacy, what its three tools do, and where Aviator says new capability is going instead.

Last verified 27 August 2026 · from Aviator's own Verify documentation

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.

What is the Aviator MCP server?

It is Aviator's server for the Model Context Protocol. Aviator Verify runs checks against a runbook, and the runbook is what these three tools manipulate.

The scope is narrow on purpose. This is not a connector to Aviator's merge queue, which lands pull requests in a tested order, or to its pull request automation. It is the submission path for one product.

The vendor's own framing is the important context. /verify-submit uses the CLI, and the documentation names the CLI as the preferred route. An integration built on these tools is built on a path that is not receiving new work.

The MCP server covers Verify submission in the CI and release stage, and reaches nothing else.

For an agent, Aviator's MCP server does one job: get a Verify runbook written and submitted. It does not reach the merge queue, the pull request automation or anything Aviator does outside Verify, so it is a narrow tool rather than a platform connector.

What can an AI agent do with Aviator?

All three tools operate on the runbook rather than on results. Reading a completed Verify run is not something this connector does.

What connecting costs before the first question

A context window is the amount of text a model can hold at once. Three tools is the whole surface, and the cost follows: between 465 and 627 tokens on Claude, a fraction of a percent of a 200,000-token window. Connecting costs that before the agent asks anything, because every tool the server registers sends its name and description to the model when the session starts.

Aviator's own documentation calls this the legacy path and points at its CLI instead. Read the figure below as the cost of the legacy route, not the recommended one.

Encodings: GPT-5.6, GPT-5.5 o200k_base; GPT-4, GPT-3.5 cl100k_base; Claude Haiku 4.5 to Opus 5 count_tokens. Counted from the 3 tool entries in the vendor's own documentation. That documentation is the only public inventory.

The server could not be run for a live tools/list. No input schemas are available, so these figures cover each tool's name and description only. They are a floor, not the figure.

The Claude columns are measured through the API's count_tokens endpoint with an empty schema per tool. So they cover the same content as the GPT columns. The range there is two tokenizer generations. Haiku 4.5 and Opus 4.6 are at the low end. Opus 5 and Sonnet 5 are at the high end. The gap between them is about a third.

Aviator MCP server limits: where answers come back incomplete

The first limit below is the one the vendor states itself, which makes it unusually easy to verify. Two more follow from the three tools.

How to configure Aviator MCP for agents

1. 1

   Decide against it for new work

   Aviator's documentation names the CLI as preferred and as the place new capability lands.

2. 2

   Keep it for existing installs

   The same page states the MCP tools still work and existing installations keep functioning.

3. 3

   Know the scope

   Three tools, all about the Verify runbook. Nothing here touches the merge queue.

4. 4

   Expect the CLI to diverge

   A capability that appears in the CLI is not guaranteed to appear here.

Paste this into your agent’s instructions

Two of the three tools write to the runbook that decides what Verify checks, and the whole path is legacy.

When you answer using Aviator MCP tools, state:
- The runbook you read or changed.
- Whether you called specSubmit or editRunbook. Both write,
  and the runbook decides what Verify checks.
- That the MCP server is Aviator's legacy submission path,
  if the question is about which route to build on.
Never state that data does not exist. State that no runbook
was returned for the identifier above.
Write your answer in ASD-STE100 Simplified Technical
English. Use short sentences with one idea in each.

Do you need the MCP server at all?

For new work, no. The Aviator CLI is the alternative, and it is the vendor's own recommendation. It is what /verify-submit uses and where new capability lands.

The connector earns its place only where an agent is already composing a runbook in the editor and an install already exists.

For the pull request state Aviator acts on, a repository connector reads the same checks and comments.

Use the Aviator CLI for new work. Keep the MCP server for installs that already work.

Aviator MCP server setup

Installation happens through Aviator's own interface with a token, rather than through a package manager.

Aviator's documentation covers authorization and versioning for the server on the same page as the tools.

# Install the Aviator MCP server from the Aviator UI,
# which provisions the token for you.

# Installed through the Aviator interface rather than
# by hand-editing a client configuration file.

# Aviator provisions the install and its authorization.
# Prefer the Aviator CLI for new work.

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

# The Aviator CLI is what /verify-submit uses, and where
# new capability lands.

Read-only access, permissions and security

• Two of the three tools write

  specSubmit creates a submission and editRunbook changes the runbook that decides what Verify checks.

• The runbook is the control surface

  Changing it changes what gets verified, which is a quieter change than failing a check.

• Authorization is Aviator's own

  The documentation covers it alongside versioning; the server holds no separate permission model.

• Legacy paths receive less attention

  A route the vendor has stopped adding to is a route that will receive fixes more slowly.

Troubleshooting

A capability exists in the CLI but not here

That is expected. Aviator's documentation states new capability lands in the CLI, not in the MCP server.

A submission behaves differently from `/verify-submit`

/verify-submit uses the Aviator CLI. The MCP server is the older submission path, so behavior can differ.

Verify checked the wrong thing

Read the runbook with getRunbook. editRunbook may have changed what the run verifies.

There are no tools for the merge queue

There are none. The documented MCP server covers Verify runbooks only.

Aviator MCP server: Reference

What engineers report

The clearest signal here comes from the vendor rather than from users, which is unusual and worth taking at face value.

Tool names, the legacy designation and the CLI preference were read from Aviator's own Verify MCP tools reference on 24 August 2026. The server installs through Aviator's interface rather than a package registry, so no tools/list capture was possible.

Should you connect an agent to Aviator?

Yes, though it is no longer actively maintained. Best for leaving working installs alone, and building anything new on the Aviator CLI.

Strongest fit

Teams with an existing Aviator MCP install that already does what they need.

Main advantage

Three clear tools for composing and submitting a Verify runbook from the editor.

Main weakness

Aviator has designated it legacy and directs new capability to its CLI.

Operational risk

Two tools write to the runbook, which decides what Verify checks.

Frequently asked questions