Monitors Git repository state, providing real-time metrics, security scanning, and semantic search of commit history.
Uses OpenAI's API for smart intent verification, aligning code diffs with ticket descriptions.
Provides OpenTelemetry tracing for observability of MCP server operations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FlowCheck MCP Server check my branch for git hygiene and security issues"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🛡️ Production-Grade Safety Layer for AI-First Development
Git hygiene monitoring + Security scanning + Semantic search + Full observability
AI coding assistants are incredibly productive—but they can also create massive, hard-to-review changesets and security risks. FlowCheck is a production-grade safety layer that:
🔍 Monitors Git state in real-time during AI-assisted coding
🔒 Scans for security issues (PII, secrets, prompt injection attacks)
🔎 Semantic history search - find commits by meaning, not keywords
📊 Tracks flow health (time, lines, branch age, drift from main)
📝 Full observability (OpenTelemetry traces, audit logs)
🎯 Intent validation (ticket-to-diff alignment)
🤖 Designed for AI agents with enforceable rules
Think of FlowCheck as a "smart fitness watch with a biometric lock" for your codebase—it helps you code faster while actively defending against security threats.
Related MCP server: Hivelore
FlowCheck is built specifically for the agentic coding workflow:
flowchart LR
Agent["🤖 AI Agent<br/>(Claude, Cursor, etc)"]
FC["🛡️ FlowCheck<br/>MCP Server"]
Git["📁 Git Repo<br/>(.git)"]
Agent -->|"get_flow_state()"| FC
FC -->|"analyze"| Git
Git -->|"metrics"| FC
FC -->|"status: warning<br/>security_flags: [...]"| Agent
Agent -->|"⏸️ Pause & suggest<br/>checkpoint commit"| AgentCopy rules/flowcheck-rules.md to your AI tool's rules directory:
# For Cursor
cp rules/flowcheck-rules.md .cursor/rules/
# For Claude Projects
cp rules/flowcheck-rules.md .claude/rules/
# For other tools
cp rules/flowcheck-rules.md .agent/rules/This instructs AI agents to automatically check Git hygiene before starting tasks and to pause when thresholds are exceeded.
git clone https://github.com/backslash-ux/flowcheck.git
cd flowcheck
python3 -m venv .venv
source .venv/bin/activate
pip install -e .Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"flowcheck": {
"command": "/path/to/flowcheck/.venv/bin/python",
"args": ["-m", "flowcheck.server"],
"env": {
"PYTHONPATH": "/path/to/flowcheck/src"
}
}
}
}Tool | Purpose |
| Returns metrics + security_flags (PII/injection) |
| Returns actionable nudges + security warnings |
| Dynamically adjust thresholds |
Tool | Purpose |
| Semantic search - find commits by meaning |
| Smart Intent Verification - use "AI Judge" (BYOK LLM) to align diffs with tickets |
| PII/secret redaction before sharing with AI |
verify_intent (Smart Mode){
"alignment_score": 0.4,
"is_aligned": false,
"ticket_id": "42",
"scope_creep_warnings": ["Scope Creep Detected by AI Judge"],
"reasoning": "The ticket asks for a bug fix in auth, but the diff contains a full refactor of the billing module."
}FlowCheck supports hierarchical configuration:
Repo Config: .flowcheck.json (in project root)
Global Config: ~/.flowcheck/config.json
Defaults
.flowcheck.json Example{
"max_minutes_without_commit": 45,
"intent": {
"provider": "openai",
"model": "gpt-4o",
"api_key_env": "OPENAI_API_KEY"
}
}.flowcheckignore)Create a .flowcheckignore file in your repo root to exclude files from analysis (uses gitignore syntax):
tests/fixtures/
*.min.js
legacy/PII Detection: Emails, phone numbers, SSNs, credit cards
Secret Scanning: AWS keys, GitHub tokens, API keys, passwords
Injection Filtering: Detects prompt injection attacks in diffs
OpenTelemetry Traces: gen_ai.* semantic conventions
Audit Logs: Append-only JSON Lines format in ~/.flowcheck/audit.log
All tool invocations are logged with trace IDs
TF-IDF Vectorization: No external ML dependencies
SQLite Storage: Local index in ~/.flowcheck/semantic_index.db
Find commits by meaning, not just keywords
Get FlowCheck running in 30 seconds:
# Clone and setup
git clone https://github.com/backslash-ux/flowcheck.git
cd flowcheck
# Configure environment
cp .env.example .env
nano .env # Add your API keys
# Start the stack
docker-compose upFlowCheck is now running at http://localhost:8000
See Docker Deployment Guide for:
Local development setup
Production deployment
Image variants (production/slim/dev)
Troubleshooting
pip install git+https://github.com/backslash-ux/flowcheck.git
# Set environment variables
export ANTHROPIC_API_KEY=sk-ant-xxxxx
# Start server
flowcheck-servergit clone https://github.com/backslash-ux/flowcheck.git
cd flowcheck
# Create virtual environment
python3 -m venv .venv
source .venv/bin/activate
# Install in development mode
pip install -e ".[dev]"
# Run tests
pytest tests/
# Start server
flowcheck-serverFlowCheck supports multiple deployment models:
Scenario | Time | Guide |
Local Development | 5 min | |
Production (Docker) | 10 min | |
Kubernetes | 30 min | |
CI/CD Integration | 15 min |
👉 Deployment Guide for full options
# Setup development environment
docker-compose -f docker-compose.dev.yml up
# Or use Python venv
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
# Run tests
pytest tests/ -v
# Run with coverage
pytest tests/ --cov=src/flowcheckFlowCheck embodies the principle that good Git hygiene enables good AI collaboration:
Smaller commits are easier for humans to review and audit
Frequent checkpoints prevent losing work during long sessions
Clean history makes it easier to understand what the AI changed
Non-blocking nudges preserve developer autonomy
MIT
End the current FlowCheck session.
Call this at the end of a task to finalize audit records.
Returns: Dictionary with final session statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses ending the session and finalizing records, but does not cover prerequisites (e.g., session must exist) or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no waste. First sentence states purpose, second gives usage, third describes return.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completeness is high: explains purpose, usage timing, and return type. Output schema provides additional structure. Very minor gap on potential error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema, so baseline is 4. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'End the current FlowCheck session' with a specific verb and resource. It distinguishes from sibling tools like start_session and get_session_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this at the end of a task to finalize audit records,' providing clear when-to-use context. Lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current flow state metrics with security scanning.
Returns metrics about repository health including:
minutes_since_last_commit: Time elapsed since last commit
uncommitted_lines: Total lines changed
uncommitted_files: Number of modified files
branch_name: Current Git branch
status: Health indicator (ok, warning, danger)
security_flags: Any detected security issues
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | Path to the Git repository. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It describes the return metrics but does not explicitly state that the operation is read-only, nor does it disclose any potential side effects or authorization needs. It is adequate but lacks explicit safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence and a bullet list of return fields. Minor improvement could be made by tightening the list, but it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description's listing of return fields is not necessary but helpful. It covers the tool's purpose and outputs, though it omits error conditions or usage context. Fairly complete for a read-only tool with a single parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'repo_path' already described as 'Path to the Git repository.' The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'flow state metrics with security scanning.' It lists specific return fields, distinguishing it from siblings like get_recommendations or get_session_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only explains what it does, without mentioning context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get actionable recommendations with security awareness.
Analyzes repository and returns suggestions based on:
Commit frequency and change size thresholds
Branch age and main-branch synchronization
Security scan results
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | Path to the Git repository. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool analyzes a repository and returns suggestions based on specified criteria, indicating a read-like behavior. However, it does not state whether it modifies anything, requires permissions, or has side effects, leaving some behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line summary followed by a bullet list of analysis criteria. It has no unnecessary words and is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not detailed here but known), the description does not need to explain return values. It adequately covers the input and the analysis intent. However, it omits any mention of error conditions or prerequisites, which for a simple tool is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage (one parameter with a basic description). The description adds meaningful context by listing the analysis criteria (commit frequency, branch age, security scan), which clarifies how the repo_path parameter is used and what recommendations the tool generates beyond the schema's 'Path to the Git repository.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get actionable recommendations with security awareness.' It specifies the resource (repository) and lists analysis criteria (commit frequency, branch age, security scan), making the purpose distinct from sibling tools which focus on session management and other unrelated tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining recommendations based on repository analysis, but it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or sibling comparisons are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current session.
Returns session statistics including:
session_id: Unique session identifier
tool_calls: Number of tool calls in this session
duration_seconds: Session duration
Returns: Dictionary with session information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read-only operation but does not explicitly state side effects, auth requirements, or rate limits. The description of returns is adequate but lacks disclosure of behavioral traits like cost or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a bullet list. It front-loads the purpose and provides structured details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description provides complete context: it names the key fields returned and their semantics. No further information is needed for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds meaning by listing returned fields, which is sufficient since there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get information about the current session' and lists specific return fields, making the purpose explicit. However, it does not explicitly distinguish itself from sibling tools like get_flow_state, though the context suggests it's session metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives such as get_flow_state or end_session. The description only explains what it does, without context on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sanitize content by redacting secrets and PII.
Use this before including file contents in prompts or outputs. Replaces sensitive data with [REDACTED_TYPE] tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Text content to sanitize. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It reveals that sensitive data is replaced with '[REDACTED_TYPE]' tokens, though it doesn't explicitly state that the input is not modified. Still, the behavioral effect is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. Front-loaded with purpose, usage, and effect. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the existence of an output schema (not shown but indicated), the description is adequate. It could mention coverage or limitations of redaction, but it's sufficiently complete for a straightforward sanitizer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter ('content'), which already describes it as 'Text content to sanitize.' The description adds context about redacting secrets/PII but does not provide new parameter-level details, warranting baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('sanitize') and resource ('content'), and clearly indicates it redacts secrets and PII. This distinguishes it from sibling tools, none of which perform sanitization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this before including file contents in prompts or outputs.' It does not mention when not to use or alternatives, but given no competing sibling, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search commit history semantically.
Find commits by meaning rather than exact keyword matching. Example: "authentication changes" finds commits about OAuth, login, tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query. | |
| top_k | No | Maximum number of results (default: 5). | |
| repo_path | Yes | Path to the Git repository. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds semantic search behavior and example but fails to disclose limitations like indexing requirements, performance constraints, or how results are scored. Minimal behavioral context beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a helpful example, front-loading the key idea. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema covering return values. However, no additional context on behavior like indexing, performance, or edge cases. Adequate for a simple search tool but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds little beyond schema: 'natural language' for query, 'max results' for top_k, 'path' for repo_path. Provides example but no extra parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Search' and resource 'commit history', clearly distinguishes semantic search from keyword matching, and provides a concrete example. No confusion with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for semantic search but does not explicitly state when to use vs. siblings (none directly similar) or when not to use. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update FlowCheck configuration thresholds.
Supported parameters:
max_minutes_without_commit: Minutes before suggesting checkpoint (default: 60)
max_lines_uncommitted: Lines before suggesting split (default: 500)
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | Configuration values to update. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It does not disclose effects (e.g., whether changes are immediate, persistent, or impact current sessions). Only supported parameters and defaults are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for the action, then a bullet list of parameters. No filler, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or output description, the tool's behavioral context is incomplete. However, it adequately documents the config parameters. Missing details on return values or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a generic 'config' object. The description adds specific keys ('max_minutes_without_commit', 'max_lines_uncommitted') with defaults, providing meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates FlowCheck configuration thresholds, matching the name 'set_rules'. It distinguishes from siblings like 'end_session' or 'get_flow_state' which have unrelated purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when updating thresholds is appropriate or prerequisites like session state. The description only lists parameters without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new FlowCheck session for audit correlation.
Sessions help correlate tool calls across a task for auditing. Call this at the beginning of a task.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | Optional identifier for the agent (e.g., "claude", "cursor"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains that sessions help correlate tool calls for auditing, which adds behavioral context. However, it does not disclose any side effects, state changes, or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences, front-loading the core action. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description fully covers what the tool does, why it's used, and when to call it. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one optional parameter 'agent_id' already described. The description does not add any additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'start' and the resource 'FlowCheck session' with a specific purpose 'for audit correlation'. It distinguishes from sibling tools like 'end_session' and 'get_session_info' by indicating when to call it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage guidance: 'Call this at the beginning of a task.' This tells the agent when to use it, but does not explicitly mention when not to use alternatives or describe constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate current work against ticket requirements.
Checks if code changes align with the stated ticket/task. Flags scope creep using GitHub Issues integration.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional description of current changes. | |
| repo_path | Yes | Path to the local repository. | |
| ticket_id | Yes | The issue ID or ticket ID (e.g., "42"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses validation logic, scope creep flagging, and integration with GitHub Issues. However, it doesn't detail what happens on failure or whether it modifies any state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and schema coverage is 100%, the description is mostly complete. It could mention prerequisites (e.g., ticket must exist in GitHub Issues) but is adequate for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not add meaning beyond what the schema provides (e.g., ticket_id, repo_path, context). No extra parameter guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool validates work against ticket requirements, checks code alignment, and flags scope creep using GitHub Issues. This is a specific verb+resource action that distinguishes it from sibling tools like 'end_session' or 'search_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use during development or review but does not explicitly state when to use or not use this tool, nor does it mention alternatives. Usage context is implied but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.0end_sessionget_flow_stateget_recommendationsget_session_infosanitize_contentsearch_historyset_rulesstart_sessionverify_intentAll nine tools target distinct actions: session lifecycle (start/end), state retrieval, recommendations, history search, content sanitization, configuration, and intent verification. Even related tools like get_flow_state and get_recommendations are clearly differentiated by their outputs and purposes.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., start_session, get_flow_state, sanitize_content). No mixing of naming conventions or vague verbs are present.
Nine tools is an appropriate number for the server's purpose of managing flow sessions, scanning, and recommendations. Each tool serves a well-defined role without redundancy or excessive granularity.
The tool set covers the essential workflows: session management, state metrics, recommendations, history search, content sanitization, configuration, and intent verification. A minor gap is the lack of a tool to list or manage past sessions, but the core functionality is well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Production-readiness for your AI coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/backslash-ux/flowcheck'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
