Skip to main content
Glama

get_active_build

Check the health of the C/C++ index at session start. Returns metadata about the last indexed build configuration, including symbol count, staleness, and reindex status.

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 it is stale (needs re-index).

stale is True when any of: (1) compile_commands.json changed since the last index, (2) source files were modified after indexing, or (3) the index schema is older than the current code expects (schema_version < current_schema). Cases (1) and (2) are handled transparently by auto-reindex on query; case (3) requires a full fw-context index — remind the user.

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.

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), analyzed_symbols (int), unanalyzed_symbols (int — definition symbols still needing LLM analysis), analysis_model (str or None), 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), stale (bool — any staleness condition)}

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?

No annotations provided, but the description comprehensively details read-only nature, stale condition logic, auto-reindex spawning (non-blocking, at most one), and background query serving. It also explains return fields thoroughly.

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?

The description is well-structured with sections, front-loading the mandatory call note. Every sentence adds value, covering purpose, usage, behavior, and return details without redundancy.

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 the complexity (index health, stale conditions, auto-reindex, return fields), the description covers all necessary aspects. No output schema exists, but the description details the return dict, ensuring completeness.

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?

Only one optional parameter with 100% schema coverage. The description repeats the auto-detection note from the schema, adding no new information. Baseline of 3 is appropriate as the schema already documents the parameter.

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 identifies the tool as a mandatory first call for C/C++ projects, returning metadata about the most recently indexed build configuration. It distinguishes itself from sibling tools by being the health check for the index.

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?

Explicitly states 'MANDATORY FIRST CALL' and instructs to 'check index health before using any other fw-context tools.' It also explains when to reindex based on stale conditions, providing clear when-to-use guidance.

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