mcp-flow
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| inspect_projectA | Analyze a project's structure: directory tree, detected stack(s), package manager, available scripts, presence of tests/linter/typechecker, and notable config files. Read-only. |
| read_relevant_filesA | Read the files most relevant to a task without loading the whole project. Either pass candidateFiles, or let the tool rank files by lexical relevance. Content is truncated, secret-masked, and sensitive files are skipped by default. Read-only. |
| create_change_planA | Assemble a structured change plan from deterministic project context (likely files, checks to run, detected risks) before writing code. Returns a plan scaffold plus guidance for finalizing it. Makes a reasonable assumption rather than asking unless something is truly blocking. Read-only. |
| generate_patchA | Turn concrete |
| apply_patchA | Apply a unified diff to the project. Defaults to dryRun=true. All target paths are confined to the project root, suspicious mass deletions are refused, and touched files are backed up before writing. Validates that every hunk applies cleanly first. |
| run_project_checksA | Auto-detect and run the project's test / lint / typecheck / build commands. Only allowlisted base commands are spawned; each runs in the project dir with a timeout, bounded and secret-masked output. |
| analyze_check_failuresA | Parse test / lint / typecheck / build output into structured issues (file, line, code, message, priority), identify affected files, and return guidance for producing a corrective patch. Read-only. |
| fix_loopA | Run a controlled verify→analyze→fix loop. Each iteration runs the project checks; on failure it analyzes errors and, when the client supports MCP sampling, requests corrective edits and applies them (if allowApply=true), then re-checks — up to maxIterations. Every action taken is reported. When sampling is unavailable it returns a precise advisory so the calling assistant can drive the loop. |
| git_statusA | Report the Git state: current branch, staged/modified/untracked files, last commit, and whether the working tree is clean. Read-only. |
| summarize_changesA | Produce a clean summary of changes: a user-facing summary, a technical summary, a suggested conventional-commit message, the checks performed, and known limitations. Uses the current git diff when none is supplied. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct stage of the development workflow: inspection, reading relevant files, planning, patch generation, patch application, running checks, analysis, automated fixing, git status, and summarization. Even the similar tools like inspect_project and read_relevant_files are cleanly separated by content vs. structure, and generate_patch vs. apply_patch are clearly distinguished as generate vs. apply.
Most tool names follow a consistent verb_noun pattern (inspect_project, read_relevant_files, create_change_plan, generate_patch, apply_patch, run_project_checks, analyze_check_failures, fix_loop, summarize_changes). The only exception is git_status, which uses a noun phrase rather than an imperative verb, slightly breaking the pattern.
With 10 tools, the server is within the ideal 3-15 range. Each tool has a clear and non-redundant role, covering the full lifecycle from initial inspection through planning, editing, verification, iteration, and summarization without unnecessary overlap.
The tool surface covers the core development workflow comprehensively: read-only exploration, planning, patch creation and application, running checks, analyzing failures, an automated fix loop, git status, and change summarization. The main gap is the lack of an explicit rollback or revert tool, though apply_patch does back up files, and a commit tool is intentionally absent since committing is a separate concern.