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

create_function

Create a function at a target address, automatically disassembling if needed and respecting existing function boundaries. Optionally assign a custom name.

Instructions

Create a function at target, optionally with a user-defined name.

If a function already starts at `target`, it is returned and renamed when a
`name` is provided. If `target` falls inside an existing function, no new
function is created and the containing function is returned.

When `target` is not yet an instruction, it is first disassembled in the
language's correct default ISA mode (PowerPC VLE, ARM Thumb-default, or
microMIPS), clearing any conflicting data, so entries are not mis-decoded
into broken boundaries.

Args:
    target: Address, exact label, or function name where the function
        should start.
    program: Required Ghidra project path or name to target.
    name: Optional user-defined function name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
targetYes
programYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.5/5.0
Behavior5/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. It transparently explains the return behavior (existing function returned, renamed if name given), the no-op when target is inside an existing function, and the disassembly side effect of clearing conflicting data. This is thorough and prevents surprising outcomes.

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 is detailed and well-structured, with a clear main sentence followed by edge-case explanations and a bulleted args section. It is somewhat long, but each sentence adds necessary behavioral context. The structure is front-loaded with the core action, making it easy to scan.

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?

The description is complete for an agent to invoke the tool correctly. It covers return values, side effects, and the disassembly mode. Since an output schema exists, return format details are not required. No essential context is missing, making it self-sufficient for the tool's complexity.

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 must compensate. It does so effectively: target is defined as an address, exact label, or function name; program is explicitly required as a Ghidra project path or name; name is described as an optional user-defined function name. This adds semantic meaning far beyond the schema's type-only definitions.

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 clearly states the tool's primary function — creating a function at a target address — and immediately explains edge cases: existing function at target (return and rename), target inside an existing function (return containing function), and disassembly behavior when target is not an instruction. This is a specific verb+resource description that uniquely identifies the operation and distinguishes it from siblings like decompile or disassemble.

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 description explains the tool's behavior in detail but does not explicitly state when to use it over alternatives or when not to use it. Usage is implied (when you want to create a function), but there is no mention of sibling tools or conditions that would make another tool more appropriate. This falls under implied usage rather than explicit guidance.

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