Local Dev Doctor MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOCAL_DEV_DOCTOR_ALLOWED_ROOTS | Yes | Required. Path(s) to allowed project roots. Use the platform path separator to provide more than one allowed root. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_diagnosisA | Create a bounded, secret-redacted local development diagnosis session. |
| list_diagnosesA | List persisted diagnosis sessions without reading their projects. |
| get_diagnosisB | Return the profile, preflight checks, probe evidence, and cited issues. |
| discover_profileA | Refresh the dynamic dependency profile and invalidate stale diagnostic results. |
| run_preflightA | Check executable, environment-name, and loopback port state without command execution. |
| prepare_probeA | Create an exact discovered-command plan and a one-time approval token. |
| execute_probeA | Execute one approved argv probe and persist bounded, redacted output evidence. |
| analyze_failuresB | Build deterministic issues and optional host hypotheses bound to known evidence IDs. |
| build_runbook_reportB | Write a redacted Markdown and JSON runbook in the external state directory. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| diagnosis_prompt |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct stage of the diagnosis pipeline: session creation/listing/retrieval, profile refresh, preflighting, probe preparation/execution, failure analysis, and report generation. No two tools appear to perform the same action, and the phase-specific descriptions make misselection unlikely.
All tool names follow a consistent imperative verb_noun snake_case pattern such as start_diagnosis, execute_probe, and build_runbook_report. The object nouns are descriptive and align with the workflow, with only expected singular/plural variation.
Nine tools is well within the ideal scope for a specialized diagnosis server. Each tool corresponds to one necessary step in the diagnostic lifecycle, so the count feels intentional rather than padded or sparse.
The tool surface covers the full diagnosis lifecycle: session setup, session retrieval, profile refresh, preflight checks, approved probe execution, failure analysis, and runbook report generation. There are no obvious dead ends or missing operations for the stated purpose.