Skip to main content
Glama
AST-Navigator-MCP

AST-Navigator-MCP

Analyze Dependencies (local imports)

analyze_dependencies
Read-onlyIdempotent

List a JavaScript/TypeScript file's local dependencies by parsing its imports, re-exports, require calls, and dynamic imports.

Instructions

List the local files one JavaScript/TypeScript file depends on, from its Tree-sitter syntax tree: ES imports (including side-effect and import type), re-exports (export ... from), require() (also TypeScript import x = require()) and dynamic import(), anywhere in the file. Packages (node_modules), node: built-ins and path aliases are counted but not listed.

Use it to follow a module's dependency graph one file at a time, or to see what a file pulls in before changing it. It lists what a file imports, not which files import it.

Resolution mirrors TypeScript/Node.js for local specifiers: exact file, the .ts source behind a .js specifier, extension probing (.ts .tsx .d.ts .mts .cts .js .jsx .mjs .cjs .json) and directory index files. tsconfig 'paths' and package.json 'exports' are not read.

Args:

  • filePath (string): file to analyse (.js .mjs .cjs .jsx .ts .mts .cts .tsx). Absolute path recommended.

  • includeTypeOnly (boolean): include type-only references, erased at compile time (default true).

  • responseFormat ('markdown' | 'json'): 'markdown' (default) is a compact list; 'json' returns the full object.

Returns (structuredContent): { filePath, language, hasSyntaxErrors, dependencies[{ path, specifiers[], kinds[import|re-export|require|dynamic-import], typeOnly, lines[] }], unresolved[{ specifier, reason: not_found|outside_roots|invalid, kinds[], lines[] }], externalCount, nonLiteralCount, truncated } Dependencies are listed in order of first reference; several specifiers naming the same file are merged.

Examples:

  • "What does src/server.ts import from this repo?" -> { filePath: "/repo/src/server.ts" }

  • Runtime dependencies only -> add includeTypeOnly: false

Errors (isError=true, text starts with 'Error [CODE]'): FILE_NOT_FOUND, PERMISSION_DENIED, NOT_A_FILE, FILE_TOO_LARGE (> 2 MiB), PATH_OUTSIDE_ROOTS, INVALID_PATH. A dependency pointing outside the allowed roots is reported as unresolved with reason 'outside_roots'; its target is never revealed.

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": {
      "filePath": "<filePath>"
    },
    "name": "analyze_dependencies"
  }
}

Input Schema

NameRequiredDescriptionDefault
filePathYesSource file whose local dependencies to list. Absolute path recommended. Relative paths resolve against the server's first allowed root.
responseFormatNo'markdown' (default): compact outline for reading. 'json': full structured data.markdown
includeTypeOnlyNoInclude `import type` / `export type ... from` references, which are erased at compile time (default true).

Output Schema

NameRequiredDescriptionDefault
filePathYesAbsolute path of the analysed file
languageYesGrammar used to parse the file
truncatedYesTrue if the file has more distinct local specifiers than are resolved per call
unresolvedYesLocal specifiers that do not resolve to a file inside the allowed roots
dependenciesYesLocal files this file loads, in order of first reference
externalCountYesDistinct non-local specifiers ignored: packages (node_modules), node: built-ins, path aliases
hasSyntaxErrorsYesTrue if the file has syntax errors; references inside broken code may be missed
nonLiteralCountYesrequire()/import() calls with a computed argument, which cannot be followed statically

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, yet the description still adds substantial undisclosed behavior: exact resolution rules (extension probing list, .ts behind .js, directory index), what is counted but deliberately not listed (packages, node: builtins, aliases), what config files are ignored (tsconfig paths, package.json exports), the 2 MiB size ceiling, and that outside-roots targets are never revealed.

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?

Front-loaded purpose statement, then scoped sections for resolution, args, returns, examples and errors, which makes it easy to scan. Slightly heavy: the verbose Returns block duplicates an output schema that already exists, and the extension list appears in both the args section and the resolution paragraph.

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 static-analysis tool with nontrivial resolution semantics, the description covers matching rules, ordering/merging behavior, unresolved-reason taxonomy, truncation and the error code set. An agent could predict both the result shape and failure modes without trial calls.

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 on top: includeTypeOnly is explained as compile-time-erased references with a concrete 'runtime dependencies only' example, and filePath carries the 'absolute path recommended' guidance plus the accepted extension set. The responseFormat line largely restates the schema enum.

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 a concrete verb and resource ('List the local files one JavaScript/TypeScript file depends on') and pins down the exact scope: ES imports, re-exports, require, dynamic import. It also explicitly carves out the inverse operation ('It lists what a file imports, not which files import it'), so an agent can distinguish it from direction-reversed or whole-tree tools.

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?

Gives two explicit use cases ('follow a module's dependency graph one file at a time', 'see what a file pulls in before changing it') plus an exclusion ('not which files import it') and a worked example for the narrower runtime-only variant. Nothing about when to pick this tool is left to inference.

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