DevTwin MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| dev_detectB | Detect what kind of project lives at |
| dev_healthA | Full environment health check: combines project detection, runtime versions, dependency state, required services, ports, and Git state into a 0-100 health_score with concrete issues and recommendations. |
| dev_driftA | Compare expected project state (required runtime/tool versions from project files) against what's actually installed locally. Reports each mismatch as a structured drift item. |
| dev_explain_failureA | Diagnose a development failure. Give it the error/output text (and optionally the command that produced it); it cross-references project type, runtimes, services, ports, and dependencies to rank likely root causes with evidence -- never asserting certainty beyond the evidence. |
| dev_project_infoA | Detailed project inspection: detected ecosystems, runtimes (installed vs required), build tools, test/build commands, environment variables in use, OS info, and Git state. Broader and slower than dev_detect. |
| dev_dependenciesC | Dependency state per detected ecosystem: package manager, lockfile presence/consistency signals, dependency counts, and whether packages appear installed locally (e.g. node_modules/, .venv/). |
| dev_servicesA | Local service detection: which services (Postgres, Redis, and compose-defined services) this project appears to need, whether each is currently running/listening, and the evidence behind that conclusion. |
| dev_checkA | Run recognized project checks (tests/lint) detected from project files,
e.g. |
| dev_prepareA | Produce a preparation plan for a (likely newly-cloned) repository: ordered steps to align runtimes, start required services, install dependencies, and run the project's build/test commands. This tool NEVER executes anything -- it only plans, and classifies each step's blast radius (read_only/safe/requires_approval/dangerous) for the caller. |
| dev_precommitA | Read-only commit-readiness summary: Git status (dirty/staged/conflicts), project health, and staged files that look like secrets. Never commits, stages, or modifies anything. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct aspect of the development environment: detection, health, drift, failure diagnosis, project info, dependencies, services, checks, preparation, and precommit. Even similar tools like dev_detect and dev_project_info are clearly differentiated by scope and speed. There is no ambiguous overlap that would cause an agent to select the wrong tool.
All tool names follow the consistent pattern `dev_` + lower_snake_case, using descriptive verbs or nouns (detect, health, drift, explain_failure, etc.). The naming convention is uniform and predictable, with no mixing of camelCase or inconsistent verb styles.
With 10 tools, the server is well-scoped and each tool serves a clear purpose within the domain of development environment analysis and preparation. The count is within the ideal range and avoids both bloat and insufficient coverage.
The tool set covers the full lifecycle for a diagnostics/preparation server: detection, health assessment, drift checking, failure explanation, dependency and service checks, test execution, preparation planning, and precommit readiness. No obvious gaps exist for the stated purpose, and the tools work together to provide comprehensive environment insight.