Skip to main content
Glama
turbyho

fw-context-mcp

by turbyho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

configure_llm

Set per-project LLM API, model, and embedding options in a gitignored local file; validates the connection and rolls back on failure, leaving shared config untouched.

Instructions

Configure LLM settings for the current project.

Writes to <project>/.fw-context/local.toml ONLY (gitignored, per-developer). Does NOT modify the global config or the shared project config.toml. After writing, tests the configuration by making a simple API call (skipped when LLM is disabled). When the test fails, the previous local.toml is restored and status is "error". A call with no change returns "error" and writes nothing.

IMPORTANT: When chat_api_base points to an external host, source code snippets in chat prompts will be sent to that endpoint. Ensure this complies with your organization's data security policies. Consider using local Ollama or an internal API proxy 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. chat_api_base: Chat API URL (see description for format details). chat_api_key: Bearer token for cloud/proxy APIs. chat_api_format: Override auto-detection: "ollama" or "openai"; "auto" returns to detection from the URL. None keeps the current value. model: Chat model name. embed_model: Embedding model: an Ollama tag, a sentence-transformers name (BAAI/..., needs the st extra), or ft://. auto_pull: Whether to auto-pull models on 404. None keeps the current value. stream: Stream chat responses via SSE. True avoids reverse-proxy idle timeouts.

Returns: dict: {status ("ok"|"error"), chat_api (dict — configured, endpoint, format, model), model (str), auto_pull (bool), stream (bool), test_latency_s (float, on success), test_response (str, on success), compliance_warning (str, when chat_api_base is external), message (str)}

Input Schema

NameRequiredDescriptionDefault
modelNoChat model name. None = keep current.
streamNoStream chat responses via SSE (both OpenAI-compatible and Ollama-native). True = send stream:true, consume SSE chunks — avoids reverse-proxy idle timeouts (nginx 60s, Cloudflare 100s). None = keep current setting.
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.
auto_pullNoAuto-pull models on 404 (Ollama only). False for intranet. None = keep current.
embed_modelNoEmbedding model: an Ollama tag, a sentence-transformers name (e.g. 'BAAI/bge-small-en-v1.5'), or 'ft://latest'. None = keep current.
chat_api_keyNoAPI key for cloud/proxy APIs. None for local/no-auth.
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.
chat_api_baseNoChat API URL. None = use local Ollama for chat. Auto-detects format: :11434 or /api/generate -> Ollama, /v1 or bare host -> OpenAI-compatible. Examples: 'https://api.deepseek.com/v1' (DeepSeek), 'http://localhost:4000' (LiteLLM), 'http://localhost:8080/v1' (llama.cpp). WARNING: external URLs send source code to that host.
chat_api_formatNoFormat override: 'ollama' or 'openai'; 'auto' returns to detection from the URL. None = keep current.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.32.1
    • addedInput schema / properties / auto_pull / anyOf
      Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / auto_pull / default
      Previous value: -falseNew value: +null
    • changedInput schema / properties / auto_pull / description
      Previous value: -"Auto-pull models on 404 (Ollama only). False for intranet."New value: +"Auto-pull models on 404 (Ollama only). False for intranet. None = keep current."
    • removedInput schema / properties / auto_pull / type
      Removed value: -"boolean"
    • addedInput schema / properties / chat_api_format / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / chat_api_format / default
      Previous value: -"auto"New value: +null
    • changedInput schema / properties / chat_api_format / description
      Previous value: -"Format override: 'auto' (default), 'ollama', or 'openai'."New value: +"Format override: 'ollama' or 'openai'; 'auto' returns to detection from the URL. None = keep current."
    • removedInput schema / properties / chat_api_format / type
      Removed value: -"string"
    • changedInput schema / properties / embed_model / description
      Previous value: -"Embedding model name (Ollama only). None = keep current."New value: +"Embedding model: an Ollama tag, a sentence-transformers name (e.g. 'BAAI/bge-small-en-v1.5'), or 'ft://latest'. None = keep current."
  2. 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."
  3. Addedv0.25.3

TDQS

A4.4/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 the exact write target (local.toml, gitignored, per-developer), what it does NOT touch (global config, shared config.toml), the post-write API test and its skip condition, rollback of local.toml on failure, and that a no-op call returns error and writes nothing.

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?

Well front-loaded: side-effect scope first, then the compliance warning, then Args and Returns. The Args section is somewhat redundant with the 100%-covered schema, which is the only waste in an otherwise tight structure.

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 complex 9-parameter config-writing tool with no output schema, the description covers side effects, rollback semantics, the post-write test, and a full Returns breakdown, plus a data-security caveat. Nothing needed to call it safely 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 baseline is 3. The Args section largely restates the schema rather than adding new meaning, though the chat_api_base note and security warning add marginal context. No syntax or format detail beyond what the schema already documents.

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?

States a specific verb ('Configure') and resource ('LLM settings') scoped to the current project. No sibling tool performs configuration, so it is trivially distinguishable from the read/search siblings, and it even names list_projects as a helper.

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?

Gives clear routing guidance between project and project_root ('It is an alternative to project_root... Give one of the two, not both') and points to list_projects. It lacks explicit when-not-to-use framing, but the config scope is unambiguous.

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