Skip to main content
Glama
turbyho

fw-context-mcp

by turbyho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

reindex_file

Re-parse a single C/C++ file with libclang to update its symbols in the index after edits, using compile_commands.json flags to avoid a full rebuild.

Instructions

Re-parse a single source file with libclang and update its symbols in the index.

Not read-only — uses the exact compiler flags from compile_commands.json. Use after editing a file to keep the index current without a full rebuild.

A source file must be listed in compile_commands.json. A header is not listed there, thus it is re-parsed through one unit that includes it. That answer covers a single compilation context, thus the result carries a warning — only a full fw-context index covers every unit that includes the header.

Also regenerates LLM analysis and method override relationships for affected symbols when those features are enabled in config. An unchanged symbol keeps its stored analysis.

Args: file_path: Path to the file to re-parse. A source file must be in compile_commands.json; a header goes through one including unit. project_root: Project root directory. Auto-detected if omitted. project: Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.

Returns: dict: {file, translation_units, symbols_updated, elapsed_s, analysis_updated (if LLM enabled), or error}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectNoProject name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.
file_pathYesPath to the file to re-parse. A source file must be in compile_commands.json. A header goes through one translation unit that includes it, and the result then carries a warning about the other units.
project_rootNoProject root. Auto-detected if omitted. This field also accepts a project name or a project_id, but project is the clear field for those.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.32.0
    • addedInput schema / properties / file_path / minLength
      Added value: +1
  2. Changed4 schema fields changedv0.30.0
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / file_path / description
      Previous value: -"Path to source file to re-parse. Must be in compile_commands.json."New value: +"Path to the file to re-parse. A source file must be in compile_commands.json. A header goes through one translation unit that includes it, and the result then carries a warning about the other units."
    • addedInput schema / properties / project
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.",
+  "title": "Project"
+}
    • changedInput schema / properties / project_root / description
      Previous value: -"Project root. Auto-detected if omitted."New value: +"Project root. Auto-detected if omitted. This field also accepts a project name or a project_id, but project is the clear field for those."
  3. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It explicitly warns 'Not read-only', explains the warning for headers, and discloses that LLM analysis and method override relationships are regenerated when enabled, while unchanged symbols keep stored analysis. It does not detail failure modes or side effects on the broader index, but it covers the most important behavioral traits.

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 well-structured with a clear opening, a 'Not read-only' warning, usage context, and an Args section. It is somewhat long but every sentence earns its place, and the most important behavioral warning is front-loaded. Minor redundancy with the schema's parameter descriptions prevents a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage, constraints, side effects, and return value shape. It lacks an output schema, but the Returns section lists the dict keys. It doesn't explain error cases or what happens if the file is not in compile_commands.json, but for a tool with this complexity, the description is nearly complete.

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 the schema already documents all three parameters. The description adds value by explaining the header-vs-source distinction and the project/project_root mutual exclusivity, which goes beyond the schema. It doesn't add much beyond that, but the schema is already rich, so a 4 is appropriate.

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 states a specific verb ('re-parse'), a specific resource ('a single source file with libclang'), and the outcome ('update its symbols in the index'). It also distinguishes itself from a full rebuild and from sibling tools like reindex_file_impl by clarifying it operates on a single file. The scope is unambiguous.

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?

The description explicitly says when to use it ('after editing a file to keep the index current without a full rebuild'), and it explains the constraint that source files must be in compile_commands.json while headers are handled through an including unit. It also gives clear guidance on project vs project_root alternatives, including 'Give one of the two, not both.' This is strong usage guidance.

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

Deploy Server

Other Tools