Skip to main content
Glama
Sign In
borer

borer

by imjustprism
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

decompile

Read-only

Turn one function at a given address into pseudo-C with local/arg labels, asm markers, and warnings for focused binary analysis.

Instructions

Decompile one function to pseudo-C. Locals are local_N/arg_N (local_N is N hex bytes below the frame base: on x86 one word below the entry sp, so rbp-N where the prologue pushes rbp and sets it there; on arm the entry sp; higher N, lower address; local_mN is N bytes above the frame base); /* asm */ marks unmodeled code. Line 2 says what was checked, // warn: what is wrong. Not for a first look (use function_summary).

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": {
      "address": "<address>"
    },
    "name": "decompile"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoReturn at most this many lines (default 300; more than the text has for all).
detailNo`skeleton` for flow and calls only; `full` or absent for all of it.
filterNoKeep only lines containing this text, case-insensitively.
offsetNoSkip this many lines of the answer.
addressYesFunction entry or any address inside it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only cover read-only/open-world, so the description carries the burden and does so: it decodes the output vocabulary (local_N/arg_N address arithmetic, local_mN above frame base, /* asm */ for unmodeled code, line 2 as the checked-status line, `// warn:` for problems). These are non-obvious output conventions an agent would otherwise misread.

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?

Purpose is front-loaded in the first clause and the rest is a compact legend of output conventions with no filler. However, the frame-base parenthetical is a dense, semicolon-chained run-on ("rbp-N where the prologue pushes rbp and sets it there; on arm the entry sp...") that is harder to parse than necessary.

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?

With no output schema, the description must explain the returned text, and it does: naming scheme, asm markers, the checked-status line and warn markers. The one soft spot is "Line 2 says what was checked," which leaves the agent guessing at the exact semantics of that line.

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

Parameters3/5

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

Schema description coverage is 100% — limit, detail (full/skeleton), filter, offset and address are each documented in the schema. The description adds no parameter-level meaning beyond that (no hint about which detail mode to pick first, no address-form guidance), so the baseline 3 applies.

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?

Opens with a specific verb+resource+scope: "Decompile one function to pseudo-C." The word "one" distinguishes it from the sibling decompile_batch, and the closing clause routes the first-look case to function_summary, so an agent can separate it from both neighbors without opening a schema.

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?

Explicit exclusion plus alternative: "Not for a first look (use function_summary)" tells the agent when NOT to call it and what to call instead. It stops short of stating the positive condition (e.g. "use when you need actual logic after the summary looks suspicious") or distinguishing it from disassemble.

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