rush

Overview Schema Source Related Servers Discussions Admin

rush_doctor

Diagnose environment health, toolchain integrity, and binary resolution at a specified path to identify issues and return a summary of findings.

Instructions

Diagnose environment health, toolchain integrity, and binary resolution at . Returns {status, findings[], summary}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	No		.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`raw`	No
`tool`	No
`engine`	No
`status`	No
`metrics`	No
`summary`	No
`findings`	No
`metadata`	No
`artifacts`	No
`duration_ms`	No
`review_kind`	No
`engine_version`	No
`review_provider`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.2Sep 15, 2026

changedOutput schema / properties / metrics / anyOf

Previous value: -[
-  {
-    "additionalProperties": {
-      "anyOf": [
-        {
-          "type": "integer"
-        },
-        {
-          "type": "number"
-        },
-        {
-          "type": "string"
-        }
-      ]
-    },
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "number"
+        },
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv0.3.0Aug 30, 2026

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses the output contract '{status, findings[], summary}', which is useful, but it does not mention side effects, prerequisites, network/local behavior, or whether the tool is purely read-only. 'Diagnose' implies non-mutating, but that is left to inference.

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

Conciseness5/5

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

A single, front-loaded sentence that states the action, target, and return shape. Every word earns its place; there is no filler or redundancy.

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?

For a tool with one optional parameter and an output schema, the description is nearly complete: it names what is diagnosed and the response envelope. It lacks guidance on when to use it among sibling tools, but the output schema covers return-value details.

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

Parameters2/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, but it only repeats '<path>' as a placeholder. It does not explain what path should point to, how the default '.' behaves, or what kinds of paths are valid beyond the schema's format: 'path'.

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?

Description names a specific verb ('Diagnose'), explicit resources ('environment health, toolchain integrity, and binary resolution'), and a scope ('<path>'). This differentiates it from the many sibling rush_* tools, which focus on linting, testing, benchmarking, or scanning, not environment health.

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

Usage Guidelines3/5

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

The description clearly implies the tool is for diagnosing environment/toolchain/binary issues, but it does not state when to prefer it over related tools such as rush_scan or rush_continuity, and it provides no exclusions or alternative recommendations. Context is present but not explicit.

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

Deploy Server