Skip to main content
Glama

get_project_context_tree

Scans a project directory and builds a hierarchical AST context tree, reducing prompt tokens by loading architecture and signatures at session start or before refactors.

Instructions

Scans the target project directory and builds an enterprise-grade multi-tier T-Zero hierarchical context tree (T-1 Master Architecture, T-2 Module References, T-3 AST Signatures, T-4 Agent Boundary Rules).

Behavior:

  • Read-only: Performs static AST analysis without modifying any files on disk.

  • Idempotent: Deterministic output for identical repository states.

  • 100% Offline: Executes locally without network calls, external embeddings, or LLM billing.

Usage Guidelines:

  • When to use: Ingest repository architecture and signatures into prompt context at the start of a coding session or before large refactors (80-95% token savings).

  • Sibling Routing: For a fast single-page class/method symbol index, use 'generate_repo_map'. For full implementation of an active file with 1st-degree caller/callee skeletons, use 'get_smart_skeleton_context'. For arbitrary in-memory snippets, use 'prune_code_snippet'.

Returns: Structured Markdown containing directory tree, module outlines, and AST signatures up to max_tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_tokensNoUpper token budget threshold for returned context. When exceeded, PageRank & Git recency prioritizes critical architectural files.
project_rootNoTarget repository root path to scan (default: current working directory)..
reduction_modeNoAST reduction level: 'ultra' for signatures & docstrings (80-95% reduction), 'balanced' for signatures + control headers, 'none' for verbatim source.ultra
include_file_contentsNoWhen True, includes AST-reduced file bodies; when False, emits only the directory hierarchy and high-level architectural outline.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.1
    • addedInput schema / properties / include_file_contents / description
      Added value: +"When True, includes AST-reduced file bodies; when False, emits only the directory hierarchy and high-level architectural outline."
    • addedInput schema / properties / max_tokens / description
      Added value: +"Upper token budget threshold for returned context. When exceeded, PageRank & Git recency prioritizes critical architectural files."
    • addedInput schema / properties / project_root / description
      Added value: +"Target repository root path to scan (default: current working directory)."
    • addedInput schema / properties / reduction_mode / description
      Added value: +"AST reduction level: 'ultra' for signatures & docstrings (80-95% reduction), 'balanced' for signatures + control headers, 'none' for verbatim source."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations are absent, so the description carries the full burden, and it does so well by disclosing read-only, idempotent, and offline/no-LLM-cost traits. It omits error behavior, handling of unreadable/symlinked directories, and runtime cost characteristics, which leaves modest gaps for a repository-wide scan.

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 front-loaded with a one-line purpose followed by labeled Behavior / Usage Guidelines / Returns sections that scan quickly. Some jargon is inflated ('enterprise-grade multi-tier T-Zero', 'T-1 Master Architecture'), which adds words without adding agent-relevant meaning, but the structure is clean.

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?

The tool is moderately complex (4 params, AST scanning) and the description covers behavior, safety profile, usage context, sibling routing, and output shape; with an output schema present it need not detail return values. Nothing an agent needs to invoke it correctly is missing.

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 each parameter (max_tokens, project_root, reduction_mode, include_file_contents) is already well documented in the schema, so the baseline of 3 applies. The description only lightly reinforces this by mentioning 'up to max_tokens' in the Returns line and adds no format details beyond 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 names a specific verb and resource ('Scans the target project directory and builds ... hierarchical context tree') and immediately differentiates itself from siblings via an explicit Sibling Routing paragraph that names generate_repo_map, get_smart_skeleton_context, and prune_code_snippet with the conditions that select each. An agent can route correctly 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 Guidelines5/5

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

It states precisely when to use it ('start of a coding session or before large refactors') with a quantified benefit, and then provides explicit alternative routing for four distinct sibling scenarios. This is the when/when-not/alternatives pattern executed fully.

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