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
20
26
MIT
Delve MCP
by dwisiswant0
Supported platform for running the Delve MCP server with specific configuration paths.
Supported platform for running the Delve MCP server with specific configuration paths.
Provides integration with Mozilla's rr tool for replay debugging of Go programs, allowing historical execution tracing and analysis.
Required runtime environment for the server, enabling the execution of the TypeScript-based MCP implementation.
Used for package management and distribution of the delve-mcp server.
Implements a TypeScript-based MCP server that interfaces with the Delve debugger for Go programs.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Delve MCPdebug myapp and set a breakpoint at main.go line 42"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
delve-mcp
MCP server for Delve debugger integration
This is a TypeScript-based MCP server that provides a complete interface to the Delve debugger for Go programs. It implements all major Delve commands and capabilities through MCP tools.
Features
Resources
List and access debug sessions via
delve://URIsEach session has metadata about its type, target, and port
JSON representation for session details and state
Tools
Debug, trace, and analyze Go programs with:
Debug commands (
debug,attach,exec,test)Core dump analysis
Program tracing
Replay debugging with
rrDAP server support
Breakpoint management with conditions
Execution control (
continue,step,next)Variable inspection and evaluation
Backend selection (
native,lldb,rr)Logging configuration
Session management
Environment Setup
The server requires:
Go installed with Delve (
go install github.com/go-delve/delve/cmd/dlv@latest)For replay functionality: Mozilla
rr(https://github.com/mozilla/rr)Node.js and npm
Related MCP server: MCP-Typescribe
Installation
To install Delve MCP server:
npm install @dwisiswant0/delve-mcpDevelopment
Install dependencies:
npm installBuild the server:
npm run buildFor development with auto-rebuild:
npm run watchConfiguration
To use with Claude Desktop, add the server config:
On Linux:
~/.config/Claude/claude_desktop_config.json.On MacOS:
~/Library/Application Support/Claude/claude_desktop_config.json.On Windows:
%APPDATA%/Claude/claude_desktop_config.json.
{
"mcpServers": {
"delve-mcp": {
"command": "/path/to/delve-mcp/build/index.js"
}
}
}Available Tools
Debug Commands
debug- Debug a Go package in current directory or specified packageattach- Attach to a running process by PIDexec- Execute and debug a precompiled binarytest- Debug tests in current package or specified packagecore- Examine a core dump file with associated executabledap- Start a Debug Adapter Protocol (DAP) serverreplay- Replay an rr trace recordingtrace- Trace program execution with function matching
Control Commands
setBreakpoint- Set a breakpoint with optional conditionremoveBreakpoint- Remove an existing breakpointcontinue- Continue program executionnext- Step over to next linestep- Step into function callstepout- Step out of current functionvariables- List local variables in current scopeevaluate- Evaluate expression in current scope
Configuration Commands
version- Get Delve version informationsetBackend- Configure debug backend (native,lldb,rr)configureLogging- Configure debug logging components
Usage Examples
Starting a Debug Session
// Debug current package
{ name: "debug" }
// Debug with specific package and build flags
{
name: "debug",
arguments: {
package: "./cmd/myapp",
buildFlags: "-tags=integration"
}
}Managing Breakpoints
// Set a breakpoint
{
name: "setBreakpoint",
arguments: {
sessionId: "abc123",
file: "main.go",
line: 42,
condition: "count > 5"
}
}Inspecting State
// List variables
{
name: "variables",
arguments: {
sessionId: "abc123"
}
}
// Evaluate expression
{
name: "evaluate",
arguments: {
sessionId: "abc123",
expr: "myVar.Field"
}
}License
MIT.
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.
TDQS
B3/5.0
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
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
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.3046MIT
- AlicenseNot gradedqualityCmaintenanceA TypeScript-based MCP server that enables code search, file reading, and project management via the GitLab API.251ISC
- AlicenseNot gradedqualityBmaintenanceA 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.271MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dwisiswant0/delve-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server