tree-sitter-analyzer

Overview Schema Source Related Servers Discussions Admin

structure

Read-onlyIdempotent

Analyze code structure via AST: outline symbols, measure complexity, trace class hierarchies, map sitemaps, and read sections on demand.

Instructions

Code-intelligence (codegraph-compatible) structural analysis facade. Covers codegraph_explore (multi-symbol source), codegraph_class_hierarchy, codegraph_class_inspect, codegraph_sitemap, codegraph_ast_path, and code-outline/complexity in one tool. Pick a capability via action:

action=outline — AST-based symbol outline for a file or directory. Params: file_path, language, depth.
action=analyze — complexity + structure analysis (cyclomatic, nesting, cohesion). Params: file_path, language.
action=signatures — LIGHTWEIGHT method-directory (~25 %% of full tokens). Lists every method as 'name →returnType(Np) startLine-endLine' grouped by class. Use FIRST for large files (>500 lines) to pick methods by name, then action=read to fetch bodies. Supports Python, Java, and other languages. Params: file_path[, language] (language auto-detected from file extension when omitted).
action=ast_path — AST path from a specific node up to the file root (navigate the parse tree, codegraph_ast_path equivalent). Params: file_path, line, column.
action=sitemap — high-level symbol sitemap of a directory or the whole project (what is defined where, codegraph_sitemap equivalent). Params: mode (full|api|module|flat), directory (relative path, optional), language, max_files. NOTE: takes a directory, not file_path — omit directory for the whole project.
action=class_tree — class inheritance/subclass hierarchy (codegraph_class_hierarchy equivalent). Params: class_name, mode (subclasses|superclasses|supers|tree|impact|all|summary). 'supers' is an alias for 'superclasses'.
action=class_detail — detailed class inspection: fields, methods, visibility, inherited members (codegraph_class_inspect equivalent). Params: class_name (or query as alias), language.
action=explore — multi-symbol source explorer: show source of several related symbols grouped in one capped response (codegraph_explore equivalent). Params: symbols (list) or symbol/query (string), maxSymbols, maxFiles.
action=read — extract a file section (single) or multiple sections (batch). Single: file_path + start_line [+ end_line + column bounds]. Batch: requests=[{file_path, sections:[{start_line, end_line}]}].

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	Action sub-mode (e.g. summary\|cycles).
`limit`	No	Max results.
`query`	No	Search query/pattern.
`scope`	No	Action discriminator (e.g. point\|graph).
`action`	Yes	Which capability to invoke. One of: analyze, ast_path, class_detail, class_tree, explore, outline, read, signatures, sitemap
`symbol`	No	Symbol/function name.
`language`	No	Language hint (usually auto).
`file_path`	No	Target file path.
`class_name`	No	Class name for class_tree and class_detail actions.
`function_name`	No	Function name (alias of symbol).
`output_format`	No	Output format: JSON.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.30.0Sep 11, 2026
- changedInput schema / properties / output_format / description
```
Previous value: -"Output format (toon|json)."New value: +"Output format: JSON."
```
- addedInput schema / properties / output_format / enum
```
Added value: +[
+  "json"
+]
```

Changed1 schema field changedv1.25.0Jun 18, 2026

addedInput schema / properties / class_name

Added value: +{
+  "description": "Class name for class_tree and class_detail actions.",
+  "type": "string"
+}

First observedv1.23.0Jun 12, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, lowering the bar, and the description adds genuine behavioral context beyond them: the token-cost profile of signatures (~25% of full tokens), the capping behavior of explore, and per-action parameter applicability. It does not describe error behavior or pagination limits, so not 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?

It is long, but the length is proportionate to nine sub-capabilities and is front-loaded with a per-action bullet format that scans quickly. Every bullet carries a distinct capability and parameter set; the only waste is a formatting artifact ('~25 %%') and a few redundant parenthetical codegraph-equivalent labels.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-action facade with a 1/11 required-parameter schema and no output schema, the description covers action selection, key parameters, and the two highest-risk pitfalls (sitemap takes a directory; signatures is the cheap first pass). Return-shape details are not needed since actions have differing outputs, though pagination/limits for explore and sitemap remain unstated.

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% (baseline 3), but the schema's own descriptions are generic ('Search query/pattern', 'Action sub-mode'), whereas the description maps which parameters apply to which action (e.g., file_path/language/depth for outline; class_name+mode for class_tree; symbols/maxSymbols/maxFiles for explore). That mapping materially reduces the risk of mis-invocation, exceeding baseline.

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 names a specific domain (code-intelligence / codegraph structural analysis) and enumerates the nine capabilities it fronts (outline, analyze, signatures, ast_path, sitemap, class_tree, class_detail, explore, read), each with a verb+resource. An agent can tell what it does without opening the schema. It does not explicitly differentiate itself from siblings like nav or search, so it falls short of a 5.

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?

Offers concrete when-to-use guidance for at least two actions: 'Use FIRST for large files (>500 lines) to pick methods by name, then action=read to fetch bodies' and the sitemap warning 'takes a directory, not file_path — omit directory for the whole project'. It also clarifies alias behavior ('supers' for 'superclasses'). No explicit cross-sibling exclusions (e.g., vs nav/search), so not a 5.

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

Deploy Server

structure

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools