Skip to main content
Glama

InitDebuggee

Start a new debuggee in x64dbg/x32dbg by detecting architecture, launching the matching debugger, verifying bridge state, and opening the executable with retries.

Instructions

Preferred first call when the target executable path is known.

Reliably start a new debuggee with retries and state verification. This tool detects the target architecture, resolves X64DBG_ROOT, starts the matching x32dbg/x64dbg instance, waits for its authenticated bridge, and opens the target. Do not preflight BridgeHello, probe port 8888, or search debugger installation paths manually before calling InitDebuggee.

Args: exe_path: Absolute path to the executable. timeout_ms: Maximum total time to spend retrying. retries: Maximum number of init attempts. stop_first: When true, stop the current debug session before init. use_scyllahide: off (default), auto (same as off), or force (explicit injection). scyllahide_profile: Optional explicit ScyllaHide profile override. arguments: Argument vector excluding argv[0]. Mutually exclusive with command_line. command_line: Explicit Windows command-line tail. working_directory: Current directory for the new process. environment: Per-launch environment overrides. The current bridge reports this unsupported and the call fails explicitly instead of ignoring it. inherit_environment: Whether the target should inherit the debugger environment. stdin: Typed stdin object (inherit/null/file/bytes/pipe). stdout: Typed stdout object (inherit/null/file/pipe). stderr: Typed stderr object (inherit/null/file/pipe). All streams must be explicit together, or all omitted for console inheritance. child_policy: none, attach-first, attach-all, or break-on-create. capture_limit_bytes: Bounded pipe retention/queue capacity in bytes.

Input Schema

NameRequiredDescriptionDefault
stdinNo
stderrNo
stdoutNo
retriesNo
exe_pathYes
argumentsNo
stop_firstNo
timeout_msNo
environmentNo
child_policyNonone
command_lineNo
use_scyllahideNooff
working_directoryNo
scyllahide_profileNo
capture_limit_bytesNo
inherit_environmentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.9

TDQS

A4.7/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, but the description adds rich context: retries, state verification, architecture detection, authenticated bridge wait, and the important note that `environment` currently fails explicitly rather than silently. Doesn't cover stop_first semantics or what state gets left after partial failure.

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?

Front-loads the preferred-call guidance and the high-level behavior before the argparse-style parameter list. A bit long, but for a 16-param tool every line earns its place.

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

Completeness5/5

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

For a 16-param, side-effecting, open-world tool with no output schema and 0% schema description coverage, the description supplies the behavioral context, prerequisites, exclusions, and per-param semantics an agent needs to invoke it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and delivers: documents mutual exclusivity of arguments/command_line, the use_scyllahide off/auto/force semantics, child_policy enum values, stream must-be-all-or-nothing rule, and the unsupported environment behavior. This substantially compensates for the empty 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?

States a specific verb+resource ('start a new debuggee') and clearly distinguishes itself from siblings like AttachToProcess by targeting the known-executable-path case. Names prerequisites and lifecycle steps (detect arch, resolve X64DBG_ROOT, start matching dbg instance, open target).

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

Usage Guidelines5/5

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

Explicitly says 'Preferred first call when the target executable path is known' and gives when-not-to-preflight guidance ('Do not preflight BridgeHello, probe port 8888, or search debugger installation paths manually'), directly routing away from BridgeHello and EnsureReady.

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