Skip to main content
Glama
sbergeron42

gdb-multiarch-mcp

by sbergeron42

gdb_get_frame_info

Retrieve current stack frame details for debugging Nintendo Switch executables in gdb-multiarch, enabling precise analysis of program execution state.

Instructions

Get information about the current stack frame.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The get_frame_info method in the GDBSession class communicates with GDB using the -stack-info-frame command to retrieve information about the currently selected stack frame.
    def get_frame_info(self) -> dict[str, Any]:
        """
        Get information about the current stack frame.
    
        Returns:
            Dict with current frame information
        """
        result = self.execute_command("-stack-info-frame")
    
        if result["status"] == "error":
            return result
    
        mi_result = self._extract_mi_result(result) or {}
        frame = mi_result.get("frame", {})
    
        return {"status": "success", "frame": frame}
  • The gdb_get_frame_info tool is registered with the MCP server, defining its name and input schema (which is empty in this case).
    Tool(
        name="gdb_get_frame_info",
        description="Get information about the current stack frame.",
        inputSchema=NO_ARGS_SCHEMA,
    ),
  • The server.py file contains the tool handling logic that maps the gdb_get_frame_info command to the session.get_frame_info() method call.
    elif name == "gdb_get_frame_info":
        result = session.get_frame_info()
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to state that this is a read-only operation, does not modify debugger state, or what specific data structure is returned. It omits critical context like whether the tool returns frame level, function name, arguments, or memory addresses.

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 consists of a single, efficient sentence with no redundant words. However, given the lack of output schema and annotations, the extreme brevity leaves significant gaps in agent understanding that slightly more elaboration could address.

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?

While adequate for a zero-parameter tool, the description is incomplete given the absence of an output schema and the presence of numerous sibling inspection tools (gdb_get_registers, gdb_get_backtrace). Without hints about what frame information includes, agents cannot easily determine if this tool meets their specific debugging needs.

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

Parameters4/5

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

The input schema contains zero parameters, establishing a baseline score of 4. The description correctly implies the tool operates on the implicit 'current' frame without requiring explicit parameterization, though it could clarify that the current thread/frame context determines the target.

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 states a clear verb ('Get') and resource ('current stack frame'), identifying the tool's basic function. However, it uses vague language ('information') rather than specifying what frame details are returned (function name, file, line, arguments), and it fails to distinguish from sibling tool gdb_get_backtrace.

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 like gdb_get_backtrace (which gets all frames) or gdb_select_frame (which changes frames). It omits prerequisites such as requiring the target program to be stopped in the debugger.

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/sbergeron42/gdb-multiarch-mcp'

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