Skip to main content
Glama
chapmanjw

Rutherford MCP Server

by chapmanjw
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

setup

Scaffold a starter config.toml and show where configuration lives. Optionally write the file, trust the workspace, or install missing ACP adapters.

Instructions

Show where config lives and scaffold a starter config.toml; the first-run helper.

scope is project (<cwd>/.rutherford/config.toml) or global (the platform config dir's config.toml). It returns the proposed starter content (the most useful settings at their effective defaults) and the resolved path, plus a snapshot of the agents you already have. Pass write=true to create the file -- it never overwrites an existing one (already_exists=true, written=false). trust_workspace=true adds the current directory to trusted_workspaces so write/yolo delegations are permitted there.

The adapters block reports agents whose underlying CLI is installed but whose npm ACP adapter shim is not (codex needs codex-acp, claude_code needs claude-agent-acp, pi needs pi-acp -- what doctor flags as not_installed with an install hint). Pass install_adapters=true to run npm i -g <package> for each of those automatically (an explicit, opt-in machine change; off by default).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoproject
writeNo
trust_workspaceNo
install_adaptersNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.2.0
  2. Removedv3.1.0
  3. Changed10 schema fields changedv3.0.2
    • removedInput schema / properties / apply
      Removed value: -{
-  "default": false,
-  "type": "boolean"
-}
    • removedInput schema / properties / default_persistence
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}
    • removedInput schema / properties / force
      Removed value: -{
-  "default": false,
-  "type": "boolean"
-}
    • addedInput schema / properties / install_adapters
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
    • removedInput schema / properties / panel_name
      Removed value: -{
-  "default": "default",
-  "type": "string"
-}
    • removedInput schema / properties / safety_mode
      Removed value: -{
-  "default": "read_only",
-  "type": "string"
-}
    • changedInput schema / properties / scope / default
      Previous value: -"global"New value: +"project"
    • addedInput schema / properties / trust_workspace
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
    • removedInput schema / properties / trusted_workspaces
      Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}
    • addedInput schema / properties / write
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  4. Addedv2.0.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden — and it delivers. It discloses the safety-critical non-overwrite guarantee ('it never overwrites an existing one'), flags install_adapters as 'an explicit, opt-in machine change; off by default', and explains what the adapters block reports and how trust_workspace affects write/yolo delegations. This is exemplary behavioral disclosure for a setup tool.

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?

The description is long, but every sentence earns its place: core purpose is front-loaded, then scope semantics, then write/overwrite guarantees, then the adapters block and opt-in install behavior. It is dense rather than padded, and well-paragraphed. A slight reorganization could tighten it, but nothing is waste.

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

Completeness5/5

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

Despite 4 parameters, 0% schema coverage, and no annotations, the description covers purpose, all parameters, key return flags (already_exists, written, content, path, agent snapshot), and side effects. It even explains the adapter-shim gap it detects. Given the output schema exists, the description needn't detail full return structure, making this complete for an agent to select and invoke correctly.

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

Parameters5/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 fully compensate — and it does. All four parameters get semantic meaning beyond raw type/default: scope maps to concrete paths, write is tied to the no-overwrite behavior, trust_workspace names the trusted_workspaces effect, and install_adapters spells out the npm i -g <package> action. Every parameter is explained.

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?

The description opens with a specific verb+resource pair: 'Show where config lives and scaffold a starter config.toml', and labels the tool 'the first-run helper'. This clearly distinguishes it from siblings like doctor, delegate, or list_roles, none of which concern config scaffolding. An agent can immediately tell what this tool is for.

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

Usage Guidelines4/5

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

The 'first-run helper' label gives clear context for when to use it, and the description cross-references doctor ('what doctor flags as not_installed'), helping an agent understand the relationship between the two tools. It lacks an explicit 'use X instead when...' exclusion, but the context is strong enough that an agent would not misuse it.

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

Deploy Server

Other Tools