Skip to main content
Glama

get_active_build

Check your C/C++ project's index health before using other tools. Returns status, symbol count, and reindex requirements to decide if indexing is needed.

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" — project initialized but no index built yet.

  • "not_initialized" — project has not been initialized (fw-context init not run).

  • "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.

Background reindex is managed by the startup daemon thread and the file watcher — get_active_build() is a read-only tool that does not spawn subprocesses. reindex_progress contains the last log line from the reindex subprocess when bg_reindex_running is True.

Set fast=False to include per-file stat scanning for accurate modified_files_count and header_affected_tus. The default fast=True is faster and sufficient for most session-start checks.

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), description (str), first_indexed_at (str), 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"|"not_initialized"|"error"), reindex_needed (bool — structural mismatch requiring a full reindex), reindex_reasons (list[str] — why reindex is needed, empty when False), stale (bool — True when reindex_needed or header_affected_tus > 0), _warning (str, optional — when manifest verification is not "full"), vec_available (bool), vec_error (str, optional), index_message (str — human-readable summary of index state)}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fastNoWhen True (default), skip per-file stat scan — faster but modified_files_count and header_affected_tus may be 0.
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?

With no annotations, the description carries full burden. It discloses that it's read-only, does not spawn subprocesses, explains reindex behavior, the meaning of fast=False, and the full status field semantics. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Slightly long but every section (status values, reindex semantics, fast parameter, args, returns) provides essential information. Front-loads the 'MANDATORY FIRST CALL' instruction.

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 description is comprehensive: covers all statuses, return dictionary fields, background reindex, and parameter trade-offs. No output schema is provided, but the return dict is fully documented in the description.

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 coverage is 100% and both parameters have descriptions in the schema. The description adds only marginal commentary about fast parameter (accuracy vs speed) that is already implied by schema. Baseline 3 applies.

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 clearly states 'Return metadata about the most recently indexed build configuration' and positions it as a health check for the index, distinguishing it from sibling tools by calling it the 'MANDATORY FIRST CALL'.

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 usage guidance: 'Call at session start', 'read-only tool', and 'before using any other fw-context tools'. It also explains what to do in each status, which is a strong when-to-use/alternatives guideline.

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