Skip to main content
Glama
turbyho

fw-context-mcp

by turbyho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

reset_index

Permanently delete a project's symbol index and WAL files; run a dry-run first with confirm=False, then re-index with fw-context index.

Instructions

Delete the entire symbol index for a project.

Not read-only — permanently deletes the SQLite database and WAL files. Call with confirm=False first (dry-run) to see what would be deleted. Re-index with fw-context index afterwards.

Handles corrupt databases gracefully — you can delete a corrupt index without needing to open it first.

Args: 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. confirm: Must be True to execute. Call without first as dry-run.

Returns: dict: {project_root, db, project_id, action: "dry_run"|"deleted", message, build_count, symbol_count, indexed_at}. build_count counts the completed builds of the project, as get_project_status lists them. symbol_count counts every symbol row in the database, the rows that the reset deletes: also the rows of a build that an index run writes now, and of an older build of a pair that an interrupted run left behind. indexed_at is the time of the newest build. The three are present only when a build config is readable.

A ``warning`` key means that the database is corrupt — the
integrity check or a read of the database failed, thus the tool
counts nothing and the three count fields are absent.

On failure the dict holds only ``error`` with the reason.

Input Schema

NameRequiredDescriptionDefault
confirmNoMust be True to execute. Call without confirm first as dry-run.
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.
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. Changed3 schema fields changedv0.30.0
    • addedInput schema / additionalProperties
      Added value: +false
    • 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."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it declares the operation is not read-only, states that the SQLite database and WAL files are permanently destroyed, notes that corrupt databases can be deleted without opening them, and describes the dry-run vs deleted action values plus the corrupt-database `warning` path.

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 destructive warning and the dry-run-first instruction are front-loaded ahead of the reference material, which is good structure. It is somewhat long and the Args block largely restates the 100%-covered schema, but the Returns detail earns its space because there is no output schema.

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?

For a destructive, zero-annotation tool with no output schema, the description covers everything an agent needs: destruction semantics, dry-run safety flow, the follow-up re-index command, the returned dict fields, the count-field caveat, and the failure and corruption cases.

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%, so the schema already documents confirm, project, and project_root in nearly identical wording. The description adds only marginal detail (the corrupt-DB behavior and count fields), so the baseline 3 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 opening line states a specific verb and resource ('Delete the entire symbol index for a project'), including the scope of the deletion. It is clearly distinguishable from the many read/search siblings and from reindex_file, which the description explicitly names as the follow-up action.

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?

It prescribes the exact workflow — call with confirm=False first as a dry-run, then re-index with 'fw-context index' afterwards. It also names the sibling list_projects for resolving the project parameter and explains when to prefer `project` over `project_root` (cross-project queries), explicitly saying to give one, not both.

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