run402-mcp

Overview Schema Source Related Servers Discussions Admin

doctor

Run local health and configuration diagnostics for run402 projects, returning blocking issues, warnings, and check results so you can identify setup problems before using the database.

Instructions

Local health and configuration diagnostics (r.doctor()): { ok, blocking[], warnings[], checks[] }, the same report as run402 doctor. ok is false only on a blocking finding. Any other operation is a run snippet against r, the Node SDK client; docs is its reference.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "doctor"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	No	Target this project's vault check. Omitted: the repository's own remote, else the active project.

Output Schema

Name	Required	Description	Default
`error`	No
`result`	No
`status`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv4.126.1Oct 22, 2026

addedOutput schema / properties / error / properties / diagnostics

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "code": {
+        "type": "string"
+      },
+      "column": {
+        "type": "integer"
+      },
+      "line": {
+        "type": "integer"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "line",
+      "column",
+      "code",
+      "message"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / error / properties / diagnostics_ref
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / error / properties / diagnostics_total
```
Added value: +{
+  "type": "integer"
+}
```

AddedSep 25, 2026

TDQS

A3.6/5.0

Behavior3/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. It usefully discloses the return fields and the ok-semantics ('ok is false only on a blocking finding'), but never states that the tool is read-only / side-effect-free, which an agent would want to know before invoking a diagnostics call.

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?

Front-loads the purpose, then the return shape, then the sibling routing. Slightly dense with backtick code references, but every clause carries information; no 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, yet the description still summarizes the response shape and the blocking-vs-warning distinction, so an agent knows what success/failure looks like. Adequate for a single-optional-param diagnostic tool; only the read-only guarantee is unstated.

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?

Only one parameter and schema_description_coverage is 100%, so the schema already documents the project_id fallback behavior entirely. The description adds nothing beyond the schema, which is the expected baseline.

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

Purpose4/5

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

States a specific verb+resource ('Local health and configuration diagnostics') and names the concrete entry point (r.doctor()) plus the exact return shape. It partially distinguishes from siblings by carving out `run`/`docs`, but does not clarify against `status`/`whoami`.

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?

Explicitly routes other operations to a `run` snippet against `r` and points at `docs` as the reference, which tells the agent when NOT to use this tool. What's missing is a positive 'use this when you need to verify ...' condition and any comparison to `status`.

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

Deploy Server