gdb-mcp는 고권한 모델 컨텍스트 프로토콜(MCP) 서버로, Codex가 GDB/MI 인터페이스와 pygdbmi 라이브러리를 통해 GDB 디버거를 제어할 수 있게 합니다.
이 프로젝트가 주로 지원하는 배포 아키텍처:
Windows 上的 Codex
-> Windows 上的 gdb-mcp MCP 服务端
-> Windows 本地 GDB
-> target remote / target extended-remote
-> linux 虚拟机中的 gdbserver
-> 虚拟机内的目标程序본 서버는 로컬 권한 디버깅, CTF Pwn 문제 풀이, 크래시 분석, Core Dump 분석, 취약점 익스플로잇 재현, ELF 파일 분석 시나리오를 위해 설계되었습니다. 고위험 GDB 명령어는 영구적으로 비활성화되지 않으며, 최초 실행 시 경고가 반환됩니다. 호출자가 재시도 시 confirm=true를 전달하면 실행할 수 있습니다.
gdb_session: 로컬 GDB 세션 시작, 중지, 재시작 및 상태 조회
gdb_load: 로컬 바이너리 파일, Core 파일, 심볼 파일 및 시작 인수 로드
gdb_exec: 범용 GDB CLI 명령어 실행 진입점
gdb_mi: 네이티브 GDB/MI 명령어 실행 진입점
gdb_remote: 가상 머신 측 gdbserver 구성 및 연결
gdb_context: 레지스터, 스택, 디스어셈블리, 호출 스택, 중단점, 메모리 맵, 공유 라이브러리 확인
gdb_memory: 메모리 읽기, 쓰기, 검색 및 덤프
gdb_register: 레지스터 읽기/쓰기
gdb_breakpoint: 일반 중단점, 하드웨어 중단점, 임시 중단점, 감시점
gdb_run_control: 실행, 계속, 단계별 진입(step into), 단계별 건너뛰기(step over), 명령어 단위 단계별 실행, 함수 완료까지 실행, 중단, 프로그램 종료, 재시작
gdb_analyze: 크래시 및 취약점 익스플로잇 가능성 분석
gdb_elf: 보안 검사(checksec), ELF 헤더, 섹션, 세그먼트, 심볼, GOT/PLT, 재배치, 문자열
gdb_pwndbg: pwndbg/gef/peda 명령어 실행 호환
모든 도구는 통일된 JSON 구조를 반환합니다:
{
"ok": true,
"tool": "gdb_exec",
"action": "exec",
"risk_level": "low",
"need_confirm": false,
"executed_with_risk": false,
"warning": null,
"data": {},
"stdout": "",
"stderr": "",
"raw": {},
"error": null
}Related MCP server: pwndbg-lldb-mcp
git clone https://github.com/traver88/gdb-mcp.git본 프로젝트가 지원하는 실행 환경은 Python 3.12입니다.
python --version
python -m venv .venv
.\.venv\Scripts\activate
pip install -e .MSYS2 설치
MSYS2 MinGW64 터미널 열기
실행:
pacman -Syu # 之后重启 MSYS2
pacman -S gdb gdb-multiarchC:\msys64\mingw64\bin을 Windows PATH에 추가
검증:
gdb --version
gdb-multiarch --versiongdb-mcp项目目录下：
.\.venv\Scripts\activate
python tests\smoke_test.py성공 시 출력:
smoke test passedsmoke_test.py 테스트 내용:
Windows 로컬 GDB 시작
examples/hello.c로 컴파일된 테스트 프로그램 로드
main에 중단점 설정
프로그램 실행
레지스터 읽기
스택 읽기
디스어셈블리
GDB 종료
sudo apt update
sudo apt install -y gdbserver gdb gcc make binutils filecd xxx/xxx/
gdbserver 0.0.0.0:1234 ./pwnpowershell:
ping 192.168.56.101
Test-NetConnection 192.168.56.101 -Port 1234[mcp_servers.gdb-mcp]
command = "D:\\gdb-mcp\\.venv\\Scripts\\python.exe"
args = ["D:\\gdb-mcp\\server.py"]command: MCP 서버를 시작하는 Python 프로그램 경로
args: server.py 서버 진입점 경로
요청 예시:
请使用 gdb-mcp：
- 启动 GDB
- 加载本地符号文件 E:/ctf/pwn/pwn
- 连接 192.168.56.101:1234 的 gdbserver
- 在 main 下断点
- continue
- 显示寄存器、栈、RIP 附近反汇编、backtrace동일한 MCP 호출:
gdb_session(action="start")
gdb_remote(
action="connect",
host="192.168.56.101",
port=1234,
mode="remote",
local_binary="E:/ctf/pwn/pwn",
confirm=true
)
gdb_breakpoint(action="add", location="main")
gdb_run_control(action="continue")
gdb_register(action="read_all")
gdb_memory(action="read", address="$rsp", size=160)
gdb_exec(command="x/20i $rip")
gdb_exec(command="bt")
gdb_context(depth=20)동일한 GDB 명령어:
file "E:/ctf/pwn/pwn"
target remote 192.168.56.101:1234
b main
c
info registers
x/20gx $rsp
x/20i $rip
bt가상 머신:
gdbserver --multi 0.0.0.0:1234MCP 호출:
gdb_remote(
action="connect",
host="192.168.56.101",
port=1234,
mode="extended-remote",
local_binary="E:/ctf/pwn/pwn",
remote_binary="/xxx/pwn",
confirm=true
)
gdb_breakpoint(action="add", location="main")
gdb_run_control(action="run")
gdb_context(depth=20)내부 GDB 명령어:
file "E:/ctf/pwn/pwn"
set remote exec-file /xxx/pwn
target extended-remote 192.168.56.101:1234Windows에서 가상 머신으로 ping이 안 됨: 가상 머신 IP와 네트워크 어댑터 모드 확인
1234 포트 연결 불가: gdbserver가 실행 중인지 확인
gdbserver가 로컬에서만 수신 대기 중: gdbserver 0.0.0.0:1234 ./pwn 사용
Windows 방화벽 차단: GDB 또는 해당 포트 허용
가상 머신 NAT 모드에서 접근 불가: 호스트 전용(Host-only) / 브리지 어댑터 사용 또는 포트 포워딩 구성
local_binary와 remote_binary 혼동: 전자는 Windows 경로, 후자는 Linux 경로
Windows GDB가 Linux ELF를 해석하지 못함: 해당 아키텍처용 다중 아키텍처 GDB 사용
원격 모드에서 info proc mappings 사용 불가: gdb_context가 크래시 대신 사용 불가로 표시함
원격 libc 심볼 누락: gdb_remote(action="set_sysroot", ...) 또는 set_solib_search_path 사용
확인이 필요한 고위험 명령어 예시:
target remote HOST:PORT
target extended-remote HOST:PORT
disconnect
detach
set remote exec-file PATH
set sysroot PATH
set solib-search-path PATH
shell ...
source ...
python ...
dump memory ...
restore ...
maintenance ...
최초 호출:
gdb_exec(command="target remote 192.168.56.101:1234")서버가 need_confirm=true를 반환하면, 확인을 포함하여 재시도:
gdb_exec(command="target remote 192.168.56.101:1234", confirm=true)실행 후 반환값에 executed_with_risk=true가 포함됩니다.
Analyze crash state, registers, stack, exploitability, calling convention, or memory faults.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | crash |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only lists what it analyzes but fails to disclose side effects, prerequisites (e.g., a running process), or whether analysis is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. While it could be restructured to include more detail, it is not verbose or wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-mode analysis), the description is incomplete. It lacks details on input semantics, output schema hints, and usage context relative to siblings. The presence of an output schema is not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'mode' with 0% description coverage. The tool description does not explain what values mode accepts, leaving the agent to guess. The listed resources might correspond to mode values, but this is implicit and insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Analyze' and lists multiple analysis resources (crash state, registers, stack, etc.), making the purpose clear. However, it does not distinguish from sibling tools like gdb_register or gdb_memory, which focus on individual aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that the mode parameter selects the analysis type or that siblings exist for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add, delete, enable, disable, list, condition, or clear breakpoints/watchpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| location | No | ||
| number | No | ||
| condition | No | ||
| temporary | No | ||
| hardware | No | ||
| watch_expr | No | ||
| confirm | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only lists actions without explaining side effects, required states (e.g., running GDB), or failure modes. For example, it doesn't clarify what 'list' returns or whether 'delete' requires a number.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence but is a flat list of verbs. It lacks structure to separate different action groups or link to parameters, making it less effective despite brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and supports multiple actions, but the description offers no details on how parameters relate to actions, return values (though output schema exists), or usage examples. This is 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 8 parameters (action, location, number, condition, temporary, hardware, watch_expr, confirm). It provides no semantic help beyond the terms in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists multiple specific actions (add, delete, enable, disable, list, condition, clear) targeting breakpoints/watchpoints, making the tool's purpose clear. However, it does not differentiate these sub-operations or distinguish the tool from siblings like gdb_run_control or gdb_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., gdb_run_control for execution, gdb_memory for memory). There are no exclusions or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return registers, current instruction, disassembly, stack, backtrace, breakpoints, and mappings.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states 'Return' indicating a read operation, but does not disclose any side effects, required program state (e.g., must be paused), performance implications, or whether the function alters state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Return') and lists the returned items efficiently. However, it omits parameter details, keeping it concise but slightly incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context indicates 'has output schema: true'), the description does not need to detail return values but should explain the depth parameter. It lists the returned items but misses parameter semantics, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'depth' with a default of 20, but the description fails to explain its meaning or effect. With schema description coverage at 0%, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb 'Return' and lists multiple specific resources (registers, instruction, disassembly, etc.). This distinguishes it from siblings like gdb_register or gdb_memory which return single aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for getting a comprehensive debug context snapshot but provides no explicit guidance on when to choose this over sibling tools like gdb_register or gdb_memory. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect ELF metadata using pyelftools when available and readelf/objdump as fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the fallback mechanism (pyelftools first, then readelf/objdump), which is behavioral information beyond the absent annotations. This helps the agent understand potential differences in output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with purpose, but omits essential parameter information. It is concise but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical details about acceptable actions and path usage, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter details in the description, the agent cannot infer valid values for 'action' or the role of 'path'. The description adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool inspects ELF metadata and specifies the backends (pyelftools, readelf/objdump), giving a clear verb and resource. However, it does not differentiate from siblings like gdb_analyze explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The agent receives no context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an arbitrary GDB CLI command with warning-and-confirm risk handling.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| confirm | No | ||
| timeout | No | ||
| parse | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks annotations. Only mentions 'warning-and-confirm' but not specifics like potential consequences, required permissions, or error handling for dangerous commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise but too sparse; could include structured parameter mention without being lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain parameter behavior, risk scenarios, or return format. Inadequate for a complex arbitrary execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
0% schema description coverage. The description adds no meaning to parameters (command, confirm, timeout, parse). 'Warning-and-confirm' vaguely hints at confirm but is not explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'execute' and resource 'arbitrary GDB CLI command'. Distinguishes from specialized siblings like gdb_breakpoint or gdb_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternative GDB tools. The risk handling hint is insufficient for decision making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a binary, core file, symbol file, and optional program arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| binary | No | ||
| core | No | ||
| symbol_file | No | ||
| args | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It fails to mention whether the operation is destructive, requires a running session, or produces any side effects, leaving the agent without critical safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise. However, it may be too brief, omitting necessary details for a tool with multiple parameters. While front-loaded with the verb and resources, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (loading multiple artifacts) and lack of annotations, the description is severely incomplete. It does not mention return values (despite an existing output schema), prerequisites, or the effect on the debugging session. The agent lacks essential context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It merely lists parameter names ('binary', 'core', 'symbol_file', 'args') without explaining their roles or expected formats, adding minimal value beyond the schema's title fields. For example, it doesn't clarify that 'binary' is the path to the executable or that 'args' are command-line arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Load' and lists the specific resources: binary, core file, symbol file, and optional program arguments. This clearly distinguishes it from sibling tools like gdb_memory or gdb_register which focus on different aspects of GDB debugging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as gdb_remote for remote debugging or gdb_exec for execution. It lacks any context about prerequisites or scenarios where loading is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read, write, search, or dump inferior memory.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| address | No | ||
| size | No | ||
| data_hex | No | ||
| pattern | No | ||
| output_file | No | ||
| confirm | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose behavioral traits such as side effects of write operations, safety considerations, or that the 'confirm' parameter may require user acknowledgment. The description lists actions but provides no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, but it may be too terse given the complexity of the tool. However, it earns points for being front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 7 parameters and a rich set of actions with no parameter documentation. The description is insufficient for an agent to correctly invoke all variations of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no detail about parameters. For example, the required 'action' parameter has no listed valid values, and parameters like 'address' and 'data_hex' remain unexplained, forcing the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states four distinct actions (read, write, search, dump) on a specific resource (inferior memory), making the tool's purpose very clear and differentiating it from sibling tools like gdb_register or gdb_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or context for selecting specific actions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a raw GDB/MI command with warning-and-confirm risk handling.
| Name | Required | Description | Default |
|---|---|---|---|
| mi_command | Yes | ||
| confirm | No | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'with warning-and-confirm risk handling' without explaining what that entails (e.g., destructive behavior, suppression of warnings). Leaves ambiguity about the tool's operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices completeness. It earns its place but lacks critical detail, so it's not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and an incomplete description, the tool is poorly documented. Does not mention output schema, return values, error handling, or how timeout/confirm function. Insufficient for safe or effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description does not explain any parameter's meaning or usage. The parameters (mi_command, confirm, timeout) are left completely undefined beyond their types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it executes raw GDB/MI commands, distinguishing it from sibling tools that are more specific (e.g., gdb_breakpoint, gdb_exec). The verb 'execute' and resource 'GDB/MI command' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Mentions 'warning-and-confirm risk handling' but does not explain when to set confirm=true or prefer other tools for common operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute pwndbg/gef/peda helper commands if they appear available.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| confirm | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavioral traits. It only mentions executing commands 'if they appear available', with no details on side effects, errors, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure and essential detail. Under-specification does not earn 'conciseness' credit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With many sibling GDB tools and an output schema, the description fails to explain when pwndbg commands are appropriate or what the output contains. Incomplete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description provides no information about the 'command' or 'confirm' parameters. Agent has no guidance on valid commands or usage of confirm flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Execute' and resource 'pwndbg/gef/peda helper commands', which clearly identifies the tool's domain. However, 'if they appear available' adds uncertainty, and it doesn't differentiate from sibling tools like gdb_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not specify prerequisites or context for executing helper commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read all registers, read one register, or write one register.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| name | No | ||
| value | No | ||
| confirm | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only lists the three operations but does not mention side effects of writing, required permissions, or whether reading returns a specific format. The 'confirm' parameter hints at a confirmation step but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence front-loading the operations. However, it is overly brief at the expense of necessary details, making it less structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no schema descriptions, three distinct actions), the description is severely incomplete. It does not describe how to specify which register, how to confirm writes, or what the output schema returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but fails. It does not map the three operations to the parameters (action, name, value, confirm). The 'action' parameter's allowed values are not listed, and 'name', 'value', 'confirm' are left undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states three specific operations: reading all registers, reading one register, or writing one register. It uses a specific verb (read/write) and resource (register), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like gdb_memory or gdb_breakpoint. The description does not mention prerequisites or context for each mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure or connect Windows GDB to a VM-side gdbserver.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| host | No | ||
| port | No | ||
| mode | No | remote | |
| local_binary | No | ||
| remote_binary | No | ||
| sysroot | No | ||
| solib_search_path | No | ||
| debug_file_directory | No | ||
| architecture | No | ||
| confirm | No | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It does not mention side effects (e.g., whether a connection is persistent), error handling, authentication needs, or rate limits. For a tool that connects to a remote server, these details are critical. The description is too sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise with no wasted words. It gets straight to the point. However, conciseness is not an excuse for missing content, but in terms of structure, it is optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters and an output schema, the description is severely underdeveloped. It does not explain return values, connection lifecycle, or how parameters interact. For a complex debugging tool, this is inadequate. No information about the output is provided, despite an output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameter meanings. It does not. The description only says 'configure or connect,' leaving 12 parameters (action, host, port, mode, etc.) completely unexplained. No value is added beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configure or connect Windows GDB to a VM-side gdbserver.' It uses a specific verb ('configure or connect') and resource ('Windows GDB to a VM-side gdbserver'), making the core function understandable. However, it does not distinguish this tool from sibling tools like gdb_session or gdb_mi, which might handle similar connection or debugging tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Among the sibling tools (e.g., gdb_session, gdb_mi, gdb_breakpoint), there is no indication of when gdb_remote is appropriate, such as for initial setup versus ongoing debugging. No context about prerequisites or workflow is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run, continue, step, next, instruction-step, finish, until, interrupt, kill, or restart.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| count | No | ||
| args | No | ||
| stdin | No | ||
| timeout | No | ||
| confirm | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behaviors. It lists actions but does not describe side effects (e.g., 'kill' terminates the program, 'interrupt' pauses). No mention of safety, state changes, or required privileges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line listing actions, which is concise but lacks structure. It could be organized into categories or bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, 6 parameters, no annotations), the description is insufficient. It does not explain return values (though output schema exists), prerequisites, or typical use cases. An agent would need significant additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 6 parameters with 0% description coverage, and the description adds no parameter explanations. For example, 'action' is required but not elaborated; 'count', 'args', 'stdin', 'timeout', 'confirm' have defaults but no meaning. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists multiple actions (Run, continue, step, next, etc.) that clearly indicate it controls GDB execution flow. It distinguishes from sibling tools like breakpoints or memory inspection. However, it does not explicitly state the resource (e.g., 'debugged program'), making it slightly less specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or which action to choose for a given scenario. The description lacks usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start, stop, restart, or inspect the current GDB session.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| gdb_path | No | ||
| workdir | No | ||
| extra_args | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only lists actions without explaining their effects (e.g., whether starting clears state, what 'inspect' returns, or if restart requires an active session).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single list of actions. It is front-loaded but lacks any structure like parameter mapping or usage hints; still, it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool manages a GDB session with 4 parameters, an output schema, and no annotations, the description is incomplete. It omits action enum values, default workflow, and parameter roles, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no parameter details. It does not explain the 'action' values, the purpose of 'gdb_path', 'workdir', or 'extra_args', leaving the schema to carry full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool manages a GDB session with specific verbs: start, stop, restart, inspect. This clearly identifies the resource and actions, and distinguishes from sibling tools like gdb_breakpoint or gdb_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like gdb_run_control or gdb_load. There are no prerequisites, side effects, or conditional usage tips.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0gdb_analyzegdb_breakpointgdb_contextgdb_elfgdb_execgdb_loadgdb_memorygdb_migdb_pwndbggdb_registergdb_remotegdb_run_controlgdb_sessionScored across 13 tools
Tools mostly cover distinct GDB aspects (breakpoints, memory, registers, execution control, session), with minor overlap between 'gdb_context' and 'gdb_register' for register info, and 'gdb_exec' vs 'gdb_mi' for command execution.
All tools start with 'gdb_', but naming patterns vary: some are verbs (analyze, exec), some nouns (breakpoint, context), and one is verb_noun (run_control). No consistent verb_noun pattern.
13 tools is well-scoped for a GDB debugger server, covering essential operations without being overwhelming.
Covers most key GDB features (session, loading, breakpoints, execution, memory, registers, analysis, context, remote, plugins), though source-level debugging or variable inspection are missing but can be handled via gdb_exec.
Live browser debugging for AI assistants — DOM, console, network via MCP.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
