Skip to main content
Glama

get_active_build

Assess the health of the build configuration index by retrieving its metadata. Use the status field to determine if a reindex is required or if the index is ready for queries.

Instructions

MANDATORY FIRST CALL for C/C++ projects. Return metadata about the most recently indexed build configuration — check index health before using any other fw-context tools.

Read-only: yes. Call at session start to check if the index exists, how many symbols it contains, and whether a reindex is needed.

Use the status field for decision-making:

  • "ready" — fully up to date, no issues. Continue normally.

  • "reindexing" — background reindex in progress. Index is still usable — all queries return accurate results. Continue normally.

  • "reindex_needed" — compile_commands.json changed or schema mismatch. Run fw-context index, but queries still work on existing data.

  • "no_index" — no build config indexed. Use other tools.

  • "error" — DB corruption or access error. Use other tools.

reindex_needed is True when a structural mismatch exists: schema version outdated or compile_commands.json changed since indexing. Modified source files are auto-handled per-query and do NOT cause reindex_needed=True.

index_message is a human-readable summary of the index state.

When modified_files_count > 0, a background fw-context index subprocess is spawned automatically (non-blocking, at most one at a time). Queries continue to be served from the existing index while the new one is being built. reindex_progress contains the last log line from the reindex subprocess when bg_reindex_running is True.

Args: project_root: Project root directory. Auto-detected from CWD if omitted.

Returns: dict: {config_hash, project_id, project_root, build_system, compile_commands, indexed_at (ISO timestamp), symbol_count, file_count, reference_count, modified_files_count (int), header_affected_tus (int — number of TUs with stale header dependencies), manifest_verification (str — "full" when manifest.json exists, "none" otherwise), analyzed_symbols (int), unanalyzed_symbols (int — definition symbols still needing LLM analysis), analysis_model (str or None), vendor_paths (list[str] — config index.vendor_paths), project_paths (list[str] — config index.project_paths), bg_reindex_running (bool), reindex_progress (str or None — last log line when reindex is running), schema_version (int — DB schema version), current_schema (int — code expects), status (str — "ready"|"reindexing"| "reindex_needed"|"no_index"|"error"), reindex_needed (bool — structural mismatch requiring a full reindex), reindex_reasons (list[str] — why reindex is needed, empty when False), index_message (str — human-readable summary of index state)}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_rootNoProject root directory. Auto-detected from CWD if omitted.
Behavior5/5

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

Despite no annotations, the description fully discloses behavioral traits: read-only nature, background reindexing behavior, auto-detection of project_root, and detailed status meanings. It explains reindex_needed conditions and non-blocking subprocess spawning.

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 description is lengthy but well-structured with clear sections (status, reindex_needed, returns). Every sentence adds value, though minor tightening could improve conciseness.

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 no output schema, the description provides a comprehensive list of return fields with explanations. It covers all necessary behavioral aspects and edge cases, making it complete for the tool's complexity.

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 description coverage is 100%, so baseline is 3. The description adds value by repeating and slightly expanding on the parameter's behavior (auto-detection from CWD), justifying a score of 4.

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 explicitly states it is the 'MANDATORY FIRST CALL for C/C++ projects' and clearly defines its function: returning metadata about the most recently indexed build configuration. It distinguishes itself from sibling tools by positioning itself as the health-check tool.

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?

Provides explicit guidance on when to call (session start, to check index health) and how to interpret the status field for decision-making. It also advises when to use other tools (e.g., for 'no_index' or 'error' status), offering clear when-not-to-use context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/turbyho/fw-context-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server