What can you do with this server?

The GDB Lite MCP server enables LLM agents to programmatically control native GDB debugging sessions. Key capabilities include: * gdb_spawn: Start a new GDB session for a local program, core file, attached PID, or remote target, with support for custom working directories, extra GDB arguments, and environment variables. * gdb_exec: Execute any GDB command(s) in a session, with support for batching multiple commands, configurable timeouts, output size limits, and polling for output. Returns structured metadata: completion_reason, at_prompt, command_pending, needs_interrupt, timed_out, truncated, byte counts, and duration. * gdb_interrupt: Send SIGINT to interrupt a hung GDB session or its debuggee and wait for the GDB prompt to return. * gdb_close: Terminate and clean up a GDB session by session_id. * gdb-lite://debug-guide: Access a built-in debug guide resource. * Full native GDB access: Since commands are passed directly to GDB, agents can use breakpoints, watchpoints, Python snippets, backtrace, core inspection, and more without additional wrappers. * Configuration: Control the GDB executable path, maximum concurrent sessions, and per-session output buffer size via environment variables.

How do I use GDB Lite MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GDB Lite MCP Start a GDB session and examine a crash" 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.

GDB Lite MCP

by Mort2000

Overview Schema Related Servers Score Discussions

Python

Local

GDB Lite MCP

A small TypeScript MCP server for driving GDB sessions from LLM agents.

GDB Lite MCP intentionally exposes only a thin set of primitives around native GDB. Agents can spawn sessions, execute GDB commands, interrupt hung programs, and close sessions while still using normal GDB features such as breakpoints, watchpoints, command lists, Python snippets, core files, attach, and remote targets.

Requirements

Node.js 20 or newer
GDB available on PATH
A native compiler such as gcc if you want to build the repository scenarios

Related MCP server: gdb and rr Debugging

Install

npm install
npm run build

Run the server locally:

npm start

The package also exposes a gdb-lite-mcp binary after it has been built.

The npm package is intentionally limited to the runtime server, debug guide, and debugging Skill. The eval/scenarios/ directory contains repository development assets; clone this repository if you want to run them locally.

MCP Configuration

Point your MCP client at the published package via npx:

{
  "mcpServers": {
    "gdb-lite": {
      "command": "npx",
      "args": ["-y", "gdb-lite-mcp"]
    }
  }
}

For repository-local evaluation, eval/run_eval.py writes a temporary opencode.json that starts the same server from the built dist/index.js.

Runtime environment variables:

GDB_LITE_GDB_PATH: GDB executable path. Defaults to gdb.
GDB_LITE_MAX_SESSIONS: maximum live sessions. Defaults to 8; must be a positive integer.
GDB_LITE_MAX_INTERNAL_BUFFER_CHARS: per-session retained output buffer. Defaults to 4194304; must be a positive integer.
GDB_LITE_AUTO_INIT: set to 0, false, no, or off to disable automatic startup defaults.

Invalid runtime configuration values fail fast when the server starts.

Tools

The server registers these MCP tools:

Tool	Purpose
`gdb_spawn`	Start a GDB session for a local program, core file, attached PID, or remote target.
`gdb_exec`	Send a native GDB command, poll output with an empty command, or list sessions with an empty or unknown `session_id`.
`gdb_interrupt`	Send SIGINT and wait for GDB to return to a prompt.
`gdb_close`	Terminate and remove a GDB session, or return the current session list when `session_id` is unknown.

gdb_exec and gdb_interrupt return structured state such as completion_reason (completed, timeout, or exited), at_prompt, command_pending, needs_interrupt, timed_out, truncated, and byte counts. Use this metadata to avoid stacking commands behind a still-running inferior. Calls on the same session are not queued; concurrent gdb_exec or gdb_interrupt requests are rejected.

The server also exposes a gdb-lite://debug-guide resource backed by GUIDE.md.

Example Workflow

gdb_spawn({
  "prog_path": "bin/program",
  "work_dir": "/absolute/path/to/debug-workspace"
})

gdb_exec({
  "session_id": "...",
  "command": "break main\nrun\nbt\ninfo locals",
  "timeout": 5
})

gdb_close({
  "session_id": "..."
})

Prefer batching related GDB commands in one tool call. For hangs, let the run time out, call gdb_interrupt, then inspect bt, info threads, and relevant locals before continuing.

Debugging Skill

The skills/gdb-debugging directory contains an agent Skill with focused debugging workflows for:

crashes
hangs
memory corruption
recursion issues
wrong results
GDB Python probes

Agents that support repository-local Skills should read skills/gdb-debugging/SKILL.md before using the MCP tools.

Scenarios

The repository eval/scenarios directory contains small native debugging tasks used to evaluate the MCP server and Skill. It is not included in the npm package.

Build all scenario binaries:

python3 eval/scenarios/build_scenarios.py

Each scenario writes local build artifacts under eval/scenarios/<name>/build/, which is ignored by Git.

Evaluation

Repository-local evaluation prompts and config live under eval/. They are not included in the npm package.

npm run build
python3 eval/run_eval.py --scenario hang-tokenizer

Run outputs are written under eval/runs/, which is ignored because it is a local evaluation result artifact.

Development

npm run build
npm test

Generated artifacts such as dist/, node_modules/, scenario build directories, logs, and local evaluation results are ignored by Git.

License

MIT. See LICENSE.

Available Tools

4 tools

gdb_closeClose gdbC

Terminate and remove a gdb session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`closed`	Yes
`existed`	Yes

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description must disclose behavioral traits. It acknowledges destruction ('terminate and remove'), but omits details like side effects on running processes, required auth, or error handling (e.g., closing an already-closed session).

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 too brief; it lacks critical information that would justify its length. While concise, it under-specifies the tool's behavior and parameters.

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?

Despite a simple signature (1 param, no nested objects), the description fails to cover prerequisites (session must exist), return values (though output schema exists), or side effects, leaving the agent under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description must explain the sole parameter ('session_id'). It does not mention what it is, how to obtain it, or its format, providing no value 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 the action ('terminate and remove') and the resource ('a gdb session'). It effectively distinguishes itself from siblings like gdb_spawn (create), gdb_exec (run commands), and gdb_interrupt (halt execution).

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, such as when to close versus interrupt a session, or whether multiple closes are safe.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gdb_execExecute gdb commandB

Send a gdb command and return all output since the previous gdb_exec or gdb_interrupt call. Empty command only polls output.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes
`timeout`	No
`max_output_bytes`	No	Optional maximum returned output size in bytes. Keeps the tail with a truncation marker.
`command`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`output`	Yes
`completion_reason`	Yes
`saw_prompt`	Yes
`timed_out`	Yes
`session_exited`	Yes
`at_prompt`	Yes
`command_pending`	Yes
`needs_interrupt`	Yes
`bytes`	Yes
`duration_ms`	Yes
`truncated`	Yes
`omitted_bytes`	Yes
`internal_buffer_bytes`	Yes

TDQS

B3.2/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 disclose behavioral traits. It mentions that output is returned since the previous call, but does not indicate whether the tool is destructive, blocking, or requires specific permissions. Side effects and concurrency behavior are omitted.

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 short (two sentences) and front-loads the action. It is efficient but could include more detail without bloating.

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 tool with 4 parameters, no annotations, and a critical role in debugging, the description is too minimal. It lacks details on required session context, timeout implications, and output format (though output schema exists). More context is needed for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25% (only max_output_bytes has a description). The description does not add meaning to parameters like session_id, timeout, or command beyond their names. It fails to compensate for the low schema coverage.

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 the tool sends a gdb command and returns output since the last call, with a specific behavior for empty commands. It distinguishes the action and resource (gdb command execution).

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?

The description provides some usage hint (empty command polls output) but does not offer explicit guidance on when to use gdb_exec versus sibling tools like gdb_interrupt or gdb_spawn. No when-not-to-use or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gdb_interruptInterrupt gdbB

Send SIGINT to the gdb session/debuggee, wait for the GDB prompt, and return incremental output.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes
`timeout`	No
`max_output_bytes`	No	Optional maximum returned output size in bytes. Keeps the tail with a truncation marker.

Output Schema

ParametersJSON Schema

Name	Required	Description
`output`	Yes
`completion_reason`	Yes
`saw_prompt`	Yes
`timed_out`	Yes
`session_exited`	Yes
`at_prompt`	Yes
`command_pending`	Yes
`needs_interrupt`	Yes
`bytes`	Yes
`duration_ms`	Yes
`truncated`	Yes
`omitted_bytes`	Yes
`internal_buffer_bytes`	Yes
`interrupted`	Yes

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It describes the core action (send SIGINT, wait for prompt, return output) but omits details like potential side effects on the debuggee, what 'incremental output' means, or error handling. It does not contradict annotations (none provided).

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 sentence of 16 words, front-loading the key action. It is concise but could benefit from slightly more structure (e.g., separating action from output).

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 3 parameters and a likely output schema (not shown), the description covers the main behavior but omits edge cases like session not found or timeout handling. It is adequate for a straightforward interrupt tool but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (33%), and the description adds no parameter-specific information beyond the overall action. The description does not explain session_id, timeout, or max_output_bytes semantics, failing to compensate for the low schema coverage.

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 the tool sends SIGINT to a GDB session and returns output. It uses a specific verb and resource, and it distinguishes itself from sibling tools like gdb_exec (which executes commands) and gdb_spawn (which starts sessions).

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. It does not specify prerequisites, when not to use it, or mention sibling tools like gdb_exec for command execution instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gdb_spawnSpawn gdbA

Start a gdb session and return a session id. Supports local programs, core files, attach, remote targets, and extra native gdb args.

ParametersJSON Schema

Name	Required	Description
`prog_path`	No	Program path. Relative paths are resolved from work_dir.
`work_dir`	Yes	Working directory for gdb and the debuggee.
`environments`	No	Extra environment variables.
`core_path`	No	Optional core file path. Relative paths are resolved from work_dir. Mutually exclusive with attach_pid and remote_target.
`attach_pid`	No	Optional local process id to attach to. Mutually exclusive with core_path and remote_target.
`remote_target`	No	Optional native GDB remote target, for example "localhost:1234". Mutually exclusive with core_path and attach_pid.
`gdb_args`	No	Optional extra native gdb command-line arguments.

Output Schema

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that a session id is returned and lists supported modes, but does not detail side effects, permissions, or error conditions. The description is adequate but could be more transparent.

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 two sentences, front-loaded with the core purpose, and wastes no words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, output schema, nested objects), the description covers the primary modes. It does not emphasize that work_dir is required or clarify dependencies between parameters, but it is largely complete for a spawn tool.

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 baseline is 3. The description adds conceptual grouping of parameters (e.g., core_path, attach_pid, remote_target as exclusive options) but does not add significant meaning beyond the schema's own parameter descriptions.

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 the verb 'Start' and the resource 'gdb session', and specifies that it returns a session id. It lists the supported modes (local programs, core files, attach, remote targets), differentiating it from sibling tools like gdb_close, gdb_exec, and gdb_interrupt.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description enumerates the various use cases (local, core, attach, remote), which implicitly tells the agent when to use this tool. However, it does not explicitly state when not to use it or provide direct alternatives to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jun 10, 2026
- First observedgdb_close
- First observedgdb_exec
- First observedgdb_interrupt
- First observedgdb_spawn

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a distinct role: spawning, executing commands, interrupting, and closing sessions. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a consistent 'gdb_' prefix with a clear verb (spawn, exec, interrupt, close), making the naming pattern predictable and understandable.

Tool Count4/5

With only 4 tools, the set is minimal but covers the core operations for managing a GDB session. It could benefit from additional tools like session listing, but is reasonable for a 'lite' implementation.

Completeness4/5

The tools cover the essential lifecycle of a GDB session: start, execute commands, send interrupts, and close. Minor gaps like session listing are acceptable for a lite MCP.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
llm-orchestration-agent-2
ai.getvda
MCP-Native LLM Orchestration Agent
1

Related MCP Servers

GDB-MCP
Developer Tools Code Execution Command Line
hnmr293
A
license
Not graded
quality
D
maintenance
An MCP server that provides programmatic access to the GNU Debugger (GDB), enabling AI models to interact with GDB through natural language for debugging tasks.
Updated a year ago (2025-08-01 03:08 UTC)
9
Apache 2.0
gdb and rr Debugging
Developer Tools
schuay
A
license
A
quality
C
maintenance
MCP server that exposes GDB debugging as tools. An AI assistant can set breakpoints, run programs, step through code, inspect variables and memory, and examine registers — all via structured tool calls. Reverse debugging with rr is also supported.
Updated a month ago (2026-08-01 13:58 UTC)
34
3
MIT
gdb_mcp
Developer Tools Testing & QA Tools
airfloats
A
license
A
quality
D
maintenance
An MCP server that enables AI assistants to control GDB debugging sessions, including breakpoint management, thread analysis, and variable inspection, using the GDB/MI protocol.
Updated 4 months ago (2026-04-26 00:32 UTC)
22
1
MIT
lldb-mcp-server
Developer Tools Command Line
FYTJ
A
license
Not graded
quality
D
maintenance
An MCP server that exposes LLDB debugging capabilities, enabling AI-assisted interactive debugging of C/C++ applications through 40 specialized tools.
Updated 7 months ago (2026-01-31 09:21 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Mort2000/gdb-lite-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server