Skip to main content
Glama

Callers, callees and impact of a change (LayerMap)

project_explore_map
Read-onlyIdempotent

Use this instead of grep 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…

Instructions

Use this instead of grep 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. Views use kinds f function, c class, m method, p property, v variable, t type, i interface, e enum; numbers are 1-based source lines. In a declaration view, @n marks where a relationship occurs and +n counts further sites, which project_find_references lists; a quoted path after the sites is the route the call or value is registered under there: its HTTP methods when the registration names them, then its path joined with the prefixes of the routers it is registered on, as far as the same function or file sets them (a prefix added where a router is mounted or passed in is not included); route "…" after a decorator is the full route the decorator maps, its class's path joined with its own. Static relationships are grouped by the declaration that owns them. Callers are direct calls, uses as a value (stored, passed, returned or selected, then usually invoked through that value) and calls through an interface, type or base member that a declaration implements (dispatched from); dispatches to lists the members that implement an interface, type or base member, which a call through it may reach; trace stops names calls whose target is a function value, a member without a mapped implementation or a computed key, which only source reading can follow; possible callers by name are calls elsewhere, in the same language, of a member with a method's name on a receiver of unknown type (an untyped value, or one an unloaded package produced); they may or may not reach that method. Read source at the printed line ranges. The map is static: trace stops, possible callers by name, 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

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.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: static-only limitations ('trace stops, possible callers by name, framework wiring and unresolved targets need source reading, and a missing relationship does not prove absence'), default hiding of tests/stdlib with includeTests/includeUnresolved opt-ins, and offset-based pagination.

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?

Purpose is front-loaded, but the body is a dense wall of semicolon-joined clauses covering return formatting, route resolution, and edge cases in one breath. Nearly all content is substantive, yet the volume and run-on structure make it hard to scan and over-invests in low-frequency detail.

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 no output schema and a complex read tool, the description carries the full burden and does so: it documents result shape (file paths, line numbers, kinds f/c/m/p/v/t/i/e, @n site markers, +n counts), aggregation rules, and pagination. Nothing essential for correct invocation is missing.

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 coverage is only 50%, but the description compensates thoroughly, explaining direction semantics (INCOMING traces callers to entry points, OUTGOING callees), depth limits per direction (8 vs 3 for BOTH), path/name/line resolution, and offset continuation ('continue with offset and otherwise unchanged arguments').

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 opening states a specific verb and resource: 'Use this instead of grep to answer what calls a function or method, what changing it affects... what it calls, and what a directory or file contains.' It names one sibling (project_find_references) but leaves project_search_map and project_check_changes unaddressed, and the core purpose is somewhat buried under the dense enumeration that follows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: 'Use this instead of grep', 'Start here to see what exists before searching or reading', plus a concrete impact-analysis workflow ('select the declaration with direction INCOMING and a depth up to 8, continue from any NOT EXPANDED declarations'). It states both when to use it and how to continue the analysis.

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