Skip to main content
Glama
I-CAN-hack
by I-CAN-hack

rename_batch

Execute multiple symbol renames in Ghidra in a single request, sequentially processing each command with per-item error reporting.

Instructions

Run multiple rename commands against the selected program in one request.

Each command object accepts the same fields as `rename`: `target`,
`new_name`, optional `kind`, optional `function`, optional `split_at`, and
optional per-command `timeout`. Commands are executed sequentially in one
Ghidra snippet. The JSON result contains one entry per attempted command
with `ok: true` and the rename result, or `ok: false` and an error string.

Example command objects:
- `{"target": "function:main", "new_name": "app_main"}`
- `{"target": "arg:#0@main", "new_name": "argc"}`
- `{"target": "local:res@handler", "new_name": "did_index",
   "split_at": "0x90003482"}`

Args:
    commands: Rename command objects to execute sequentially.
    program: Required Ghidra project path or name to target.
    timeout: Default decompiler timeout in seconds for local/argument
        renames. A command may override this with its own `timeout`.
    stop_on_error: Stop after the first command failure when true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
programYes
timeoutNo
commandsYes
stop_on_errorNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden. It discloses sequential execution, per-command result entries with ok/error structure, per-command timeout override, and stop_on_error behavior. It does not explicitly state persistence or side effects of the renames, but the rename semantics are strongly implied by the tool name and examples.

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 well-structured with a front-loaded purpose, an Args section, and concrete examples. Every section earns its place; the examples make the nested command format concrete without adding fluff.

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 no annotations and 0% schema coverage, the description is quite complete: it covers execution order, result format, timeout behavior, and stop_on_error. It relies on the sibling rename tool for nested field semantics and does not describe the success result shape in detail, but an output schema is present, so that detail is not strictly required.

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?

Schema coverage is 0%, so the description must compensate, and it does: it explains `commands`, `program`, `timeout`, and `stop_on_error`, plus the nested fields accepted by each command object. The semantics of `kind`, `function`, and `split_at` are delegated to the sibling `rename` tool rather than explained inline, which is a minor gap.

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 opens with a specific verb and resource: 'Run multiple rename commands against the selected program in one request.' It clearly differentiates from the sibling rename tool by emphasizing batch execution rather than a single rename.

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 makes the batch context explicit: 'Commands are executed sequentially in one Ghidra snippet,' and references the sibling `rename` tool for the command object shape. It does not explicitly state 'use rename for a single command' or list exclusions, so it stops short of a 5.

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