Loading ToolBench
MCP server that gives AI coding agents a live, structured understanding of a developer's local environment
DevTwin demonstrates solid tool design with 18 well-structured tools covering project diagnostics, health checks, and build/test execution. All tools have descriptions (avg 156 chars) and input schemas with typed parameters. Naming follows verb_noun convention (devtwin_detect, devtwin_health, devtwin_build). However, parameter descriptions are sparse, most lack detail on constraints, ranges, or expected formats. Output schemas are not documented in the source. Error handling guidance is absent. The workspace parameter is well-designed to avoid path confusion, but most other parameters lack actionable constraint documentation.
Run recognized project build commands discovered from project files, such as npm run build, ./gradlew build, xcodebuild build, or dotnet build. Only commands DevTwin itself recognized are ever executed, each with a timeout.
Scan monorepo subdirectories for ecosystems and run their recognized build commands. Use it to verify a backend change has not broken the Android, iOS, or frontend builds.
Run recognized project checks (tests and linters) discovered from project files, such as pytest, npm test, ./gradlew test, or cargo test. Only commands DevTwin itself recognized are ever executed, each with a timeout.
Store DevTwin configuration: default workspace, allowed workspace roots, command timeouts, and whether recognized project commands may be executed.
Dependency state per detected ecosystem: package manager, lockfile presence and consistency signals, dependency counts, and whether packages appear installed locally.
Output schemas not documented. Tools return structured data (health scores, drift items, service state) but LLMs cannot see what fields to expect. This forces agents to guess at response structure and risks extraction errors.
Parameter descriptions lack actionable constraints. 'limit' in devtwin_get_logs states '1-500' but most other numeric/string params omit ranges, formats, or valid values. LLMs cannot validate inputs without explicit constraints.
No error handling guidance. Tools like devtwin_build and devtwin_check can fail (command timeout, unrecognized command) but descriptions do not explain what errors mean or how to recover. Agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Detect what kind of project lives at the workspace: languages, ecosystems, and the evidence (files) behind each detection. Fast, file-based only.
Compare expected project state (runtime and tool versions declared in project files) against what is actually installed. Reports each mismatch as a structured drift item.
Diagnose a development failure. Give it the error or 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.
Return recent DevTwin tool activity (tool name, status, summary, timestamp), newest first.
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.
Scan monorepo subdirectories for ecosystems and run a health check on each. Returns per-ecosystem health score, runtime and dependency state, issues, and recommendations.
Deep health check of DevTwin itself: confirms the workspace is readable and that recognized commands can be spawned. Does not inspect the project.
Read-only commit-readiness summary: Git status (dirty, staged, conflicts), project health, and staged files that look like they may contain secrets. Never commits, stages, or modifies anything.
Produce an ordered preparation plan for a newly cloned repository: align runtimes, start required services, install dependencies, run checks. Never executes anything; each step is classified by blast radius (read_only, safe, requires_approval, dangerous).
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 devtwin_detect.
Clear all DevTwin state and configuration. DevTwin creates no database tables and writes no files, so nothing persists after this call.
Local service detection: which services (Postgres, Redis, and compose-defined services) this project appears to need, whether each is currently running or listening, and the evidence behind that conclusion.
Return DevTwin readiness and effective configuration: whether command execution is enabled, whether workspace roots are restricted, and which ecosystem adapters are registered.
devtwin_configure accepts additionalProperties: true with no schema for the config object. LLMs cannot know what fields are valid, leading to invalid configurations and silent failures.
Destructive operations (devtwin_remove, devtwin_build, devtwin_check) lack confirmation or dry-run support. An agent could accidentally clear all state or run untested commands without a safety gate.