Skip to main content
Glama
Rutherford MCP Server

Rutherford MCP Server

by chapmanjw

login

Sign an ACP agent in when doctor reports auth_required: check authentication status or start a background sign-in, then share the returned link and poll the job.

Instructions

Sign an ACP agent in once, for an agent that doctor reports as auth_required.

Some agents open no session until a client has called ACP authenticate, then cache the credential themselves (Google Antigravity is one). No other Rutherford call signs in; this is the explicit place.

Without method it is read-only: status=authenticated if a session already opens, else status=method_required with the agent's advertised methods (id, name, kind). With method (an agent-kind id) it starts the sign-in as a background job, waits up to wait_s for the agent to print its sign-in link, and returns status=pending with job_id and signin_urls -- give the first link to the user, who completes the sign-in in a browser, then poll job_status / job_result. The job finishes authenticated once a session opens with the new credential (lifting any cooldown bench), fails with AUTH_FAILED (declined, the agent still refused a session afterwards, or no sign-in within timeout_s, which bounds the authenticate step), or with the agent's own handshake error if the confirming session fails for another reason. status=authenticated without method means a session opens and no ACP sign-in is needed; a turn may still need a provider key, which doctor checks. A repeated login while one is running returns that job (joined=true) instead of starting another (and status=cancelled if cancel_job ends it while the call waits); a different method then is refused with INVALID_INPUT until it finishes or is cancelled. The links are agent-authored, taken only from sign-in prompt lines, and never opened by Rutherford. An env_var method returns the variables to set (status=configure_env) and a terminal method returns the command to run (status=run_in_terminal); Rutherford never asks for or stores a credential value.

Input Schema

NameRequiredDescriptionDefault
agentYes
methodNo
wait_sNo
timeout_sNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.3.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains read-only status checks without `method`, background job creation with `method`, returned statuses, `join` behavior, cancellation, `AUTH_FAILED` conditions, cooldown lifting, and credential/link handling. It explicitly says Rutherford never opens agent-authored links and never asks for or stores credential values.

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 core purpose and usage condition are front-loaded, and the detail is largely justified by the complexity of the auth flow. However, it is a long single-paragraph description with some repeated status language, so it is less concise than it could be despite being well-targeted.

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?

The description is complete for a complex authentication tool with no annotations and a low-coverage input schema. It covers status outcomes, background-job polling, failure modes, repeated calls, method variants, credential handling, and the `env_var`/`terminal` cases, while the output schema can carry the return-value structure.

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

Parameters4/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, and it largely does: `method` behavior is explained in detail, `wait_s` is tied to waiting for the sign-in link, and `timeout_s` bounds the authenticate step. The `agent` parameter is clear in context as the agent that `doctor` reports as `auth_required`, though its exact accepted string format is not specified.

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 uses a specific verb and resource: "Sign an ACP agent in once." It also names the selecting condition ("for an agent that `doctor` reports as `auth_required`") and explicitly distinguishes this from other Rutherford calls: "No other Rutherford call signs in; this is the explicit place."

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?

It states when to use the tool, how the no-method versus method variants differ, and names relevant alternatives and follow-up siblings (`doctor`, `job_status`, `job_result`, `cancel_job`). It also explains repeated-login behavior and the `INVALID_INPUT` refusal for a different method while a job runs.

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