为 AI 编码代理提供对本地开发环境的实时、结构化理解。
DevTwin 是一个模型上下文协议（Model Context Protocol，MCP）服务器，它为一个 AI 编码代理回答一个核心问题：为什么这个开发者的环境不同、损坏或不健康？
它检测项目技术栈，对照项目实际要求检查已安装的运行时版本，检查依赖和锁文件状态，查找所需的本地服务（Postgres、Redis，……）以及它们是否在运行，检查端口和 Git 状态，并将所有这些转化为结构化的、基于证据的诊断结果——绝不会将你的环境发送到云端后端，也绝不会向模型暴露任何机密值。
Related MCP server: devscope
AI 编码代理读代码没问题，但对代码实际运行的环境却视而不见。
“为什么 npm test 在我的机器上失败？”通常与代码无关——而是 Node 版本不匹配、服务没有运行，或者依赖从未安装。
DevTwin 为代理提供高级工程师手动收集的相同信号——node --version、git status、lsof -i :5432、docker ps——以结构化工具调用的形式，而不是靠猜。
这通常是开发者问的第一个问题，而且问得合理。在像 Claude Code 这样已经有 Bash 工具的客户端里，你可以直接让它运行 node --version、docker ps、lsof -i :5432 等命令——不需要 MCP 服务器。DevTwin 拉平的差距不是“到底能不能做到”，而是这些：
没有 DevTwin（原始 Bash） | 使用 DevTwin |
代理可以运行任何东西，包括破坏性命令，甚至可能是无意中。 | 零任意执行——只允许固定的只读/安全检查白名单。参见安全模型。 |
每次会话都会选择不同的调查方法；可能会错过生态系统的边缘情况（Gradle wrapper 与系统 Gradle， | 每个生态系统每次都运行同样经过精心挑选和测试的检查。 |
像 | 结构上永远不会返回机密值——只报告存在与否。参见隐私模型。 |
只在有 shell 工具的客户端中工作（Claude Desktop 不行，某些 IDE 插件也不行）。 | 在任何 MCP 客户端中工作，不管有没有 shell。 |
~6 次独立往返才能诊断一个故障。 | 1 次调用。参见实际示例。 |
针对 Claude CLI 的诚实回答： 由于它已经有 Bash，DevTwin 在这里的赢面比“你原本没有的能力”要小——它是安全保证和一致的结构化输出，而不是全新的访问能力。这也是为什么它不是免费的——连接它实际要花多少 token、什么时候值得，请参见 Token 成本。
在采纳之前，还有几个问题值得问：
“这不就是一个多了几步的 doctor 脚本（make doctor、bin/setup）吗？” 从概念上讲，是的——很多成熟仓库已经手工写了一个。DevTwin 的不同之处在于，大多数仓库没有这样的脚本；为每个生态系统写好一个确实是实打实的工作；它的输出是结构化的 JSON，可供代理推理，而不是供人类阅读的纯文本；而且同样的 10 个工具在每个仓库中都以相同方式工作，而不是每个项目一个带有自己约定和盲点的定制脚本。
“这只适用于 Claude / Claude Code 吗？” 不是。DevTwin 使用标准的模型上下文协议——任何兼容 MCP 的客户端（Claude Desktop、Cursor、Windsurf 等）都可以用同样的方式连接它。它与 Claude 没有任何特殊绑定。
“依赖它安全吗——它是否在积极维护？” 它处于 Alpha 状态，是一个年轻的项目——在把它用于你依赖的工作流之前，请阅读代码（它很短），就像你对待任何新的开发工具依赖一样。
“它会不会建议错误的东西，或者自动运行一个不好的推荐？” 这里没有任何工具会执行 recommendations 字符串——那些只是供代理（或你）阅读并决定的文本。dev_check 是唯一会执行任何内容的工具，而且只执行它自己从项目文件中识别出来、并对照固定白名单检查过的命令——参见安全模型。
“它会回传数据或向任何地方发送遥测吗？” 不会。它自身零网络调用——参见本地优先架构。
“我不希望 MCP 服务器在我的机器上运行任何命令。” 10 个工具中有 9 个是纯只读的（文件读取、版本检查）。只有 dev_check 会执行任何内容，而且只执行 DevTwin 自己从项目文件中识别、并对照白名单检查过的命令，使用 shell=False 和超时——关于它允许和不允许的确切范围，参见安全模型。
更少的错误诊断。 没有 DevTwin 时，代理在调试失败时只能读代码和猜测——它常常会对实际上只是 Node 版本不匹配或数据库停止的问题提出代码修复。DevTwin 给它的不是猜测，而是事实。
一次调用代替多次调用。 一次 dev_health 调用把约 10 项底层检查（运行时版本、依赖状态、服务、端口、Git）捆绑成一个结构化的、带评分的结果——而不是让代理做十几次独立的 shell 往返，并每次都解析原始 CLI 输出。
每次都是同样的检查。 每个生态系统的具体检查（Gradle wrapper 与系统 Gradle，.nvmrc 与 package.json 的 engines……）被编码一次，因此诊断在多次会话之间保持一致，而不是取决于代理碰巧想到要运行什么。
比给代理一个 shell 更安全。 绝不执行任意命令，绝不进行破坏性操作——参见安全模型。
绝不触碰机密。 对看起来像机密的环境变量只检查是否存在；永远不会读取或返回其值——参见隐私模型。
在代理没有 shell 的地方也能工作。 没有 Bash 工具的 MCP 客户端（某些 IDE 助手、受限代理）也能获得这种能力，而不是完全没有能力。
真实数字，不是估算——直接从这个服务器自身的 MCP 工具模式（mcp.list_tools()）和一个真实的 dev_health() 响应测量而来，使用标准的每 token 约 4 个字符的近似值。
两个不同的时刻会消耗 token，而且成本差别很大：
时刻 | 发生什么 | 成本 |
客户端连接到 DevTwin 的时刻 | 所有 10 个工具模式（名称、描述、参数）都被添加到该会话的每个请求中——无论工具是否被调用。这是任何 MCP 服务器的共性，并非 DevTwin 特有。 | ≈1,400 token，每一轮都如此 |
只有在工具实际被调用时 | 该工具的 JSON 响应被添加到上下文中，一次。 | 每次调用约 120-200 token（根据发现的问题数量而变化） |
每个工具的模式大小明细（实测）：
工具 | 模式大小 | ≈ token 数 |
| 440 字符 | ~110 |
| 500 字符 | ~125 |
| 470 字符 | ~117 |
| 793 字符 | ~198 |
| 523 字符 | ~130 |
| 507 字符 | ~126 |
| 507 字符 | ~126 |
| 771 字符 | ~192 |
| 645 字符 | ~161 |
| 481 字符 | ~120 |
总计（全部 10 个工具） | 5,637 字符 | ≈1,400 |
诚实的底线： 对于会话中单次一次性诊断（该会话其他时间完全不涉及环境问题），原始 Bash 在总 token 上可能更便宜——约 1,400 token 的固定模式税往往超过用一次调用替换多条 shell 命令省下的 token。双方的真实数字见下面的实际对比。
一个会话中出现的环境问题越多，DevTwin 的理由就越充分（固定税只付一次；之后的每个问题在 DevTwin 上约 150 token，而在原始 Bash 上每次都要多花几百 token）——它的真正优势根本不是原始 token 数量，而是一致性、安全性，以及在没有 Bash 工具的 MCP 客户端中也能工作。参见优势和诚实的权衡。
实际启示： 按项目注册 DevTwin，而不是按用户注册，这样固定税只在实际有用的会话中支付——参见在其他项目上使用。
DevTwin 不是一个用于稳定环境的日常工具——没有人需要在写的每个函数上都重新检查“Postgres 是否在运行”。它是一个应急工具：在特定时刻价值很高（刚克隆完、构建莫名失败、提交之前），其余时间闲置。这是预期的使用模式，而不是缺点。
Token 开销只要连接上，每一轮都会产生，无论是否使用 —— 确实测数字见 Token 开销。
它并不一定在单次一次性问题上的 Token 节省上胜出；它的胜出点在于一致性、安全性，以及触达不提供 shell 的客户端的能力 —— 见 Benefits。
Wait "Benefits" should translate? The anchor must be "#benefits". The link text should be "优势" or "收益". We'll translate to "优势". Let's change.
Actually I wrote "## 此功能解锁的示例问题" etc.
Let's produce final.
Need be careful that "Token overhead is payed every turn" – "token overhead" is 开销. "on each turn the moment it's connected" = "一连接，每一轮都会产生开销". Good.
I'll produce final message with all.
But we must ensure all text within inline code remains in original case. We'll keep.
Let's write in final.
Need "GXP1" etc line as plain text.
Let's produce.* Token 开销在连接后的每一轮都会立即支付，无论是否实际使用 —— 真实的测量数字见 Token 开销。
对于单个一次性问题，它并不一定在 Token 开销上稳定占优；它的优势在于一致性、安全性，以及能够覆盖没有 shell 的客户端 —— 见 优势。
如果某个智能体已经对你有完整控制权、且很少发生环境漂移的仓库拥有完整 shell 访问权限，那你在那里可能完全不需要 DevTwin。
DevTwin 最能在这些场景中体现价值：共享/新手引导仓库、受信任程度较低或没有 shell 的智能体环境，以及“到底该检查什么”本身就很难的多生态 monorepo。
假设你问一个智能体“为什么 npm test 失败了？”，而真正原因是 Node 版本不匹配，加 Postgres 没在运行。
不使用 DevTwin（智能体使用原生 Bash）—— 它必须一条命令一条命令地猜测正确的操作顺序：
cat package.json # spot "engines": {"node": ">=20"}
node --version # v16.20.0 -- mismatch found
grep -i "pg\|postgres" package.json # spot the Postgres dependency
cat .env # risk: may print a real secret into context
lsof -i :5432 # nothing listening
docker ps # check if it's in a container instead六次往返，一条需要智能体自行规划的调查路径，第 4 步中有机密信息泄漏到对话中的真实风险，以及大约 400-800 Token 的命令与输出文本（具体数值取决于文件大小和正在运行的 Docker 容器数量）。
使用 DevTwin，只需要一次调用：
dev_health(){
"status": "error",
"summary": "2 issues found: runtime drift, service down",
"issues": [
"Node 16.20.0 installed, project requires >=20 (from package.json engines)",
"Postgres required (found in docker-compose.yml) but not running on 5432"
],
"recommendations": [
"nvm install 20 && nvm use 20",
"docker compose up -d postgres"
]
}同样的结论，回复约 150 Token—— 再加上那一轮本来就已经固定支付的 1,400 Token schema 开销（见 Token 开销）。一次调用替代六次，完全不会有泄漏机密的可能性，而且每次执行的都是一模一样的预置检查，而不是那种每次会话都不同的即兴调查。
“检查我的开发环境。”
“为什么我的 Kotlin 项目构建失败？”
“我的 Node 版本对这个仓库来说正确吗？”
“为什么我的应用连接不上 Postgres？”
“我的环境与这个仓库的预期有偏差吗？”
“我提交前应该运行什么？”
“我刚克隆了这个仓库——我要怎么才能把它运行起来？”
每个受支持生态一行：你实际会问的问题、DevTwin 为回答它而检查的内容，以及它针对 dev_check 识别的测试/构建命令。
生态 | 示例问题 | 检查的内容 | 识别的命令 |
Python | “我的 Python 版本对这个仓库来说正确吗？” | 用 |
|
Node.js | “为什么 | 用 |
|
JVM（Java + Kotlin + Android） | “为什么我的 Android 应用在新克隆后无法构建？” | 检查 |
|
Go | “我的 Go 版本对这个仓库来说正确吗？” | 用 |
|
Rust | “为什么 | 用 |
|
.NET | “为什么 | 检查 |
|
Swift（iOS/macOS） | “为什么我的 iOS 构建会失败？” | 用 |
|
Ruby | “为什么 | 用 |
|
PHP | “为什么我的 PHP 应用无法启动？” | 用 |
|
通用（fallback） | “这个仓库不属于上面的任何语言——你能告诉我什么？” | 检查 |
|
一个 MCP 服务器，多个生态适配器——而不是每种语言一个单独的服务。
MCP server -> core (workspace/detector/health/drift/diagnostics) ->
adapters (python/node/jvm/go/rust/dotnet/swift/ruby/php/generic) ->
system inspection (os/process/ports/env/fs/docker) ->
service detection (postgres/redis/generic)完整细节见 docs/architecture.md。如何新增一个语言适配器：docs/adapters.md。
生态 | 识别依据 | 运行时检查 | 包管理器 |
Python |
|
| uv、pip、poetry、pipenv |
Node.js |
|
| npm、pnpm、yarn、bun |
JVM（Java + Kotlin） |
|
| Gradle（wrapper 感知）、Maven（wrapper 感知） |
Go |
|
| Go modules |
Rust |
|
| cargo |
.NET |
|
| NuGet |
Swift（iOS/macOS） |
|
| Swift 包管理器、CocoaPods |
Ruby |
|
| Bundler |
PHP |
|
| Composer |
通用（fallback） |
| — | make/task/just/docker |
任何不能匹配特定适配器的项目仍然可以通用适配器获得有用的输出——DevTwin 绝不会对未被识别的项目什么都不返回。
uv pip install devtwin-mcp
# or
pip install devtwin-mcp要基于此仓库的克隆进行本地开发，请参见 docs/development.md。
确切的配置语法因客户端而异——请查阅你所用客户端的文档。一般来说，DevTwin 作为一个 stdio MCP 服务器调用，调用方式如下：
{
"mcpServers": {
"devtwin": {
"command": "devtwin"
}
}
}如果是从克隆中（未安装包）进行本地开发：
{
"mcpServers": {
"devtwin": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/devtwin-mcp", "devtwin"]
}
}
}用 MCP Inspector 验证工具是否可以发现：
npx @modelcontextprotocol/inspector uv run devtwinDevTwin 是一个单一的可执行文件——任何数量的项目都可以指向同一个安装地，不需要针对每个项目重新安装。有两种作用域：
作用域 | 加载范围 | 何时使用 |
项目（推荐默认） | 仅该仓库内 | 默认选择——为什么见 Token 开销 |
用户 作用域 | 每个项目、每个会话 | 当你在大部分仓库中都需要 DevTwin 时 |
项目作用域——在项目根目录放置 .mcp.json：
{
"mcpServers": {
"devtwin": {
"command": "/absolute/path/to/devtwin-mcp/.venv/bin/devtwin"
}
}
}或使用 Claude Code CLI：
claude mcp add devtwin /absolute/path/to/devtwin-mcp/.venv/bin/devtwin --scope project用户作用域：
claude mcp add devtwin /absolute/path/to/devtwin-mcp/.venv/bin/devtwin --scope user添加后，重启客户端（或重新连接 MCP 服务器），然后直接正常提问即可——见 此功能解锁的示例问题。
**Monorepo 提示：**在一个混合平台的仓库中（如 Android + iOS + 后端），把问题指向特定的子文件夹，而不是仓库根目录——例如“检查 android/ 应用的健康状态”。在一个混合仓库根目录运行 dev_detect 会输出它找到的每一个生态，这对一次性盘点很有用，但对一个针对性检查来说就太吵了。
所有工具都返回 {status, summary, data, issues, recommendations}。status 是 ok、warning、error、unknown 之一。
| 工具 | 分类 | 说明 |
| --------------------- | ------------- | ------------------------------------------------------------------------------------ |
| `dev_detect` | 只读 | 基于文件的快速项目/生态系统检测，并附带证据。 |
| `dev_health` | 只读 | 综合运行时、依赖、服务与 Git 状态的完整 0-100 健康评分。 |
| `dev_drift` | 只读 | 比较所需的运行时/工具版本与实际已安装的版本。 |
| `dev_explain_failure` | 只读 | 将给定的错误消息诊断为一组按优先级排列、有证据支持的根本原因。 |
| `dev_project_info` | 只读 | 详细的项目检查：运行时、构建工具、命令、操作系统、Git。 |
| `dev_dependencies` | 只读 | 各生态系统的依赖/lockfile 状态。 |
| `dev_services` | 只读 | 所需的本地服务（Postgres、Redis、compose services）及其运行状态。 |
| `dev_check` | 安全执行 | 在超时限制下运行已识别的测试/lint 命令（如 `pytest`、`./gradlew test`）。 |
| `dev_prepare` | 仅生成计划 | 为刚克隆的仓库生成准备计划；自身绝不执行该计划。 |
| `dev_precommit` | 只读 | 提交就绪摘要：Git 状态、健康信息以及疑似机密的已暂存文件。 |
## 安全模型
* **不执行任意命令。** 不存在 `execute_shell` 工具。
`dev_check` 只运行 DevTwin 自己从项目文件中识别出的命令，这些命令经过 allowlist
检查，并以 `shell=False` 和超时机制运行。
* **绝不执行破坏性操作。** DevTwin 从不运行 `git reset --hard`、
`rm -rf`、`kill -9`、`docker compose down`，也不删除 lockfile 或修改 `.env`。
* **`dev_prepare` 只做规划。** 它会对每个建议步骤进行分类
（`read_only`/`safe`/`requires_approval`/`dangerous`），并且绝不自行执行任何操作。
完整详情见 [`docs/security.md`](docs/security.md)。
## 隐私模型
* 仅当环境变量名称看起来像敏感信息（`PASSWORD`、`TOKEN`、`SECRET`、`API_KEY`、`PRIVATE_KEY`、`ACCESS_KEY`、`AUTH`、`CREDENTIAL`……）时，才检查其**是否存在**——绝不返回其值。
* `.env` 文件只扫描变量的 *名称*。
* `dev_precommit` 会标记名称看似敏感的已暂存文件，但不会读取或报告其内容。
## 本地优先架构
* 没有服务器组件、没有账户，也不存在除它所检查的本地命令（`git`、`docker`、语言工具链）之外的任何自身网络调用。
* 它报告的一切均来自运行它所在机器上已有的文件和进程。
## 开发
GXP12
完整的工作流程见 [`docs/development.md`](docs/development.md)。
## 贡献
参见 [`CONTRIBUTING.md`](CONTRIBUTING.md)。添加一种新的语言生态系统是最常见的贡献方式——模板参见 [`docs/adapters.md`](docs/adapters.md)，或以已合并的真实示例 [`src/devtwin/adapters/swift.py`](src/devtwin/adapters/swift.py)、[`ruby.py`](src/devtwin/adapters/ruby.py) 和 [`php.py`](src/devtwin/adapters/php.py) 为蓝本来构建你自己的适配器。
## 路线图
* 更多生态系统适配器：Elixir、Dart、Scala、C/C++（CMake/Bazel/Buck）、Nix（如何添加见 `docs/adapters.md`）
* 更多服务检测器（MySQL/MariaDB、MongoDB、Kafka、RabbitMQ）
* 与 CI 配置（如 GitHub Actions runtime matrices）进行更丰富的漂移对比
* 在单个会话内跨工具调用缓存开销较大的检查项时，提供可选的本地缓存
## 许可证
Apache-2.0 —— 参见 [`LICENSE`](LICENSE)。Run recognized project checks (tests/lint) detected from project files,
e.g. pytest, ./gradlew test, npm test, cargo test. Only commands
DevTwin itself recognized are ever executed (never an arbitrary string),
each with a timeout. Pass run to restrict to a subset of the recognized
commands (call dev_project_info first to see what's available).
| Name | Required | Description | Default |
|---|---|---|---|
| run | No | ||
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that only DevTwin-recognized commands are ever executed (never arbitrary strings) and that each command has a timeout, which is valuable safety information. It doesn't mention side effects or output specifics, but the core behavioral constraints are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then safety details, then usage guidance. Every sentence earns its place with specific, actionable information and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are documented separately. The description covers safety, usage flow, and available options, but omits any mention of the workspace parameter and doesn't clarify behavior when no checks are recognized. Given the tool's complexity and the availability of an output schema, these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains the 'run' parameter (restrict to a subset of recognized commands) and directs the agent to dev_project_info to see valid values. However, the 'workspace' parameter is completely unaddressed; an agent might not know it represents the working directory. The explanation for 'run' is helpful but not comprehensive for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs recognized project checks (tests/lint) with concrete examples (pytest, gradlew test, npm test, cargo test). It uses a specific verb 'Run' and a well-defined resource, distinguishing it from sibling tools like dev_detect or dev_health which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises calling dev_project_info first to discover available commands and to use the 'run' parameter to restrict execution to a subset. This provides clear context and a specific prerequisite, though it doesn't explicitly contrast with alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dependency state per detected ecosystem: package manager, lockfile presence/consistency signals, dependency counts, and whether packages appear installed locally (e.g. node_modules/, .venv/).
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It describes output content but does not state whether the tool is read-only, scans the filesystem, requires network access, or has side effects. It also omits any performance or error implications. The behavior is not transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the key concept and lists specifics efficiently. While it could be slightly more structured with an explicit verb, it is economical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one undocumented parameter and no annotations. Even though an output schema exists (which may clarify return values), the description omits critical context about the workspace parameter and how ecosystems are detected. It is incomplete for an agent to call correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'workspace' has zero schema description coverage (0%), and the description does not mention it at all. The agent has no idea what workspace does, how it affects the results, or what values are acceptable. The description fails to compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports dependency state per ecosystem, listing specific data points (package manager, lockfile, counts, local install). It is specific about content, though it lacks an explicit action verb like 'get' or 'list'. It does not differentiate from siblings, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like dev_detect, dev_health, or dev_drift. No mention of context that would trigger this tool, no exclusions, and no mention of alternatives. The agent must infer when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect what kind of project lives at workspace: languages, ecosystems,
and the evidence (files) behind each detection. Fast, file-based only.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds two meaningful traits: 'file-based only' (implying read-only, local operation) and 'fast' (performance). However, it lacks depth—no mention of error handling, what happens if the workspace is invalid, or whether it caches results. It provides some transparency but not comprehensive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It leads with the core purpose, then appends the behavioral notes. Every word contributes; nothing is redundant or unnecessary. This is an exemplary concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema exists), the description covers the essentials: what it does, the parameter, and some behavior. However, it omits usage context—when to choose this over siblings—and lacks deeper behavioral details like edge cases or side effects. It is adequate for basic use but not fully complete without referencing alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains 'workspace' as the location where the project lives, which clarifies the parameter's role. The default '.' is also consistent. While it doesn't detail accepted path formats, for a single optional parameter this is sufficient and adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'detect' and the resource 'project at workspace', and specifies the outputs: languages, ecosystems, and evidence files. It distinguishes itself from a tautology and conveys a specific capability, though it does not explicitly contrast with sibling tools like dev_project_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The phrase 'Fast, file-based only' hints at scope and performance but does not state when a developer should pick this over siblings such as dev_health or dev_project_info, nor does it mention exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It uses non-mutating verbs ('compare', 'reports') which strongly imply a read-only operation, but it does not explicitly state that it does not modify anything or disclose any side effects, permissions, or limitations. The lack of explicit transparency is a moderate gap for a tool that could potentially access local installations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the core comparison action and then specifies the output format. Every word contributes to understanding the tool's function and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single optional parameter, an output schema, and no annotations, the description provides sufficient context to call it correctly. The purpose and result are clear, and the workspace parameter is implied. It could mention edge cases (e.g., invalid workspace) or what happens when no drift is found, but the output schema likely covers the return structure, so the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'workspace' with a default but no description, and schema description coverage is 0%. The description's mention of 'project files' and 'installed locally' gives context that the workspace parameter specifies which directory to inspect, but it does not explicitly describe the parameter's purpose or acceptable values. It adds some meaning but does not fully compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb (compare), resource (expected vs installed project state), and outcome (reports mismatch as structured drift items). It distinguishes itself from sibling tools by specifying the exact comparison of required runtime/tool versions against local installations, which is not ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case (detecting version drift) but does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or conditions. With many siblings, explicit routing would be helpful, but the core purpose is clear enough that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| command | No | ||
| workspace | Yes | ||
| error_message | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'cross-references project type, runtimes, services, ports, and dependencies' and that it 'ranks likely root causes with evidence'. It also clarifies a behavioral trait: 'never asserting certainty beyond the evidence'. This is transparent about the tool's inductive reasoning and its limitation. The description doesn't mention any destructive actions or side effects, but the name suggests (and the description confirms) it is purely diagnostic. Given the lack of annotations, this is a good level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the main purpose and inputs at the front. It packs a lot of information: the input, the cross-referencing behavior, the output (ranked root causes with evidence), and a critical limitation ('never asserting certainty beyond the evidence'). No fluff, every clause earns its place. The structure is clear: first sentence states the action, second expands on internals and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (diagnostic reasoning tool with multiple input parameters and an output schema), the description covers the core functionality well: it explains what the tool does, what it takes, and what it returns. The output schema exists (though not provided in the input schema here, but the signal says 'Has output schema: true'), so the description doesn't need to detail return values. The main missing piece is explicit mention of the 'workspace' parameter – it is implied by 'project type, runtimes, services' but not directly stated as an input. Other than that, the description is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the parameters. The description mentions 'error/output text' and 'command that produced it' and 'workspace' implicitly. It doesn't explicitly name the workspace parameter, but it says 'cross-references project type, runtimes, services, ports, and dependencies' which implies the workspace is the project context. The description adds value by explaining what the parameters are used for (error_message as the primary input, command as optional context). It does not cover all parameter semantics in detail (e.g., format of workspace), but given the high-level nature, it provides enough meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: diagnose a development failure. It specifies the inputs (error/output text, optionally the command) and the output (ranks likely root causes with evidence). The verb 'diagnose' and the resource 'development failure' are specific, and the description distinguishes it from siblings by focusing on failure analysis rather than detection, health, or project info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: when you have error/output text and optionally the command that produced it. It implies that the tool is for diagnosing failures, not for general health checks or detection. While it doesn't explicitly name alternatives, the context signals and sibling names (dev_check, dev_detect) suggest it's for failure analysis, and the description gives a clear condition for invocation. This is a strong usage guideline, essentially 'use this when you have error text and want root cause analysis'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does convey that the tool is non-mutating (a 'check' that produces a score and issues), implying a read-only operation, but it stops short of explicitly stating side-effect-free behavior, performance implications, or what happens if the workspace doesn't exist. It also doesn't describe the structure of the 'issues and recommendations' it returns, though an output schema is present. The overall intent is clear, but some behavioral specifics are 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, densely informative sentence that front-loads the core purpose ('Full environment health check') and immediately enumerates the covered areas. Every element earns its place—no filler, no repetition. It is compact while conveying both scope and outcome, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a good high-level overview of functionality and output, and the presence of an output schema relieves it of fully explaining return values. However, it omits any guidance on the `workspace` parameter (its purpose and valid values), which is necessary for correct invocation. It also doesn't mention prerequisites (e.g., must be inside a project) or how to interpret the health score beyond 'issues and recommendations'. For a tool that combines many aspects, these gaps are moderate, leaving the description slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, `workspace` (default '.'), and the schema provides zero description coverage (0%). The tool description never mentions this parameter or explains its meaning (e.g., directory path, project root). Although the name is somewhat self-explanatory and there is a sensible default, the description fails to compensate for the missing schema documentation. The agent is left to infer what value to pass, which is a notable gap for a parameter that affects the scope of the health check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('health check') applied to the environment, lists the concrete aspects it combines (project detection, runtime versions, dependency state, services, ports, Git state), and defines the single 0-100 health_score output. It unambiguously distinguishes itself from narrower sibling tools like dev_dependencies or dev_services by being a 'Full environment health check' that aggregates many dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a comprehensive, one-stop check by explicitly enumerating what it covers, which signals when to use it (when a holistic overview is needed). However, it does not explicitly exclude alternatives (e.g., 'use dev_dependencies for dependency-only checks') nor call out situations where a narrower tool is preferred. This is clear context without exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It explicitly states 'Read-only' and 'Never commits, stages, or modifies anything.' This fully discloses the tool's side-effect-free nature, which is the critical behavioral trait. The description goes beyond a simple purpose statement by reassuring the agent of safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the core purpose front-loaded. The first sentence states what it does, the second reinforces the read-only guarantee. No fluff or redundant details; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, scope, and behavioral safeguards. An output schema exists, so return values are presumed documented elsewhere. The only notable gap is the undocumented 'workspace' parameter, which prevents the description from being fully complete for a drop-in usage understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter ('workspace') with 0% description coverage, and the tool description does not mention it at all. This leaves the agent to infer that 'workspace' refers to a path, but there is no explicit guidance, default behavior, or allowed values. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Read-only commit-readiness summary' and details the specific checks (Git status, project health, secrets). It also explicitly states what it never does, which distinguishes it from mutation tools. The purpose is unambiguous and distinct from sibling dev_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description: it is for checking commit readiness, presumably before committing. However, the description does not explicitly state when to use this tool versus its siblings (e.g., dev_health, dev_check) or provide any exclusion criteria. It offers clear context but no explicit comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It explicitly states 'This tool NEVER executes anything -- it only plans' — a critical guarantee that prevents an agent from expecting side effects. It also discloses the output behavior (classifying each step's blast radius). This is thorough and transparent for a planning tool with zero side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and then the key behavioral caveat. Every clause adds value: scope, typical use case, and the critical non-execution guarantee. No filler, no redundancy. It is concise and well-structured for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity (one optional param, no execution), the description is almost complete. It covers what the plan includes (steps, blast radius classification) and what it never does. The output schema exists, so return details are covered implicitly. Minor omission: it doesn't specify the format or granularity of the plan, but that is not essential for invocation. Overall, an agent can confidently call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single optional 'workspace' parameter with 0% description coverage, so the description must compensate. It does not directly explain 'workspace', but the purpose 'for a repository' implies the workspace is the repository path. Since the parameter is simple, optional, and has a sensible default, the lack of explicit parameter explanation is a minor gap. This warrants a middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Produce a preparation plan'), a specific resource ('repository'), and the scope ('align runtimes, start services, install deps, run build/test'). It also explicitly disclaims execution, which clearly distinguishes it from sibling tools like dev_check or dev_detect that likely run commands. The purpose is unambiguous and differentiated without needing to name siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage — 'for a (likely newly-cloned) repository' — and clarifies it is for planning, not execution. However, it does not explicitly state when to prefer this over sibling tools (e.g., dev_check for actual validation, dev_services for service management). The context is present but no alternatives or exclusions are given, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the scope of inspection and a performance characteristic (slower), but does not explicitly state read-only behavior, required permissions, or potential side effects. The word 'inspection' implies non-mutating, yet it is not stated outright.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the purpose and a detailed list, followed by a comparative note. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are already covered. The description specifies a rich set of inspected aspects and includes a performance caveat. It does not explain the workspace parameter's role, but that is captured under parameter semantics. Overall, the description gives sufficient context for an agent to decide to call the tool and understand its high-level behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'workspace' parameter at all. The parameter name is self-explanatory, but the description adds no contextual meaning about what value to provide (e.g., project root path) or how it affects the inspection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'inspection' with a specific resource ('project') and enumerates concrete content: ecosystems, runtimes, build tools, commands, environment variables, OS info, Git state. It also differentiates from dev_detect by noting 'broader and slower', making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with dev_detect ('Broader and slower than dev_detect'), giving a comparative usage cue. It implies choosing this tool when depth is needed over speed, though it does not list explicit when-not-to-use conditions or mention any other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs local detection, checks whether services are running/listening, and provides evidence, which implies a read-only, non-destructive operation. However, it does not state that it has no side effects, does not start services, or what happens if services are missing. It is more transparent than a bare 'detect services' but still lacks explicit safety details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose ('Local service detection') and packs in the three key outputs (needed services, running status, evidence). There is no filler or irrelevant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists (though not detailed here), so return values need not be explained. The description covers the essential scope: which services, whether running, and evidence. It omits explicit clarification of the 'workspace' parameter and any limitations, but for a detection tool with a single optional parameter, it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'workspace' with a default of '.' and zero description coverage (0%). The description does not mention the parameter at all, leaving the agent to infer that it refers to the project directory. The name and default give some hint, but the description adds no semantic value beyond the schema, and the schema itself provides no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('detection') and resource ('services'): it identifies which services (Postgres, Redis, compose-defined) the project needs, whether they are running, and provides evidence. This clearly distinguishes it from sibling tools like dev_dependencies (dependencies) or dev_health (health status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention any conditions, alternatives, or exclusions. An agent would have to infer from the title and sibling names that this is about service detection, but there is no explicit routing or 'use this when' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dev_checkdev_dependenciesdev_detectdev_driftdev_explain_failuredev_healthdev_precommitdev_preparedev_project_infodev_servicesScored 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.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Scores your code across 12 areas, with findings, fix prompts, and re-assessment in your AI agent
Lets coding agents check their own code for leaked secrets, risky dependencies and AI-code mistakes
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
