fw-context-mcp

Overview Schema Source Related Servers Discussions Admin

check_dependencies

Run a read-only dependency audit of the fw-context installation to find missing prerequisites and get repair commands before init or when project status reports problems.

Instructions

Run the dependency audit of the installation. Read-only, and it creates no file.

Call it when get_project_status or another tool reports a problem of the installation, or before the first fw-context init. It is not a call for each session: it runs every check of the installation.

Each entry gives what to do in action: a message for a human, and the shell command that repairs it. status="skipped" means a prerequisite is missing (e.g. libclang-so skipped because libclang-python is absent) — not a failure.

In a project that is not initialized, only the checks that need no project config run: the Python packages and libclang. The Ollama, model, database and build checks need the config.

The check config names a config file that cannot be used. The checks that read the config are then skipped. When a config file cannot be used, the tool cannot know if the project is initialized, thus it runs every check.

Args: project_root: Project root directory. Auto-detected from CWD 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: list[dict]: one dict per check, each with name, status, critical (bool), message, and an optional action ({message, command}).

Input Schema

Name	Required	Description	Default
`project`	No	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.
`project_root`	No	Project root. Auto-detected if omitted. Pass explicitly when the project is not the server cwd. This field also accepts a project name or a project_id, but project is the clear field for those.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.30.0Sep 5, 2026

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. Pass explicitly when the project is not the server cwd."New value: +"Project root. Auto-detected if omitted. Pass explicitly when the project is not the server cwd. This field also accepts a project name or a project_id, but project is the clear field for those."

Addedv0.25.3Aug 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it discloses read-only behavior, the meaning of status='skipped' as a missing prerequisite rather than a failure, which checks run in an uninitialized project, and the fallback behavior when a config is unusable. This is substantive behavioral context beyond any structured field.

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?

Purpose and read-only guarantee are front-loaded, and most paragraphs cover distinct behavioral nuances. It is on the verbose side and repeats the project/project_root guidance already in the schema, but little is purely wasted.

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 tool whose output schema already defines the returned fields, the description adds the remaining context an agent needs: when checks are skipped, how uninitialized projects are handled, and what the action/command fields are for. Nothing material is missing.

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 both parameters. The description explains the project vs project_root relationship ('use one of the two, not both'), but this largely restates the schema text, 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 first sentence states a specific verb and resource ('Run the dependency audit of the installation') and immediately discloses the safety profile ('Read-only, and it creates no file'). It is clearly distinguishable from siblings like check_ollama and get_project_status, which check narrower concerns.

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 when to call it ('when get_project_status or another tool reports a problem... or before the first fw-context init'), names the triggering sibling, and states a negative condition ('It is not a call for each session'). The when/when-not split leaves little to inference.

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