MCP server composition

arbora.mcp_server owns the arbora transport and composition boundary. The action implementations remain in the agent plane and epistemic-graph; arbora registers them once and exposes the same core through MCP and REST.

1. StartThe arbora command starts the single serving lifecycle.
2. ComposeThe server binds the shared tool and REST application runtime.
3. Connect authorityTyped agent-utilities services and epistemic-graph clients supply domain behavior.
4. Open the fleetLazy fleet meta-tools expose admitted connector services.
5. Host co-servicesAgent WebUI and messaging use the same composed process authority.

The serving lifecycle mints process authority, bootstraps the engine, installs the gateway application adapter, attaches the lazy fleet surface, starts the native WebUI host when configured, and then serves stdio or streamable-http. Optional WebUI imports remain lazy.

The fleet loader uses Arbora's native multiplexer. Its EG-backed catalog read is capability-gated on the generated kind-only AgentComponent.Search client contract. When that authority is unavailable, catalog refresh fails closed; it does not substitute a static reader. See Capability status.

Resident tool surface

The server registers exactly ten resident tools: the six MCP verbs find, ask, why, write, act, manage, plus the four fleet meta-tools find_tools, load_tools, unload_tools, multiplexer_status. No other MCP tool is registered; every other capability is reached through act/manage or the generated /api/v1 HTTP surface mounted alongside the explicit protocol-route table (arbora.api.http.protocol_routes).

The four fleet meta-tools map to internal fleet operations as follows — this is the published parity inventory for the resident-fleet slice of the tool-to-operation parity requirement:

Fleet meta-tool	Destination operation
find_tools	fleet.catalog.search
load_tools	fleet.tools.load
unload_tools	fleet.tools.unload
multiplexer_status	fleet.status