MCP Local LLM Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| settings | No | Path to a custom settings file (e.g., env.settings). This corresponds to the --settings command line argument. | |
| WORKSPACE_ROOT | No | The path to your project for proper path resolution. Automatically detected in many environments but can be explicitly set. | |
| OPENROUTER_API_KEY | No | Optional API key for testing with OpenRouter as an external backend. | |
| TESTING_MODE_ENABLED | No | Enables testing mode, typically used when testing with external SOTA backends like OpenRouter. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| summarizeB | Summarize a file, folder, or repo. Use action=path|repo. Prefer compact mode to keep context small. |
| discover_toolsA | Find tools by category/capability. Check callable+requiredArgs before invoking. Use include_examples only when needed. |
| mcp_healthB | Health/diagnostics. Healthy when any backend is available. format=dense gives compact status. includeDetails adds routing/cache stats and redacted errors. |
| agent_taskA | Autonomous multi-step task runner. Use readOnly for analysis. Defaults: maxSteps=50, maxActionsPerStep=100; use async for long tasks. |
| orchestrationB | Manage CLI orchestration settings. Use simulate for read-only routing prediction; use logs for runtime routing evidence. |
| cli_orchestrateC | Execute tasks via OpenCode/Copilot orchestration. Requires orchestration enabled. |
| workspaceB | Workspace metadata/snapshot/explore helper. Use for quick structure discovery before deeper tools. |
| todosC | Find or implement TODO/FIXME markers with prioritization options. |
| codebase_qaC | Answer repo-level questions using indexed context and local LLM. |
| analyze_test_gapsA | Estimate missing tests from source/test patterns (requires root). Supports relative-path globs; defaults include TS/JS/PY. Guidance only. |
| analyze_impactB | Estimate ripple effects of changed files across dependencies, imports, and tests. |
| index_symbolsB | Build in-memory symbol index for cross-file lookups. |
| cross_file_linksC | Trace import/export links from entry points. |
| securityC | Security actions: scan, risk, redact, fix. scan may return coverage guidance for narrow scope; use recommended include globs and includeHidden=true. |
| linterC | Run lints, syntax validation, or LLM-assisted lint fixes. |
| formatterC | Run formatter or LLM-assisted syntax fixes. |
| analyze_fileC | LLM analysis for one file. If path is a directory, returns candidate-file hints. includeContent defaults to false. |
| searchC | Unified search (intelligent|structured|gather|filenames). root defaults to "." when omitted. |
| local_code_reviewB | Privacy-preserving code review (security/performance/style/comprehensive). Hidden files require includeHidden=true. |
| generate_docsC | Generate docs (jsdoc/readme/api/examples) for a file or folder. |
| suggest_refactoringB | Suggest refactors with tradeoffs and safer alternatives. |
| suggest_editB | Propose targeted code edits from intent. apply=true auto-applies only high-confidence edits. |
| find_and_fixC | Search -> analyze -> suggest/apply fixes for repeated patterns across files. |
| draft_fileA | Generate a new file draft from intent and local patterns. Does not write files. |
| generate_agents_mdA | Generate AGENTS.md from project structure. useLlm=false for faster static output. |
| find_duplicatesB | Detect similar files/functions/code spans with similarity thresholds. |
| code_quality_analyzerC | Run multi-signal quality checks: duplicates, complexity, smells, security. |
| code_helperC | Explain, optimize, or simplify code snippets. |
| regex_helperB | Explain regex or generate regex from natural language. |
| refactor_helperC | Naming suggestions and extraction hints for selected code. |
| mcp_diff_summarizerC | Summarize code diffs into concise human-readable changes. |
| mcp_error_explainerB | Explain stack traces/errors and likely fixes. |
| mcp_translate_codeB | Translate code between languages with structure preservation. |
| mcp_plan_implementationC | Turn a feature request into concrete implementation steps. |
| mcp_analyze_complexityC | Estimate Big-O complexity with optional detail. |
| mcp_summarize_logsC | Condense logs and highlight likely root causes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| analyze-security | Run comprehensive security analysis on your codebase. Scans for secrets, vulnerabilities, and security risks using local LLM. |
| find-todos | Find and prioritize all TODOs, FIXMEs, HACKs, and technical debt markers in your codebase. |
| review-changes | Use local LLM to review recent code changes. Privacy-preserving code review that never leaves your machine. |
| explain-code | Get detailed explanation of code using local LLM. Includes purpose, structure, and potential issues. |
| generate-tests | Generate test cases for your code using local LLM. Creates comprehensive tests with edge cases. |
| suggest-improvements | Get refactoring and improvement suggestions for your code using local LLM. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 36 tools
The tool set has clear functional groupings (e.g., analysis, code generation, refactoring), but there is significant overlap in purpose. For example, 'analyze_file', 'summarize', and 'codebase_qa' all involve analyzing or summarizing code content, which could lead to agent confusion. Similarly, 'code_quality_analyzer', 'linter', and 'security' tools all perform code quality checks with blurred boundaries.
Naming conventions are mixed, with some tools using verb_noun patterns (e.g., 'analyze_file', 'generate_docs', 'suggest_edit') and others using noun_verb or other styles (e.g., 'code_helper', 'formatter', 'todos'). There is inconsistency in prefix usage, as some tools start with 'mcp_' while others do not, and abbreviations like 'qa' in 'codebase_qa' deviate from the general pattern.
With 36 tools, the count is excessive for a local LLM server, leading to a bloated and overwhelming interface. This many tools suggests poor scoping, as many functions could be consolidated (e.g., multiple analysis tools) or omitted without losing core functionality. It exceeds typical well-scoped servers (3-15 tools) and risks usability issues.
The tool set covers a broad range of code-related tasks, including analysis, generation, refactoring, and quality checks, with no obvious major gaps for a local LLM server. However, minor gaps exist, such as the lack of a dedicated tool for version control operations (e.g., git integration) or real-time collaboration features, which could enhance the server's utility.