Agent Mesh

What agent-mesh MCP server does

The agent-mesh MCP server organizes multiple workers into fleets of independent operating-system processes. A fleet can contain agents with separate roles and prompts, and may use the default OpenCode runtime or an operator-configured runtime. Agents can work in parallel, exchange messages, ask questions, and return final results for collection.

Coordination actions are recorded in a ledger. Messages create per-recipient delivery records, including delivery, viewing, and acknowledgement state. Decisions can be opened as ratifications with a quorum, deadline, required sign-offs, and optional voter weights. Agents can cast or change their effective vote, while the underlying history remains recorded.

The project is an MIT-licensed core and is deliberately pre-1.0. Its stated boundary excludes provider-account management, credentials, billing, spending authority, external publication, and managed policy.

How it works

Use spawn_fleet to start a set of agents, or spawn_from_template to create one from a saved configuration. Templates can be versioned and reused. attach_agent adds a premade agent to an active fleet. Fleet state, health, timeouts, and final outputs are available through dedicated tools.

Agents communicate through direct or broadcast messages. send_messages provides atomic batches of up to 1,000 messages. Consumers can poll with get_inbox, which acknowledges received messages, or subscribe through server-sent events with subscribe_inbox. subscribe_events provides a fleet-wide event stream, optionally filtered by fleet.

The agent-mesh MCP server supports operational checks through ledger verification, build-identity reporting, and health inspection. The versioned verifier variants use read-only snapshots and return consistency information; they do not add ledger writes. Routing tools can match work against registered roles and skills, record outcomes, or produce advisory candidate projections without executing providers.

Setup and configuration

The published package is named meshfleet, not agent-mesh. Install it globally with npm install -g meshfleet, or clone the repository, install dependencies, and build it with npm install && npm run build.

For the published package, configure an MCP host to run npx -y meshfleet as a local server, then restart the host. The documented primary host is OpenCode. A source checkout can instead run its built dist/index.js entrypoint, but the source-checkout configuration is intended for development rather than release use.

The package includes a no-key demonstration command that uses a temporary ledger. A configured ledger can be inspected with the package explicitly selected through npx. MESHFLEET_DB_FILE can point to another ledger file when an existing database was created by a newer package version.

Runtime selection is operator-controlled. OpenCode is the default. Other runtimes require their own configuration; some require an absolute command, a version label, and an opaque workspace binding. Model selectors use the provider/model form where supported.

Tools and capabilities

• Spawn fleets, load saved fleet templates, attach agents, and set fleet-specific timeouts.
• List fleet and agent state, collect final outputs, and inspect health or build identity.
• Send direct, broadcast, or batched peer messages and receive them by polling or SSE.
• Write, query, and verify witnessed-delivery records.
• Open ratifications, cast votes, and resolve quorum decisions.
• Register agent capabilities, route work, recommend routes, and record routing outcomes.
• Discover premade agent personalities and run bounded peer discussions with ask_peer and wake_agent.

Limitations and notes

The agent-mesh MCP server does not itself provide provider credentials, account operations, billing information, quota data, authentication claims, or external attestation. Runtime wrappers own their authentication, and the server passes a scrubbed environment rather than reading or serializing credentials.

OpenCode is the first-class host described by the project. The core uses standard MCP, but broader host support is presented as demand-driven rather than guaranteed by the README. The project should therefore be tested with the intended MCP client and configured runtime before production use.

The source-only local-demo runtime is a deterministic worker for demonstrations and is not included in the published package. It does not silently replace failed real agents. Cryptographic signing and auditor-grade attestation belong to a separate paid layer, while coordination and verification remain part of the MIT core.