Skip to main content
Glama

analyze_code_dependencies

Read-onlyIdempotent

Map module imports, symbol call chains, graph centrality, and unreferenced dead code across polyglot repositories to inspect dependencies before refactoring, moving, or removing code.

Instructions

Analyzes module imports, symbol call chains, graph centrality (PageRank), and unreferenced dead code across polyglot source files, distinguishing from 'analyze_change_impact' and 'enforce_architecture_rules' by performing global dependency structure and dead-code analysis rather than calculating change blast radius or verifying layer boundaries.

Parameters:

  • analysis_type (str, optional, default='dependencies'): Type of structural analysis: 'dependencies' for module import/export graph, 'call_chain' for deep caller/callee execution trace, 'pagerank' for architectural backbone centrality, 'dead_code' for unreferenced symbols.

  • project_root (str, optional, default='.'): Root directory of the repository to scan (default: current directory).

  • target_symbol (str, optional, default=''): Target class or function name when analysis_type is 'call_chain'.

  • file_path (str, optional, default=''): Optional path to a specific file to analyze.

Behavior:

  • Read-only: Inspects source syntax trees without modifying or moving files.

  • Idempotent: Deterministic dependency mapping for any scanned repository.

  • 100% Offline: Local AST and regex parsers; zero external network requests.

  • Auth & Rate Limits: Zero authentication or cloud credentials required; runs in <1s.

  • Error Handling: Emits clean notices if the target symbol or file is not found in the AST index.

Usage Guidelines:

  • When to use: Run before refactoring, moving, or removing a module to inspect inbound dependents, outbound imports, deep symbol call chains, or unreferenced functions.

  • When NOT to use: Do not use for estimating the blast radius score of modifying a specific function or class (use 'analyze_change_impact' instead); do not use for validating whether imports violate architectural layer rules (use 'enforce_architecture_rules' instead).

Returns: Markdown report detailing import graphs, call chains, centrality rankings, or detected dead code.

Input Schema

NameRequiredDescriptionDefault
file_pathNoOptional path to a specific file to analyze.
project_rootNoRoot directory of the repository to scan (default: current directory)..
analysis_typeNoType of structural analysis: 'dependencies' for module import/export graph, 'call_chain' for deep caller/callee execution trace, 'pagerank' for architectural backbone centrality, 'dead_code' for unreferenced symbols.dependencies
target_symbolNoTarget class or function name when analysis_type is 'call_chain'.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv7.3.2
  2. Removedv7.0.1
  3. Addedv7.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, but the description adds useful operational context: zero auth/cloud credentials, sub-second execution, offline AST parsing, and clean error handling for missing symbols or files. Some statements repeat annotation semantics, which keeps it from a 5.

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?

Well structured and front-loaded, with the differentiation statement early and clear sections for behavior and usage. It is somewhat over-formatted and repeats parameter details already present in the schema, but the length is justified by the tool's complexity.

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?

Covers purpose, sibling routing, read-only behavior, offline execution, auth requirements, performance, and error handling. An output schema exists and the description briefly notes the Markdown report format, so return-value explanation is not required in depth.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description largely restates the same parameter meanings rather than adding syntax, constraints, or conditional rules beyond the schema. Baseline 3 is appropriate when the schema already documents all parameters.

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?

States the specific analyses performed (imports, call chains, PageRank, dead code) and explicitly distinguishes itself from analyze_change_impact and enforce_architecture_rules. An agent can identify the tool's scope and sibling boundaries without opening the schema.

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?

Includes explicit 'When to use' and 'When NOT to use' sections, naming both alternatives and the exact conditions that should route the agent elsewhere. This is about as clear as usage guidance gets.

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