Skip to main content
Glama

gdb_command

Execute GDB debugging commands to control program execution, examine memory, analyze stack traces, and perform binary analysis through the GDB MCP Server.

Instructions

Execute any arbitrary GDB command. Use this for all GDB operations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYes
commandYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The gdb_command tool handler function registered with @mcp.tool() decorator. Takes session_id and command as parameters, calls _get_gdb_tools().execute_command() to execute the GDB command.
    @mcp.tool()
    def gdb_command(session_id: str, command: str) -> str:
        """Execute any arbitrary GDB command. Use this for all GDB operations."""
        try:
            return _get_gdb_tools().execute_command(session_id, command)
        except Exception as e:
            return f"Error: {str(e)}"
  • The core implementation of execute_command in GDBTools class. Gets the GDB session, executes the command via gdb.write(), formats the response, and handles BrokenPipeError with session cleanup.
    @handle_gdb_errors("executing command")
    def execute_command(self, session_id: str, command: str) -> str:
        gdb = self.sessionManager.get_session(session_id)
        try:
            response = gdb.write(command)
            return format_gdb_response(response)
        except BrokenPipeError:
            self.sessionManager._cleanup_dead_session(session_id)
            raise BrokenPipeError("GDB session connection lost")
  • Abstract method signature for execute_command in DebuggerTools base class, defining the interface contract with session_id and command parameters returning a string.
    @abstractmethod
    def execute_command(self, session_id: str, command: str) -> str:
        """Execute an arbitrary debugger command."""
        pass
  • Helper function format_gdb_response that formats GDB MI (Machine Interface) responses into human-readable output by parsing console, log, target, and result message types.
    def format_gdb_response(response: List[Dict[str, Any]]) -> str:
        """Format GDB response for better readability."""
        if not response:
            return "No response from GDB"
        
        formatted_lines = []
        for msg in response:
            msg_type = msg.get('type', 'unknown')
            payload = msg.get('payload', '')
            
            if msg_type == 'console':
                formatted_lines.append(f"Console: {payload}")
            elif msg_type == 'log':
                formatted_lines.append(f"Log: {payload}")
            elif msg_type == 'target':
                formatted_lines.append(f"Target: {payload}")
            elif msg_type == 'result':
                message = msg.get('message', '')
                if message == 'done':
                    payload_str = str(payload) if payload else "Command completed successfully"
                    formatted_lines.append(f"Result: {payload_str}")
                else:
                    formatted_lines.append(f"Result ({message}): {payload}")
            else:
                formatted_lines.append(f"{msg_type.title()}: {payload}")
        
        return '\n'.join(formatted_lines) if formatted_lines else "Command executed"
  • DebuggerFactory.create_tools() method that instantiates GDBTools with the appropriate session manager, enabling the tool handler to access GDB functionality.
    @staticmethod
    def create_tools(debugger_type: Optional[str] = None) -> Tuple[DebuggerTools, str]:
        """
        Create debugger tools.
        
        Args:
            debugger_type: 'gdb', 'lldb', or None for auto-detection
            
        Returns:
            Tuple of (tools, actual_debugger_type)
        """
        session_manager, actual_type = DebuggerFactory.create_session_manager(debugger_type)
        
        if actual_type == 'gdb':
            return GDBTools(session_manager), 'gdb'
        elif actual_type == 'lldb':
            return LLDBTools(session_manager), 'lldb'
        
        raise RuntimeError(f"Unknown debugger type: {actual_type}")
Behavior2/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 states the tool executes commands but doesn't disclose behavioral traits like error handling, output format, session requirements, or side effects. The description is minimal and misses critical details for a command execution tool.

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 with two short sentences, front-loaded with the core purpose. However, it's arguably too brief, lacking necessary details for effective use, which slightly reduces its efficiency.

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 (executing arbitrary debugger commands), no annotations, and an output schema (which helps but isn't described), the description is incomplete. It doesn't cover prerequisites, examples, or integration with sibling tools, leaving significant gaps for an AI agent.

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 0%, so the description must compensate. It mentions no parameters explicitly, failing to explain 'session_id' (what session to use) or 'command' (what GDB command to run). The description adds no meaning beyond the bare 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 tool's purpose: 'Execute any arbitrary GDB command' specifies the verb (execute) and resource (GDB commands). It distinguishes from siblings like 'debugger_command' and 'lldb_command' by specifying GDB, but could be more precise about what GDB is (a debugger).

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 implied usage guidance: 'Use this for all GDB operations' suggests it's the primary tool for GDB, but doesn't explicitly state when to use alternatives like 'gdb_start' or 'gdb_terminate'. It lacks clear exclusions or comparisons with sibling tools.

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

Install Server

Other Tools

Latest Blog Posts

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/smadi0x86/MDB-MCP'

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