A
licenseB
qualityD
maintenanceTypeScript-based MCP server designed to enhance code editing experiences by providing features such as hover information, code completion, and diagnostics.
3
28 npm
26
MIT
Delve MCP
by dwisiswant0
delve-mcp
用于 Delve 调试器集成的 MCP 服务器
这是一个基于 TypeScript 的 MCP 服务器，为 Go 程序的 Delve 调试器提供了完整的接口。它通过 MCP 工具实现了所有主要的 Delve 命令和功能。
特征
资源
通过
delve://URI 列出并访问调试会话每个会话都有关于其类型、目标和端口的元数据
会话详细信息和状态的 JSON 表示
工具
使用以下工具调试、跟踪和分析 Go 程序：
调试命令（
debug、attach、exec、test）核心转储分析
程序跟踪
使用
rr重放调试DAP 服务器支持
带条件的断点管理
执行控制（
continue、step、next）变量检验与评估
后端选择（
native、lldb、rr）日志配置
会话管理
环境设置
服务器要求：
使用 Delve 安装 Go（
go install github.com/go-delve/delve/cmd/dlv@latest）对于重放功能：Mozilla
rr（ https://github.com/mozilla/rr ）Node.js 和 npm
Related MCP server: MCP-Typescribe
安装
要安装 Delve MCP 服务器：
npm install @dwisiswant0/delve-mcp发展
安装依赖项：
npm install构建服务器：
npm run build对于使用自动重建的开发：
npm run watch配置
要与 Claude Desktop 一起使用，请添加服务器配置：
在 Linux 上：
~/.config/Claude/claude_desktop_config.json。在 MacOS 上：
~/Library/Application Support/Claude/claude_desktop_config.json。在 Windows 上：
%APPDATA%/Claude/claude_desktop_config.json。
{
"mcpServers": {
"delve-mcp": {
"command": "/path/to/delve-mcp/build/index.js"
}
}
}可用工具
调试命令
debug- 调试当前目录或指定包中的 Go 包attach-通过 PID 附加到正在运行的进程**
exec**执行并调试预编译的二进制文件test-在当前包或指定包中调试测试core- 检查与可执行文件相关的核心转储文件dap- 启动调试适配器协议（DAP）服务器replay- 重放 rr 跟踪记录trace- 使用函数匹配来跟踪程序执行
控制命令
setBreakpoint- 设置带有可选条件的断点**
removeBreakpoint**删除现有断点**
continue**继续程序执行**
next**跳到下一行**
step**单步执行函数调用**
stepout**跳出当前函数variables- 列出当前范围内的局部变量evaluate-评估当前范围内的表达式
配置命令
version- 获取 Delve 版本信息setBackend- 配置调试后端（native、lldb、rr）configureLogging- 配置调试日志组件
使用示例
启动调试会话
// Debug current package
{ name: "debug" }
// Debug with specific package and build flags
{
name: "debug",
arguments: {
package: "./cmd/myapp",
buildFlags: "-tags=integration"
}
}管理断点
// Set a breakpoint
{
name: "setBreakpoint",
arguments: {
sessionId: "abc123",
file: "main.go",
line: 42,
condition: "count > 5"
}
}检查状态
// List variables
{
name: "variables",
arguments: {
sessionId: "abc123"
}
}
// Evaluate expression
{
name: "evaluate",
arguments: {
sessionId: "abc123",
expr: "myVar.Field"
}
}执照
麻省理工学院。
Available Tools
19 toolsattachC
Attach to a running process
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | Process ID to attach to |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description is too brief. It does not disclose effects like suspending the process, debugging capabilities, or permission requirements. For a tool that modifies process state, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (6 words), which is concise but at the expense of needed detail. It is front-loaded but overall feels incomplete for a debugger attach action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 required param, no output schema, no annotations), the description is insufficient. Missing info on side effects, detaching, or interaction with other debug tools.
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?
The input schema fully describes the single parameter 'pid' with a clear description. The tool description adds no extra meaning, so baseline 3 is appropriate.
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?
The description clearly states the verb 'attach' and the resource 'running process', indicating it connects a debugger to an existing process. However, it does not differentiate from sibling debugging tools like 'debug' or 'exec'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites or scenarios (e.g., should the process be stopped? what if already attached?).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
configureLoggingC
Configure debug logging
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | Components to enable logging for | |
| destination | No | Log destination (file path or file descriptor) |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the configuration is additive or overriding, persists across sessions, or requires any special conditions. This is a significant gap for a configuration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but this verges on underspecification. It does not front-load key details or structure information for quick consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no output schema, flat parameters), the description could still be more complete. It fails to explain the effect of configuring logging, such as whether existing logs are affected or if there are side effects.
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?
Schema coverage is 100% with descriptions for both parameters ('components' and 'destination'). The tool description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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?
The description 'Configure debug logging' clearly states the action and resource, distinguishing this from sibling tools like attach, continue, and evaluate which are debugger commands. However, it lacks specificity about what logging configuration entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or contextual constraints mentioned. The agent must infer usage solely from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
continueC
Continue program execution
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the debug session |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'continue program execution' without clarifying side effects, safety, or what happens after continuation (e.g., pause on next breakpoint).
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?
The description is very concise at three words, but it sacrifices informativeness. It earns its place as a minimal viable description, but could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter, but the description lacks context about when to use it, what happens after invocation, and there is no output schema. Adequate but incomplete for an agent to use correctly.
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?
Schema coverage is 100%, so baseline is 3. The description adds no meaning beyond the schema for 'sessionId', which is already described as 'ID of the debug session'.
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?
The description clearly states the verb 'continue' and resource 'program execution', which distinguishes it from sibling tools like 'step' and 'next'. However, it could be more specific, e.g., 'after a breakpoint is hit'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'step', 'next', or 'evaluate'. The agent is left to infer usage context without explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coreB
Examine a core dump
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| executable | Yes | Path to the executable that produced the core dump | |
| corePath | Yes | Path to the core dump file |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only says 'Examine', suggesting a read operation, but does not disclose whether it modifies state, requires permissions, or produces output beyond what is expected.
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?
Extremely concise (4 words), but it accurately conveys the tool's purpose without wasted words. Could benefit from a bit more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters and no output schema, the description is minimally adequate but lacks detail on what 'examine' entails (e.g., output format, temporary effects).
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?
Both parameters already have descriptions in the input schema (100% coverage). The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Examine a core dump' clearly states the tool's action (examine) and resource (core dump), distinguishing it from siblings like 'debug' or 'evaluate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., 'debug'). The purpose implies usage for core dump analysis, but without disclaimers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dapC
Start a DAP (Debug Adapter Protocol) server
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| clientAddr | No | Optional address where DAP client is waiting for connection |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether the server listens or requires a client connection. The optional parameter hints at client interaction, but this is not explicitly stated.
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?
The description is a single, front-loaded sentence that communicates the core purpose. It is concise but could benefit from additional detail without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context about the server's behavior, return value, and lifecycle. For a server-starting tool with no output schema, more detail is needed.
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?
Schema coverage is 100%, with a clear description for 'clientAddr'. The tool description adds no extra parameter meaning, so baseline 3 is appropriate.
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?
The description clearly states the tool starts a DAP server, using a specific verb and resource. It distinguishes from siblings like 'debug' and 'attach' by focusing on server initialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to start a DAP server versus using related tools like 'attach' or 'debug'. The description lacks context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
debugC
Start debugging a Go package
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| package | No | Package to debug (defaults to current directory) | |
| buildFlags | No | Build flags to pass to the compiler |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the action. With no annotations, the agent learns nothing about side effects (e.g., starting a debug session, compiling), required permissions, or error states. This is insufficient for a tool that likely has significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words, effectively conveying the core purpose. However, it may be too brief to provide necessary context, balancing conciseness against completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a debugging tool with no output schema and no annotations, the description is incomplete. It fails to explain what happens after execution (e.g., session start), return values, or state changes, leaving significant gaps for the agent.
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?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond what the schema provides, so baseline score is appropriate.
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?
The description 'Start debugging a Go package' clearly identifies the action (start) and resource (debugging a Go package). It is distinguishable from sibling tools like 'continue' or 'step' which are subsequent actions. However, it does not differentiate from 'attach' which also initiates debugging but for an external process, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'attach' or 'test'. There is no mention of prerequisites or contexts where it should not be used, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evaluateC
Evaluate an expression in current scope
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the debug session | |
| expr | Yes | Expression to evaluate |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is minimal. It implies evaluation but does not disclose side effects, scope context, or whether it is read-only. The agent is left to infer behavior from the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted information. It front-loads the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the simplicity of the tool, the description could be more complete by indicating what the tool returns (e.g., evaluated value, errors) and any constraints (e.g., expression language). It omits critical contextual information for an AI agent to use it effectively.
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?
Schema description coverage is 100%, so the schema already documents both parameters. The description does not add any additional meaning beyond what is in the schema, meeting the baseline expectation.
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?
The description clearly states the verb 'evaluate' and the resource 'expression in current scope', distinguishing it from sibling tools like 'exec' or 'variables' by focusing on expression evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'exec' or 'variables'. The description does not provide context for its typical use case within a debug session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execC
Debug a precompiled binary
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| binary | Yes | Path to the binary | |
| args | No | Arguments to pass to the binary |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'debug', which implies execution under a debugger, but does not specify side effects, state changes, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise (one sentence), but this brevity sacrifices informativeness. It is not overly verbose, but could include more structured detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a debugging tool with 2 parameters and no output schema, the description lacks critical context such as return values, termination behavior, and interaction with the debugger state.
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?
Schema has 100% parameter description coverage, so the description adds no extra meaning. Baseline score of 3 is appropriate.
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?
Description clearly states the tool debugs a precompiled binary, which is specific and action-oriented. However, it does not differentiate from sibling tool 'debug', which likely performs a similar role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use 'exec' versus alternative tools like 'debug' or 'attach'. The description offers no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nextC
Step over to next line
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the debug session |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must disclose behavioral traits. It only states 'Step over to next line' without describing side effects, state changes, or requirements (e.g., session must be paused). This is insufficient for an agent to understand the tool's behavior beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) but lacks structure or front-loading of key information. While it is short, it could benefit from a brief elaboration on context or prerequisites without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, common debugger action), the description is minimal. It does not explain return values, preconditions (e.g., paused session), or how it interacts with breakpoints. Siblings like 'continue' and 'step' provide contrast but the description alone is insufficient for complete understanding.
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?
Schema coverage is 100% and the 'sessionId' parameter description is clear. The tool description does not add any additional meaning beyond the schema, meeting the baseline expectation.
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?
The description 'Step over to next line' clearly indicates the tool performs a debugger step-over operation. It distinguishes from siblings like 'step' (step into) and 'stepout' (step out) by specifying 'over', though it could be more explicit about the action's effect on function calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'step' or 'continue'. The description does not mention prerequisites (e.g., paused debug session) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
removeBreakpointC
Remove a breakpoint
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the debug session | |
| breakpointId | Yes | ID of the breakpoint to remove |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description lacks disclosure of side effects, required session state, or potential errors. Simply stating the action does not provide behavioral context beyond the basic operation.
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?
The description is a single concise sentence that directly states the purpose without fluff. It is front-loaded and efficient, though it could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple remove operation, the description lacks information on return values, error conditions, or post-removal behavior. With no output schema, some indication of what the agent can expect after invocation is missing.
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?
Input schema has 100% coverage with clear parameter descriptions. The description adds no additional meaning beyond what the schema already provides, earning a baseline score of 3.
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?
Description clearly states the action 'Remove a breakpoint' with a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'setBreakpoint', though the inverse relationship is implicitly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to remove vs. disable a breakpoint. The description assumes the agent knows the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replayC
Replay an rr trace
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tracePath | Yes | Path to the rr trace directory | |
| onProcess | No | Optional PID to pass to rr |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as side effects, permissions, or whether the replay is destructive. The description carries full burden but fails to provide meaningful transparency.
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?
The description is a single clear sentence with no waste. It is appropriately short for a two-parameter tool, though it could optionally be a bit more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and full schema coverage, the description provides minimal but sufficient context. However, it lacks detail on expected behavior or output, which would be helpful for an action like replaying a trace.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.
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?
The description 'Replay an rr trace' clearly states a specific verb and resource, distinguishing it from sibling debugging commands like 'continue' or 'step'. However, it does not explicitly differentiate itself or add context beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description is purely definitional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
setBackendC
Set the backend for debugging
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| backend | Yes | Backend to use (default, native, lldb, or rr) |
TDQS
C2.7/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as persistence, side effects, or permissions. The description is too brief to inform the agent beyond the basic action.
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?
The description is a single concise sentence that contains the essential purpose. It is front-loaded and wastes no words, though it could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the bare minimum but lacks explanation of what 'backend' means or the effect of the change, making it incomplete.
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?
Schema coverage is 100%, and the parameter already has an enum and description. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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?
The description clearly states the verb 'set' and the resource 'backend', with context 'for debugging'. It distinguishes from sibling tools that involve other debugging operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance ('for debugging') but does not specify when to use this tool versus alternatives like debug or dap. No when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
setBreakpointB
Set a breakpoint in the debugged program
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the debug session | |
| file | Yes | File path where to set the breakpoint | |
| line | Yes | Line number for the breakpoint | |
| condition | No | Optional condition for the breakpoint |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as whether execution halts, if multiple breakpoints are allowed, or error handling. The description carries the full burden but is too minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the purpose, no wasted words. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a debugging tool with no output schema and complex behavior (e.g., interaction with other debug commands), the description is too sparse. It lacks context on what happens after setting a breakpoint or return values.
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?
Input schema has 100% coverage with descriptions for all 4 parameters. The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set a breakpoint in the debugged program' with a specific verb and resource. It distinguishes from sibling tools like removeBreakpoint or continue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to set vs. remove breakpoints, or step). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stepC
Step into function call
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the debug session |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It only states the action but omits details like whether it requires a session, what happens if no function call exists, or any side effects. The behavior is implied but not explicitly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, but this under-specification sacrifices informativeness. It does not earn its place as a helpful guide; rather, it relies on the agent inferring context from the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (single required parameter, no output schema, no annotations), the description is barely adequate. It fails to explain the step-into behavior, the impact on debug state, or any return value, leaving the agent with insufficient context for correct invocation.
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?
The input schema covers 100% of parameters (sessionId is documented). The description adds no additional parameter-specific meaning beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Step into function call' uses a specific verb ('step into') and resource ('function call'), clearly distinguishing it from sibling tools like 'next' (step over) and 'stepout' (step out), which is essential for an AI agent selecting the correct debugging action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives such as 'next' or 'continue'. It does not mention scenarios like stepping into a function while debugging or any prerequisites (e.g., active session, breakpoint hit).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stepoutB
Step out of current function
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the debug session |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like side effects, prerequisites (e.g., active debug session), or error conditions. The minimal description fails to compensate for the lack of annotations.
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?
The description is a single concise sentence, front-loading the purpose. However, it could include more structure or guidelines without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is inadequate. It does not explain what stepping out entails, prerequisites, or expected behavior, making it incomplete for an AI agent.
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?
The input schema has 100% coverage, with the 'sessionId' parameter already described as 'ID of the debug session'. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Step out of current function', which is a specific verb and resource. It distinguishes from sibling tools like 'step', 'next', and 'continue'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'step' or 'next'. No context for usage is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
testC
Debug tests in a package
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| package | No | Package to test (defaults to current directory) | |
| testFlags | No | Flags to pass to go test |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Debug tests' without explaining what that entails (e.g., does it run tests with breakpoints, output progress, or handle failures).
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?
The description is extremely concise (3 words), which is efficient, though it sacrifices explanatory detail. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return values or side effects. It does not. For a tool with two optional parameters, the description is too minimal to fully inform usage.
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?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond what the schema provides, meeting the baseline for schema-rich tools.
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?
The description clearly states the tool debugs tests in a package, which is a specific action on a specific resource. It distinguishes from the sibling 'debug' tool by specifying tests, but could be more explicit about how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'debug' or 'exec'. The description does not mention any prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
traceC
Trace program execution
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| regexp | Yes | Regular expression to match functions to trace | |
| pkg | No | Package to trace (defaults to .) | |
| ebpf | No | Use eBPF for tracing (experimental) | |
| stack | No | Show stack trace with given depth | |
| pid | No | Pid to attach to |
TDQS
C2.1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a minimalist description, there is zero disclosure of behavioral traits such as side effects, permissions required, performance impact, or the experimental nature of eBPF. The agent has no awareness of safety or resource implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, the description is under-specified for a tool with 5 parameters and multiple options. The single sentence does not front-load key information, and the conciseness comes at the cost of utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is completely inadequate. It fails to explain return values, parameter interactions, or use cases, leaving the agent with insufficient context.
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?
The input schema covers all 5 parameters with descriptions (100% coverage), so the description adds no extra value. Baseline 3 is appropriate as the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Trace program execution' conveys a generic action and resource but lacks specificity about what aspects of execution are traced (e.g., function calls, system calls), making it vague rather than precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'attach', 'debug', or 'evaluate'. The description does not mention prerequisites, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
variablesC
List local variables in current scope
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the debug session |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, preconditions (e.g., active debug session), or behavior on invalid session. Carries full burden but provides minimal info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short (5 words), no waste, but at the expense of missing essential context. Not excessively long, but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description should hint at return format (e.g., variable names/values). For a debug tool with one param, more context is needed for complete understanding.
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?
Schema coverage is 100% (sessionId described), so baseline is 3. Description adds no extra meaning beyond schema.
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?
The description clearly states the action (List) and resource (local variables) with scope context (current scope). It distinguishes from siblings like evaluate or debug, but could specify what constitutes current scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like evaluate or trace. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
versionB
Get Delve version information
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It only states what it does, not what is returned or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is minimally adequate but could mention version format.
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?
No parameters, schema coverage 100%. Description adds no extra value but is not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get Delve version information', using specific verb and resource. It distinguishes from sibling tools like attach, debug, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or alternatives. While the tool is simple, even basic context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
19 tool updates
- First observed
attach - First observed
configureLogging - First observed
continue - First observed
core - First observed
dap - First observed
debug - First observed
evaluate - First observed
exec - First observed
next - First observed
removeBreakpoint - First observed
replay - First observed
setBackend - First observed
setBreakpoint - First observed
step - First observed
stepout - First observed
test - First observed
trace - First observed
variables - First observed
version
TDQS
B3/5.0
Scored across 19 tools
Disambiguation4/5
Tools have distinct purposes with clear descriptions. Some potential confusion exists between 'debug', 'exec', 'test', and 'attach' as different ways to start debugging, but descriptions differentiate them. Overall, agents can reliably distinguish tools.
Naming Consistency5/5
All tools use a consistent single-word lowercase naming pattern (e.g., 'continue', 'step', 'setBreakpoint'). While not verb_noun, the pattern is uniform and predictable, making it easy for agents to understand.
Tool Count3/5
19 tools is on the higher end for a debugger MCP server. While each tool serves a legitimate debugging function, the count exceeds the typical 3-15 range, making it somewhat heavy but still manageable.
Completeness3/5
Covers core debugging workflows like starting, stepping, breakpoints, and evaluation. However, missing common operations like listing breakpoints, viewing stack traces, and goroutine inspection indicate notable gaps for comprehensive debugging.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
A MCP server built for developers enabling Git based project management with project and personal…
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables LLMs to understand and work with TypeScript APIs they haven't been trained on by providing structured access to TypeScript type definitions and documentation.14 npm46MIT
- AlicenseNot gradedqualityCmaintenanceA TypeScript-based MCP server that enables code search, file reading, and project management via the GitLab API.7 npm1ISC
- AlicenseNot gradedqualityCmaintenanceA standalone MCP server that provides TypeScript type inference and hover information using tsgo, enabling AI agents to get type details, diagnostics, references, and more without needing an editor.11 npm1MIT