Rutherford MCP Server

Overview Schema Source Related Servers Discussions Admin

doctor

Probes each ACP agent with a real read-only round trip, reporting whether it spawns, handshakes, and answers with a conformance status.

Instructions

Probe each agent (or one named agent) with a real read-only ACP round trip and report conformance.

The trustworthy health check for ACP agents: whether each spawns, handshakes, and answers. Each report is ok / no_answer / model_unavailable / handshake_failed / auth_required / not_installed / error. auth_required means the agent is installed but holds no credential yet; sign it in once with login. model_unavailable means spawn + handshake succeeded (the agent is reachable) but the harness/provider rejected the model on the turn (a model/provider config issue, e.g. a Claude Code on AWS Bedrock / Vertex), so it is NOT reported as a broken agent. Slower than capabilities (it makes a real call per agent); run it to see which of the roster actually drive on this machine. connect_only runs the lighter handshake-only check (spawn + handshake, no prompt) and reports reachable / handshake_failed / auth_required / not_installed plus each agent's advertised models -- it shows whether Rutherford can talk to and configure an agent even when a model call would fail for a reason outside ACP (an auth / entitlement / quota issue, e.g. Grok without a SuperGrok subscription).

When an agent (codex / claude_code / pi) launches a separate npm ACP adapter shim and that shim is not installed but its underlying CLI is (you have codex/claude/pi), the report adds an install_hint with the exact npm i -g <package> command instead of a flat not_installed -- run that, or setup install_adapters=true, to set the adapter up.

Input Schema

Name	Required	Description	Default
`agent`	No
`timeout_s`	No
`connect_only`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv3.0.2Jun 21, 2026

addedInput schema / properties / agent

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / connect_only

Added value: +{
+  "default": false,
+  "type": "boolean"
+}

removedInput schema / properties / live

Removed value: -{
-  "default": true,
-  "type": "boolean"
-}

addedInput schema / properties / timeout_s

Added value: +{
+  "default": 60,
+  "type": "number"
+}

First observedv0.1.1May 31, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden and does so: it discloses that the probe is read-only, that it costs a real call per agent and is therefore slow, and it defines every possible outcome (ok / no_answer / model_unavailable / handshake_failed / auth_required / not_installed / error), including the important nuance that `model_unavailable` is NOT a broken agent. It also explains the `install_hint` augmentation for shim-backed agents (codex / claude_code / pi).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the `capabilities` comparison are front-loaded, and every paragraph does real work (status glossary, connect_only mode, install_hint path). It is still noticeably wordy — long parentheticals about Bedrock/Vertex and SuperGrok could be trimmed — but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, yet the description usefully enumerates result statuses anyway. Combined with the sibling routing and remediation paths, an agent has nearly everything needed; the only real hole is the undocumented `timeout_s` and no hint about how long a full-roster probe takes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It covers two of three parameters — `agent` ("probe each agent (or one named `agent`)") and `connect_only` ("runs the lighter handshake-only check (spawn + handshake, no prompt)") — but never mentions `timeout_s` or its default of 60 seconds, leaving a full third of the surface undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — probe each agent with a real read-only ACP round trip and report conformance — and explicitly positions itself against the sibling `capabilities` ("Slower than `capabilities`... run it to see which of the roster actually drive"). An agent can distinguish `doctor` from `capabilities` without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use and when-to-use-something-else: run `doctor` for a real call per agent, use `connect_only` for the lighter handshake-only check, use `login` when the result is `auth_required`, and run the install hint or `setup install_adapters=true` when a shim is missing. Each alternative is named with the condition that selects it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server