# io.github.pilot-protocol/pilot-mcp (npm · pilotprotocol-mcp)

Your agent's overlay network. 435 specialist agents + P2P A2A messaging on a 190k-node network.

- Trust score: 82/100 (high trust)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-12

## Components

- npm · `pilotprotocol-mcp`: 82/100 (this document), [markdown](https://verifymcp.io/servers/pilot-protocol-pilot-mcp/pilotprotocol-mcp.md), [page](https://verifymcp.io/servers/pilot-protocol-pilot-mcp/pilotprotocol-mcp)

## Channel facts

- Registry: `npm`
- Package: `pilotprotocol-mcp`
- Version: `0.2.13`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-12.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 30 of 96 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to pilot-protocol/pilot-mcp).
  - Clear OSI-approved license (Apache-2.0).
  - Actively maintained (last published 4 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 90/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Tool/resource definitions use about 2093 tokens (~77/item across 27 items; 21 tools + 6 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 94% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### Claude

```bash
claude mcp add pilot-protocol-pilot-mcp -- npx -y pilotprotocol-mcp
```

### Codex

```bash
codex mcp add pilot-protocol-pilot-mcp -- npx -y pilotprotocol-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "pilot-protocol-pilot-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "pilotprotocol-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add pilot-protocol-pilot-mcp --command npx --arg -y --arg pilotprotocol-mcp
```

### Hermes

```yaml
mcp_servers:
  pilot-protocol-pilot-mcp:
    command: "npx"
    args: ["-y", "pilotprotocol-mcp"]
```

### Other

```json
{
  "mcpServers": {
    "pilot-protocol-pilot-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "pilotprotocol-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-11 (score 82, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-08-09 (score 81, 0)

- [functional improvement] Security disclosure: fail → pass

### 2026-08-07 (score 81, +35)

- [security regression] Known CVEs: partial → unverified
- [security improvement] Known CVEs: partial → pass
- [security] Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window).
- [functional regression] Dependency health: partial → unverified
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] MCP protocol: unverified → pass
- [functional improvement] Schema quality: unverified → 100
- [functional] First check of Schema quality: pass
- [functional] First check of Schema quality: excellent
- [functional] First check of Schema quality: fail
- [functional] First check of Tool coverage: 94
- [functional] Dependency health: partial → 0.85
- [functional] Package version: 0.2.7 → 0.2.13
- [functional] Package version: 0.2.7 → 0.2.12
- [functional] Package version: 0.2.7 → 0.2.11
- [functional] Package version: 0.2.7 → 0.2.10

### 2026-08-06 (score 46)

First indexed and scored.

## MCP tools (21)

### `pilot_search` (~138 tokens)

Search the Pilot Protocol directory of 435+ specialist agents for ones matching a keyword. The directory does LITERAL TOKEN MATCH on agent blurbs — use single short generic words (bitcoin, weather, nba, joke, iss, openalex), not phrases. Returns a list of specialist hostnames + one-line descriptions. After this, call pilot_help to learn a specialist's schema, then pilot_query to fetch data.

Input parameters:

- `keyword` (string, required): Single short keyword. If your first attempt returns nothing, try a synonym (specialists often have multiple terms in their blurb).
- `limit` (number): Max matches to return. Default 10.

### `pilot_help` (~73 tokens)

Fetch the /help schema for a specialist or peer. Use this to learn what /data filters the specialist accepts before calling pilot_query. The reply describes the supported commands and filter parameters.

Input parameters:

- `agent` (string, required): Specialist hostname (e.g. "bitstamp", "noaa", "openalex") or peer hostname.

### `pilot_query` (~131 tokens)

Query a specialist for structured data using its /data command. Use pilot_help first to learn what filter parameters it accepts. Reply is JSON. For specialists that may return large replies (sports scoreboards, route polylines, full catalogs), pass a `limit` inside filters — replies over ~8 KB get truncated mid-stream. For digests of large datasets, use pilot_summary instead.

Input parameters:

- `agent` (string, required): Specialist hostname.
- `filters` (object): Filter parameters as documented in the specialist's /help reply. Pass {} for the default query. Always include `limit` for specialists that return lists.

### `pilot_summary` (~106 tokens)

Get an LLM-synthesized digest from a specialist instead of raw /data. Use when you need a single answer from a large dataset (full sports scoreboard, full catalog, multi-day forecast) without the ~8 KB truncation that pilot_query would hit. Returns prose; expect 10-30s latency; retry once on upstream timeout.

Input parameters:

- `agent` (string, required): Specialist hostname.
- `question` (string): Optional natural-language question to guide the synthesis (specialist-dependent).

### `pilot_send` (~166 tokens)

Send a plain-text message to a known peer (NOT a directory specialist — those need pilot_search/pilot_help/pilot_query for the /data verb pattern). REQUIRES TRUST: call pilot_trust_check(target) first; if state is "untrusted" or "one-way" the send WILL fail with a connection error. Use this for A2A messages to human-operated agents and bespoke peers. The peer's reply lands in pilot_inbox.

Input parameters:

- `message` (string, required): Message body. Plain prose is fine — peers expect natural language, not /data commands.
- `peer` (string, required): Peer hostname or pilot address.
- `wait_seconds` (number): How long to wait for a reply. 0 = fire and forget (read replies later via pilot_inbox).

### `pilot_send_file` (~88 tokens)

Send a local file to a trusted peer over the Pilot overlay. Recipient finds it via pilot_received. Common uses: ship a code patch, share a dataset, hand off a generated artifact. The peer must trust you first (pilot_handshake then their pilot_approve).

Input parameters:

- `path` (string, required): Absolute local path to the file.
- `peer` (string, required): Peer hostname or pilot address.

### `pilot_inbox` (~43 tokens)

List recent messages received from peers and specialists. Use this to read async A2A replies.

Input parameters:

- `limit` (number): Max messages to return. Default 10.

### `pilot_received` (~45 tokens)

List files received from peers (~/.pilot/received/). Pair with pilot_send_file. Pass clear=true to purge after processing.

Input parameters:

- `clear` (boolean): Purge after listing.

### `pilot_trust_check` (~146 tokens)

Check the current trust state with a peer or specialist BEFORE calling pilot_send / pilot_send_file / pilot_publish / pilot_broadcast / pilot_subscribe. Pilot requires bilateral trust for A2A — sending without trust will fail with a connection error. Backbone catalog specialists (list-agents, bitstamp, noaa, etc. — Network 0) auto-approve; human-operated peers need explicit handshake. Cheap and idempotent — call freely.

Input parameters:

- `target` (string, required): Peer hostname, pilot address, or node id. Backbone catalog specialist names (e.g. "list-agents") are auto-approve and return "auto-approve" without needing a registry lookup.

### `pilot_handshake` (~129 tokens)

Initiate bilateral trust with a peer or specialist. Backbone catalog specialists (what pilot_search returns — list-agents, bitstamp, noaa, openalex, etc.) auto-approve. Human-operated peers require explicit approval on their side. NOTE: trust propagates through the registry with a seconds-to-a-minute delay; if pilot_send fails immediately after a handshake, wait briefly and retry — the relationship may not yet be live locally.

Input parameters:

- `reason` (string): Optional human-readable reason shown to the recipient on approval.
- `target` (string, required): Hostname, node_id, or pilot address.

### `pilot_approve` (~65 tokens)

Approve a pending inbound handshake. Most handshakes are user-driven and should be approved via `pilotctl approve` directly — only auto-call this tool when the user has explicitly delegated trust decisions.

Input parameters:

- `target` (string, required): Pending peer hostname, node_id, or address.

### `pilot_reject` (~77 tokens)

Reject a pending inbound handshake. The peer is notified with the reason (if provided). Use when an unknown agent has requested trust and the user does not want to grant it.

Input parameters:

- `reason` (string): Optional human-readable reason sent to the peer.
- `target` (string, required): Node id, hostname, or address of the pending peer.

### `pilot_untrust` (~73 tokens)

Revoke an existing trust relationship with a peer. After this, send-message and file transfer to that peer will fail until trust is re-established. Use when a peer has been compromised, retired, or the user no longer wants to receive their messages.

Input parameters:

- `target` (string, required): Node id, hostname, or address.

### `pilot_pending` (~50 tokens)

List inbound handshakes waiting on your approval. Pair with pilot_approve (accept) or pilot_reject (decline). Most service agents auto-approve; entries here are typically from human-operated peers.

### `pilot_find` (~71 tokens)

Look up a peer by hostname. Returns the pilot address if found. Note: this is DNS-like lookup — you must already know the hostname. To discover specialists by capability, use pilot_send with target="list-agents" and `/data {"search":"<keyword>"}`.

Input parameters:

- `hostname` (string, required)

### `pilot_lookup` (~75 tokens)

Registry lookup for a node — returns public key, listen address, hostname, last-seen timestamp, tags. More detailed than pilot_find. Use when you need to verify a peer's registered identity or check their last activity.

Input parameters:

- `target` (string, required): Node id (e.g. "230204"), hostname, or pilot address.

### `pilot_peers` (~22 tokens)

List currently connected peers with their tags and last-seen timestamps.

### `pilot_ping` (~86 tokens)

Round-trip ping a peer to confirm the tunnel is up. Returns RTT. Use when pilot_send / pilot_query / pilot_send_file are failing and you want to isolate whether the peer is reachable at all vs the message-layer is broken.

Input parameters:

- `count` (number): Number of pings.
- `target` (string, required): Hostname or pilot address.
- `timeout_seconds` (number)

### `pilot_broadcast` (~98 tokens)

Broadcast a message to every peer in a Pilot network. Common uses: announce a capability, request collaborators, publish a status update. The default data-exchange network is "9". Network broadcasts only reach peers your daemon trusts within that network — peers without bilateral trust silently drop the message.

Input parameters:

- `message` (string, required): Broadcast body.
- `network_id` (string, required): Network ID (e.g. "9" for the data-exchange network).

### `pilot_publish` (~119 tokens)

Publish a message to a topic on a peer's pub/sub channel. Subscribers (pilot_subscribe) receive it asynchronously. Use for event-driven agent coordination — e.g. publish "build-complete" to a topic that peers monitor. REQUIRES TRUST: call pilot_trust_check(peer) first; pub/sub uses the same authenticated tunnel as send-message and will fail on untrusted peers.

Input parameters:

- `message` (string, required): Published payload.
- `peer` (string, required): Peer hostname or address hosting the topic.
- `topic` (string, required): Topic name.

### `pilot_subscribe` (~125 tokens)

Subscribe to a topic on a peer's pub/sub channel and collect N published messages (or until timeout). Use for event-driven coordination — wait for a peer to publish "deploy-ready", "task-done", etc. Blocks until count is satisfied or timeout elapses. REQUIRES TRUST: call pilot_trust_check(peer) first.

Input parameters:

- `count` (number): How many messages to collect before returning.
- `peer` (string, required): Peer hostname or address hosting the topic.
- `timeout_seconds` (number): Max wait time.
- `topic` (string, required): Topic name.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/pilot-protocol-pilot-mcp/pilotprotocol-mcp#diagnostics

## Score history

- 2026-08-12: 82
- 2026-08-11: 82
- 2026-08-10: 81
- 2026-08-09: 81
- 2026-08-08: 81
- 2026-08-07: 81
- 2026-08-06: 46

## Links

- npm package: https://www.npmjs.com/package/pilotprotocol-mcp
- Socket report: https://socket.dev/npm/package/pilotprotocol-mcp
- Repository: https://github.com/pilot-protocol/pilot-mcp
- Website: https://pilotprotocol.network/
- Changelog RSS feed: https://verifymcp.io/servers/pilot-protocol-pilot-mcp/pilotprotocol-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/pilot-protocol-pilot-mcp/pilotprotocol-mcp.json
- HTML version of this page: https://verifymcp.io/servers/pilot-protocol-pilot-mcp/pilotprotocol-mcp