Skip to main content
Glama
Sign In
ih8sn1ff

ih8sn1ff

by ih8w1nd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

debug_dump

Dump module images of a stopped process, using dump offset equal to RVA, for later PE reconstruction and analysis.

Instructions

Dump module images of the stopped process (dump offset == RVA).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>"
    },
    "name": "debug_dump"
  }
}

Input Schema

NameRequiredDescriptionDefault
outdirNodumps
session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

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 the full behavioral burden. It discloses the stopped-process precondition and RVA-offset semantics, but says nothing about the mutation side effect (writing files to disk), where output lands, required permissions, or failure modes on a running session.

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?

A single tight sentence with the resource and the key offset semantic front-loaded. No filler, though it is arguably under-specified rather than optimally concise for the tool's complexity.

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 file-producing debug tool with no annotations, no output schema, and zero parameter documentation, the description leaves too much unstated: output naming/location conventions, session requirements, and interaction with dump_process/run_and_dump. The stopped-process hint is the only completeness aid.

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% across both parameters, so the description must compensate. The parenthetical about RVA relates to dump content semantics, not to either parameter; neither 'outdir' nor the required 'session_id' is explained in the description.

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?

States a specific verb ('Dump') and resource ('module images of the stopped process') with a useful scope qualifier ('dump offset == RVA'). However, it does not distinguish itself from close siblings like dump_process, run_and_dump, or debug_read_memory, so an agent cannot tell them apart from the text alone.

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 phrase 'of the stopped process' implies the precondition that a debug session must be halted before calling, which is real implied guidance. But there is no explicit when-to-use/when-not, and no alternative tool is named despite several overlapping dump-related siblings.

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

Deploy Server

Other Tools