MCP server overview

Aerandil ships a first-class Model Context Protocol server (protocol revision 2025-11-25, negotiating down to 2025-06-18 for older hosts). It turns the same governed ontology the REST API serves into a surface an AI agent can drive directly — no glue code, no hand-written tool wrappers.

What it exposes

• Every registered action is a typed MCP tool. The tool’s input schema is the action’s schema, so an agent gets the same validation the REST API enforces. Apply apply_rate_recommendation or assemble_package_sale as a tool call.

• Every tool carries behaviour annotations — read-only and mutating hints — so a host can gate its confirmation UX before a call ever reaches the engine.

• Every object type is a resource, addressable with a URI template:

  aerandil://object/<type>/<id>

  An agent can read a booking or a folio by URI without a bespoke endpoint.

Transports

The server speaks two transports from one implementation:

• stdio — for local hosts that launch the server as a subprocess (editors, desktop agents).
• streamable HTTP — for networked hosts, sharing the API’s auth.

The library is host-agnostic; the production host binary reuses the REST API’s engine, store, and auth wiring rather than duplicating it, so the MCP surface and the HTTP surface can never drift apart.

Authentication

The MCP server authenticates against the same OAuth 2.1 identity as the REST API — an agent is bound by exactly the action scopes its credentials carry. See Authentication for how scopes map to actions.

Note

A per-tool reference (every MCP tool, its input schema, and the scope it requires) is generated from the action registry — the same registry that backs the API reference. That generated catalogue is being wired in; until then, the API reference is the authoritative list of actions.