Skip to main content
Glama

analyze_method

Inspect a Java method at a file position to get signature, parameters, exceptions, callers, callees, and override info in one call, replacing separate method and call-hierarchy queries.

Instructions

Comprehensive method analysis in a single call.

USAGE: analyze_method(filePath="path/to/File.java", line=N, column=N) OUTPUT: Method info, parameters, exceptions, callers, callees, override info

Combines:

  • Method info (signature, modifiers, return type)

  • Parameters with types

  • Declared exceptions

  • Incoming calls (who calls this method)

  • Outgoing calls (what this method calls, in its lambdas included; a call in an anonymous or local class declared in it is a call of that class's member; creating an anonymous class is a call of the superclass constructor its constructor runs)

  • Override information (super method, overriding methods)

callers.count and callees.count are the exact numbers of distinct callers and callees; each list holds the first maxCallers (default 20) or maxCallees (default 50) of them, callers in search order and callees in source order. meta.totalCount counts both, meta.returnedCount those listed, and meta.truncated is true when either list is cut. A negative maxCallers or maxCallees is INVALID_PARAMETER.

The method is the one the position names, wherever it is declared: its file and line are those of its declaration, and its callees are read there. A method of a class file reports no file, line or callees (there is no source to read them from); its callers are those in the project's source files. callers.potentialMatches holds the references JDT could not confirm, the first maxCallers of them; overrides.potentialMatches the places naming the declaring type, or a subtype, as a supertype that JDT could not confirm. overrides.unresolvedSupertypes, present only when there are any, names each supertype of the declaring type the compiler cannot resolve, with the type whose declaration names it: the method may override a method of one of them.

Use this instead of multiple calls to get_method_at_position + call hierarchy tools.

IMPORTANT: Uses ZERO-BASED coordinates.

potentialMatches, present only when there are any, holds the places JDT's search reports as possible matches but cannot confirm, because a type or name there does not resolve (a missing dependency or a compile error): count is their exact number, and locations lists them, as many as the results it stands beside may list. They are never counted or listed as results.

Requires load_project to be called first.

Input Schema

NameRequiredDescriptionDefault
lineYesZero-based line number
columnYesZero-based column number
filePathYesPath to source file
maxCalleesNoMaximum callees listed (default 50); callees.count counts all
maxCallersNoMaximum callers listed (default 20); callers.count counts all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.3
    • changedInput schema / properties / maxCallees / description
      Previous value: -"Maximum callees to return (default 50)"New value: +"Maximum callees listed (default 50); callees.count counts all"
    • changedInput schema / properties / maxCallers / description
      Previous value: -"Maximum callers to return (default 20)"New value: +"Maximum callers listed (default 20); callers.count counts all"
  2. Addedv1.3.4
  3. Removedv1.3.3
  4. First observedv1.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, the description carries the whole burden and discharges it richly: truncation semantics (meta.truncated, totalCount vs returnedCount), INVALID_PARAMETER behavior for negative limits, position-resolution rules (declaration file/line, class-file methods reporting no callees), and what potentialMatches/unresolvedSupertypes mean. This is far beyond what the schema reveals.

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 opening is well front-loaded (USAGE, OUTPUT, Combines), but the body sprawls across many dense paragraphs, and the potentialMatches explanation and the load_project prerequisite are stranded toward the very end rather than grouped with related material. Much of the length is justified by the absent output schema, but it is not tight.

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?

For a high-complexity tool with no output schema, the description documents the returned structure (counts, meta fields, potentialMatches, unresolvedSupertypes), edge cases, and the sequencing prerequisite. An agent has enough to invoke it correctly and interpret the result without a schema.

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 the baseline is 3, but the description adds real meaning beyond the schema: it explains the interaction between callers.count/callees.count and the maxCallers/maxCallees truncation limits, and flags that negative values are INVALID_PARAMETER. The zero-based note merely echoes the schema.

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 ("Comprehensive method analysis") and explicitly enumerates what it covers: signature, parameters, exceptions, callers, callees, overrides. It also distinguishes itself from siblings by naming get_method_at_position and the call-hierarchy tools it replaces, so an agent can route without opening any 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 an explicit when-to-use rule ("Use this instead of multiple calls to get_method_at_position + call hierarchy tools") and a hard prerequisite ("Requires load_project to be called first"). It does not state when to prefer the narrower single-purpose siblings instead, so it falls short of a full when/when-not/alternatives treatment.

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