Skip to main content
Glama

build_project_context

Read-onlyIdempotent

Scans a repository and builds a token-optimized, multi-tier AST context for LLM prompts, enabling architecture-aware coding sessions and refactors within a set token budget.

Instructions

Scans the target repository file system and constructs a token-optimized AST context payload for LLM prompts across multiple hierarchy tiers (T-1 to T-4), distinguishing from 'prune_code_snippet' and 'search_codebase' by constructing multi-tier repository architecture trees rather than pruning individual in-memory snippets or executing keyword searches.

Parameters:

  • project_root (str, optional, default='.'): Target repository root path to scan.

  • context_type (str, optional, default='tree'): Context generation mode: 'tree' for hierarchical multi-tier AST tree, 'repo_map' for compact symbol index, 'skeleton' for focus-file implementation with 1st-degree caller/callee skeletons, 'zero_waste_prompt' for agent prompt prefix with pruned AST, 'incremental_diff' for git diff context.

  • focus_file (str, optional, default=''): Optional path to a focus file when context_type is 'skeleton' or 'incremental_diff'.

  • reduction_mode (str, optional, default='ultra'): AST reduction depth level ('ultra' for 80-95% compression with signatures and docstrings, 'balanced' for signatures + control structures, 'none' for verbatim source code).

  • max_tokens (int, optional, default=64000): Upper token budget threshold for returned context.

  • include_file_contents (bool, optional, default=True): If True, includes AST-reduced file bodies; if False, emits directory hierarchy only.

Behavior:

  • Read-only: Scans workspace files and parses AST signatures without modifying disk state.

  • Idempotent: Generates deterministic context representations for identical workspace revisions.

  • 100% Offline: Operates entirely locally with zero telemetry, remote embedding APIs, or cloud billing.

  • Auth & Rate Limits: Zero authentication or cloud credentials required; completes in <2s for 1,000 files.

  • Error Handling: Returns clean Markdown warning notices if no analyzable files exist in the specified path.

Usage Guidelines:

  • When to use: Ingest repository architecture, module indexes, focus file skeletons, or zero-waste prompts at the beginning of an agent coding session or major refactor (80-95% token savings).

  • When NOT to use: Do not use for stripping implementation bodies from a single in-memory code string or diff patch (use 'prune_code_snippet' instead); do not use for querying specific code symbols or text without building a full context tree (use 'search_codebase' instead).

Returns: Structured Markdown document featuring '# Repository Architecture (T-1)', '# Module Dependencies (T-2)', '# AST Signatures (T-3)', '# Architectural Rules (T-4)', and token compression metrics.

Input Schema

NameRequiredDescriptionDefault
focus_fileNoOptional path to a focus file when context_type is 'skeleton' or 'incremental_diff'.
max_tokensNoUpper token budget threshold for returned context.
context_typeNoContext generation mode: 'tree' for hierarchical multi-tier AST tree, 'repo_map' for compact symbol index, 'skeleton' for focus-file implementation with 1st-degree caller/callee skeletons, 'zero_waste_prompt' for agent prompt prefix with pruned AST, 'incremental_diff' for git diff context.tree
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 directory hierarchy only.

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.6/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, closed-world and non-destructive, but the description goes beyond them with offline/zero-telemetry operation, no-auth requirement, a concrete performance bound (<2s for 1,000 files), and defined error behavior (Markdown warning notices when no analyzable files exist). That is real added context for a tool that walks a filesystem.

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?

The leading purpose sentence plus labeled Behavior/Usage Guidelines/Returns sections are front-loaded and scannable. It loses a point for re-listing all six parameters verbatim when the schema already documents them, which is filler rather than value.

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?

Given six optional params, full schema coverage, an output schema, and rich annotations, the description leaves nothing material unexplained — it covers modes, token budget, error paths, and the shape of the returned Markdown tiers.

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 parameter block in the description is essentially verbatim duplication of the schema entries, so it adds little beyond structured data. The only minor surplus is the '.' working-directory gloss and the compression percentages, which the schema mostly carries too.

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 specific verb+resource pair ('Scans the target repository file system and constructs an AST context payload') and immediately contrasts it with the two nearest siblings, prune_code_snippet and search_codebase, by describing what each does instead. An agent can differentiate without consulting 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?

Has explicit 'When to use' (start of coding session or major refactor, 80-95% token savings) and 'When NOT to use' sections that name the alternative tools and the condition that selects them. No inference required.

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