Skip to main content
Glama
Sign In
callgraph

callgraph

by GeRiY
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

method_body

Retrieve compact, line-numbered source for one or more methods, with optional docblocks or raw text, to inspect and edit functions without reading whole files.

Instructions

Line-numbered source of one or more methods/functions, compact: the docblock above the method and blank lines dropped, comments inside the body kept (line numbers stay exact; the header says when a docblock was omitted; doc: true adds it, raw: true = exact, unfiltered text, e.g. before editing). Use after outline instead of reading the whole file. Example: {"path": "app/Order.php", "method": ["cancel", "refund"]} (method may be a string or a list).

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": {
      "path": "<path>",
      "method": "<method>"
    },
    "name": "method_body"
  }
}

Input Schema

NameRequiredDescriptionDefault
docNoAlso include the docblock / doc comments above each method.
rawNoExact, unfiltered source (docblock and blank lines kept), e.g. before an exact edit.
fullNoDisable the 400-line output cap.
pathYesFile path, relative to the project root.
methodYesMethod/function name (`"cancel"`), or an array of names (`["cancel", "refund"]`).
projectNoRegistered project alias; default: the server's working directory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.3

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 burden and does disclose the non-obvious transformation semantics: docblocks and blank lines are dropped by default, comments inside the body are kept, line numbers remain exact, and the header flags an omitted docblock. It also explains the `doc`/`raw` escape hatches and their purpose ('e.g. before editing'), though it omits what happens when a method name is not found, the ordering of multiple results, and the 400-line cap (only documented in the schema).

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?

A single dense paragraph front-loaded with the return value, followed by the workflow rule and a usage example. Every clause carries information (compaction rules, flags, example) with no filler.

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?

There is no output schema, so the description must characterize the return value — and it does, precisely (line-numbered, compacted, header notes omissions). Combined with the schema-documented `full` cap and `project` scoping, an agent has nearly everything; only error/not-found behavior and multi-method result ordering are missing.

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 100%, so baseline is 3, but the description adds real meaning beyond the field descriptions: it explains that the default output drops the docblock and that `doc: true` restores it while `raw: true` yields exact unfiltered text for editing. The concrete JSON example also clarifies the string-vs-list flexibility for `method`.

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+resource: 'Line-numbered source of one or more methods/functions', and immediately names the scope (one or many methods) plus the compaction behavior. It explicitly contrasts itself with the sibling `outline`, so an agent can pick it without opening either 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?

It gives a clear workflow rule: 'Use after `outline` instead of reading the whole file', which routes the agent from outline to this tool and away from whole-file reads. It does not state explicit exclusions (e.g. when to prefer `search`, `locate`, or a full-file read for cross-method context), so it falls short of a full when/when-not pair.

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