Skip to main content
Glama

Callers, callees and impact of a change (LayerMap)

project_explore_map
Read-onlyIdempotent

Trace what calls a function, what a change affects, and what it calls up to 8 levels, then map files and declarations before reading source.

Instructions

Use this before grep or reading files to answer what calls a function or method, what changing it affects (callers traced up to entry points such as HTTP routes, handlers, jobs and commands), what it calls, and what a directory or file contains: one call returns the callers or callees up to 8 levels deep, with file paths and line numbers, for TypeScript, JavaScript, Go, Python and Java. Read the static project map, zooming from the whole project to one declaration. path "." or a directory lists modules, module imports, external packages and its files: with exported declarations when the listing is small, as file names and line counts by directory when larger, and as modules only when very large. Start here to see what exists before searching or reading. A file path lists its declarations and members, imports, importers and top-level statements. A file path with name (or Container.member), optionally narrowed by its start line, or with a line alone, shows that declaration's calls, callers (including uses as a value), writes, heritage, decorators and members, aggregated per related declaration with @line sites; closures and locals are folded into their named container. depth also expands the related declarations hop by hop: up to 8 in one direction, which traces callers up to entry points (INCOMING) or callees down (OUTGOING), and up to 3 for BOTH. To find what a change affects, select the declaration with direction INCOMING and a depth up to 8, continue from any NOT EXPANDED declarations the view names, then confirm the entry points in source. Test files and standard-library call targets are hidden and counted by default; includeTests and includeUnresolved show them. Read source at the printed line ranges. The map is static: calls through an interface, type or base member continue to the members it links as implementations (dispatches to, dispatched from), while trace stops, possible callers by name (calls of a same-named member on a receiver of unknown type), framework wiring and unresolved targets need source reading, and a missing relationship does not prove absence. When a page reports more entries, continue with offset and otherwise unchanged arguments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lineNoStart line of a same-named declaration; without name, the declaration containing this line.
nameNoDeclaration name or Container.member in the file, as printed by the map.
pathNo"." or a directory for an overview, or a file for its declarations..
depthNoRelationship hops for a declaration: up to 8 for INCOMING or OUTGOING (for example callers up to entry points), up to 3 for BOTH.
offsetNo
directionNoBOTH
includeTestsNo
includeUnresolvedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover the safe-read profile (readOnly, idempotent, non-destructive, closed-world), while the description discloses substantial behavior beyond that: depth caps (8 INCOMING/OUTGOING, 3 BOTH), test files and stdlib targets hidden and counted by default, pagination via offset, and a precise static-analysis limitation model (traces stop, possible callers by name, framework wiring and unresolved targets need source reading, absence is not proof). This is exactly the extra context the annotations cannot supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and starting guidance are front-loaded, but the body is one very long, dense paragraph mixing invocation syntax, output formats, analysis workflow and caveats, with repetition ('before searching or reading' recurs). For a tool this complex some length is warranted, yet several clauses could be split or trimmed without loss.

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?

With 8 parameters, no output schema and no required fields, the description carries the return-shape burden itself and does so: it describes file paths and line numbers, per-declaration aggregation with @line sites, and how listing detail degrades from exported declarations to file names/line counts to modules-only. Edge cases, defaults and continuation are all covered.

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?

Despite only 50% schema description coverage, the description supplies meaning for effectively every parameter: path '.'/directory/file semantics, name as Container.member, line as the containing-or-disambiguating declaration, depth directional caps, direction INCOMING/OUTGOING/BOTH, includeTests/includeUnresolved, and offset used with otherwise unchanged arguments. It materially exceeds the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a precise set of verbs and resources: it returns callers, callees, impact, directory/module contents and per-declaration detail, with language coverage and line/file output named. The scope (static project map, zooming from project to a single declaration) is unmistakable. What it does not do is name or differentiate itself from the sibling tools it overlaps with (project_find_references, project_search_map), so the agent must infer the boundary itself.

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?

Strong when-to-use guidance: 'Use this before grep or reading files', 'Start here to see what exists before searching or reading', plus a concrete impact-analysis workflow (INCOMING + depth up to 8, continue from NOT EXPANDED declarations, confirm entry points in source). The gap is that the alternatives named (grep) are external, not the actual sibling MCP tools whose overlap with this one is the real routing risk.

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