Skip to main content
Glama
turbyho

fw-context-mcp

by turbyho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_environment_status

Aggregate project dependencies, build system, compile database, index, and LLM backend status in one read-only call to assess setup readiness at session start.

Instructions

Return the complete project environment status in one call.

Read-only. Aggregates five domains into a single call so the LLM can see everything at session start without extra round-trips:

  • deps — dependency audit (run_full_check), each entry with an optional action (message + shell command). status="skipped" means a prerequisite is missing (e.g. libclang-so skipped because libclang-python is absent) — not a failure.

  • build_system — detected build system, None when unknown.

  • compile_db — whether compile_commands.json exists and its entry count. Reported as {"exists": false, ...} before init (no config to resolve the path from, and loading one would create empty config files).

  • index — the FULL get_active_build() result, unchanged (its action lives in index_message).

  • llm — LLM backend status with an optional action.

When the project is not initialized (index.status == "not_initialized"), only the config-independent dependency subset runs (checks that do not need a project config) — Ollama/model/db/build checks are skipped.

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: dict: {init_status (str — "initialized" or "not_initialized"), deps (list[dict] — name, status, message, and an optional action), build_system (str or None), compile_db (dict — {exists (bool), path (str or None), entry_count (int or None — None before init, and when fw-context cannot read the file)}), index (dict — the full get_active_build result), llm (dict — {enabled, ollama_running, chat_model, embed_model}, plus ollama_enabled when the LLM check ran, plus an optional action)}.

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.
project_rootNoProject 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.

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. 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."
  2. Addedv0.25.3

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden, and it does this well: it labels the tool 'Read-only', explains skipped-status semantics, documents the truncated dependency check when uninitialized, and discloses the before-init compile_db behavior. This goes far beyond a generic 'get status' phrasing.

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 long but necessarily so, given the complex aggregate output and absent output schema. It is well structured with a front-loaded summary, bullets for the five domains, and dedicated Args/Returns sections. Every sentence contributes useful information.

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 with no output schema and a multi-domain return value, the description is remarkably complete: it documents every returned field, the uninitialized-project behavior, and optional action fields. An agent has enough to call it correctly and interpret its result.

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 coverage is 100%, so the baseline is 3. The description adds meaningful conflict guidance: 'Give one of the two, not both,' and clarifies when to use project vs project_root. This is useful semantic information not fully enforced by the schema.

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 starts with a concrete verb and resource: 'Return the complete project environment status in one call.' It further defines the aggregation of five named domains, which clearly distinguishes it from narrower sibling tools like check_dependencies or check_ollama.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly frames the tool as the session-start aggregate call: 'so the LLM can see everything at session start without extra round-trips.' It also clarifies the project vs project_root alternatives. However, it never explicitly says to use individual sibling tools when only a specific domain is needed.

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