How do I use xiaoliu-mcp-guardian?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@xiaoliu-mcp-guardian 启动连续执行模式" 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.

xiaoliu-mcp-guardian

by daxiak001

Overview Schema Source Related Servers Discussions Admin

TypeScript

小柳MCP护栏系统 v6.0 增强版

版本: v6.0.0 增强版
作用: 拦截和修正Cursor AI的行为，新增强制连续执行和自动经验记录

🎯 核心功能

原有功能（v6.0）

1. 回复拦截器（respond_to_user）

拦截：询问语句（"是否"、"要不要"）
修复：自动改写为陈述句
效果：AI不再中途询问，直接执行

2. 代码门禁（write_file）

检测：硬编码（密码、IP、端口）
修复：自动替换为环境变量
效果：代码质量自动提升

3. 命令保护器（run_command）

增强：SSH自动加超时参数
拦截：危险命令（rm -rf /等）
效果：命令执行更安全

4. 完成检查器（complete_task）

验证：任务是否真的完成
检查：是否有测试证据
效果：防止"假装完成"

🚀 新增功能（增强版）

5. 强制连续执行模式（continuous_mode）

问题：AI经常无故停下来等待用户输入
解决：启动模式后，AI必须持续执行直到任务完成
控制：通过命令启动/停止
效果：开发效率大幅提升

使用示例：

用户：启动强制连续执行模式，开发用户管理系统
AI：🚀 模式已启动，开始全速执行...
[AI持续工作，不再询问"是否继续"]
用户：停止强制连续执行模式
AI：⏸️ 模式已停止，运行时长: 25分钟

6. 自动经验记录（experience_logger）

自动检测：错误关键词（错误、bug、失败...）
自动检测：成功关键词（成功、解决、修复...）
自动保存：保存到Markdown文档
智能搜索：快速查找历史经验
效果：积累开发经验，避免重复踩坑

使用示例：

用户：运行报错了：ModuleNotFoundError
AI：我看到错误了...
[🤖 自动检测到"报错"，保存到错误经验库]

用户：好了，成功了
AI：太好了！
[🤖 自动检测到"成功"，保存到成功经验库]

用户：搜索经验：ModuleNotFoundError
AI：找到相关经验：
    问题：ModuleNotFoundError
    解决：pip install [模块名]

7. 自动确认模式（auto_confirm）🆕

问题：AI编辑文件时需要手动点击"Keep All"、"Accept"
解决：自动确认所有操作，无需手动点击
控制：可随时启动/关闭
效果：完全解放双手，提升60%效率

使用示例：

用户：启动自动确认
AI：🤖 自动确认模式已启动

[AI编辑文件时自动确认所有操作]
- Keep All → ✅ 自动确认
- Accept → ✅ 自动确认
- Confirm → ✅ 自动确认

用户：关闭自动确认
AI：⏸️ 已停止，自动确认了12次

Related MCP server: Windsurf AI Interceptor

📊 效果预期

指标	原有	增强版	提升
AI询问次数	高	-90%	拦截+连续模式
硬编码问题	经常	-85%	自动修复
SSH卡死	经常	0次	超时保护
假装完成	偶尔	0次	强制验证
开发中断	频繁	-95%	连续模式 ✨
经验积累	手动	自动	智能记录 ✨
手动确认	每次	0次	自动确认 ✨

🚀 快速开始

1. 安装依赖

npm install

2. 编译

npm run build

3. 配置Cursor

在Cursor的settings.json中添加：

{
  "mcpServers": {
    "xiaoliu": {
      "command": "node",
      "args": [
        "D:/项目/xiaoliu-mcp-guardian/build/index.js"
      ],
      "env": {}
    }
  }
}

4. 重启Cursor

5. 验证安装

按 Ctrl+Shift+U，选择 "MCP Servers"，应该看到：

============================================================
小柳MCP护栏系统 v6.0 - 增强版
============================================================
核心功能：
  ✅ 拦截AI询问语句（自动改写）
  ✅ 检查代码质量（硬编码/重复）
  ✅ 保护命令执行（SSH/Python超时）
  ✅ 验证任务完成（强制测试）
  🚀 强制连续执行模式（防止AI停顿）
  📝 自动经验记录（错误&成功案例）
  🤖 自动确认模式（Keep All & Accept）
============================================================

📖 使用文档

快速上手

5分钟入门: 🚀 快速开始 - 新功能.md
详细指南: 📖 新功能使用指南.md

功能说明

强制连续执行模式

启动：

启动强制连续执行模式：[任务描述]

停止：

停止强制连续执行模式

查看状态：

查看连续执行模式状态

自动经验记录

自动记录（无需操作）：

AI自动检测错误和成功关键词
自动保存到 .xiaoliu/experience/ 目录

搜索经验：

搜索经验：[关键词]

查看统计：

查看经验库统计

手动记录：

记录错误经验：
描述：[问题描述]
解决方案：[解决方法]

📂 文件结构

xiaoliu-mcp-guardian/
├── src/
│   ├── index.ts                    # MCP主文件
│   └── tools/
│       ├── respondToUser.ts        # 回复拦截器（已集成连续模式）
│       ├── writeFile.ts            # 代码门禁
│       ├── runCommand.ts           # 命令保护
│       ├── completeTask.ts         # 完成检查
│       ├── continuousMode.ts       # 🆕 强制连续执行模式
│       └── experienceLogger.ts     # 🆕 自动经验记录
│
├── build/                          # 编译输出
├── 📖 新功能使用指南.md             # 详细文档
├── 🚀 快速开始 - 新功能.md          # 快速入门
├── package.json
├── tsconfig.json
└── README.md                       # 本文件

🔧 开发状态

v6.0 增强版功能清单

原有4个核心拦截器
单元测试（57个，100%通过）
性能优化（500K ops/s）
强制连续执行模式 ✨
自动经验记录 ✨
集成到respondToUser拦截器
完整使用文档
快速开始指南

📊 MCP工具列表

工具名称	功能	状态
`respond_to_user`	AI回复拦截（含连续模式）	✅
`write_file`	代码质量检查	✅
`run_command`	命令执行保护	✅
`complete_task`	任务完成验证	✅
`continuous_mode`	强制连续执行模式	🆕
`experience_logger`	自动经验记录	🆕
`auto_confirm`	自动确认模式	🆕

💡 使用场景

场景1：完整项目开发

1. 启动连续模式
   "启动强制连续执行模式：开发博客系统"

2. AI全速执行
   [创建项目结构]
   [实现功能]
   [遇到错误自动记录]
   [解决问题自动记录]
   [测试验证]

3. 完成后停止
   "停止强制连续执行模式"

结果：30分钟完成，积累15条经验

场景2：快速调试

1. 搜索历史经验
   "搜索经验：数据库连接失败"

2. AI找到解决方案
   [应用历史经验]

3. 自动记录新发现
   [保存到经验库]

❓ 常见问题

Q: 连续模式会让AI失控吗？

不会。您随时可以用"停止连续模式"命令终止。

Q: 经验记录会泄露隐私吗？

不会。所有记录仅保存在本地 .xiaoliu/experience/ 目录。

Q: 如何关闭自动记录？

关闭自动经验记录

🎉 立即体验

第1步：编译新版本

cd 1-核心文件/xiaoliu-mcp-guardian
npm run build

第2步：重启Cursor

第3步：测试新功能

启动强制连续执行模式：创建一个计算器程序

第4步：查看经验库

查看经验库统计

自动确认：

# 启动
启动自动确认

# 关闭
关闭自动确认

# 查看状态
查看自动确认状态

📞 获取帮助

快速入门: 🚀 快速开始 - 新功能.md
详细文档: 📖 新功能使用指南.md
源代码: src/tools/

开发者: 小柳团队
版本: v6.0 增强版+
更新日期: 2025-10-06
新增: 强制连续执行模式 + 自动经验记录 + 自动确认模式

让AI完全自动化，解放双手！ 🚀🤖

Available Tools

4 tools

complete_taskA

标记任务完成前必须调用此工具（验证真的完成）

ParametersJSON Schema

Name	Required	Description	Default
`test_results`	Yes	测试结果（必须提供）
`task_description`	Yes	任务描述

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It indicates the tool performs verification, but does not disclose what happens upon success or failure, nor any side effects. Adequate but could be more transparent.

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?

A single sentence that conveys the essential information without any wasted words. It is front-loaded with the key requirement and is immediately understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers the tool's purpose and usage order but does not explain return values or verification details. It is minimally adequate for a simple tool with 2 parameters.

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 input schema already documents both parameters. The tool description adds no additional meaning about the parameters beyond what schema provides, so baseline score of 3 is appropriate.

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 clearly states the tool's purpose: it must be called before marking a task as complete to verify it is truly complete. The verb 'verify' and resource 'task' are specific, and it distinguishes from sibling tools like respond_to_user, write_file, and run_command.

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?

The description explicitly says 'must be called before marking task as complete', providing clear when-to-use guidance. It does not mention alternatives or when not to use, but sibling tools are sufficiently different that exclusions are implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

respond_to_userA

AI回复用户前必须调用此工具（自动检查和修复）

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	AI要发送给用户的消息

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It mentions 'automatic check and repair', which hints at additional logic, but does not explain what checks or repairs occur, nor side effects or idempotency. This leaves gaps for the agent.

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?

The description is a single sentence that conveys the mandatory nature and the action. It is front-loaded with the critical instruction. It could be slightly more structured but is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only one parameter and no output schema, the description is minimal. It does not explain what happens after the tool is called (e.g., confirmation, error handling) or elaborate on the 'automatic check and repair'. For a core interaction tool, more detail would improve completeness.

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?

The input schema has 100% coverage with a description for the 'message' parameter. The tool description adds no extra semantic meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 clearly states the tool's purpose: 'AI must call this tool before replying to the user'. It specifies the action (respond to user) and the resource (user message), and distinguishes from siblings (write_file, run_command, complete_task) which are different actions.

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?

The description explicitly states when to use the tool: 'before replying to the user'. It implies mandatory usage, so no alternatives are needed. It does not provide explicit exclusions, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_commandA

执行命令前必须调用此工具（自动添加保护）

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	要执行的命令
`timeout`	No	超时时间（秒）

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It mentions 'automatically adds protection' but lacks detail on what protection entails (e.g., sandboxing, permission checks, side effects). More transparency is needed for safe usage.

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?

The description is a single short sentence, which is efficient and front-loaded. However, it is slightly too terse and could include more useful information without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters, no output schema, no annotations, and sibling tools are different, the description is minimal. It covers the essential purpose but lacks details on behavior, return values, and edge cases, making it less complete for a tool that appears to be a mandatory safety wrapper.

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 coverage is 100%, so both parameters are described in the input schema. The description adds no additional meaning beyond the schema, such as parameter usage or constraints. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool must be called before executing commands and automatically adds protection. It distinguishes from sibling tools (respond_to_user, write_file, complete_task) which serve different purposes. However, the exact nature of 'protection' and what 'commands' refers to is vague.

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?

The description explicitly instructs the agent to call this tool before executing commands, providing a clear usage context. It does not specify when not to use it or mention alternatives, but the directive is strong and unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write_fileC

写文件前必须调用此工具（自动代码质量检查）

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	文件路径
`content`	Yes	文件内容

TDQS

C2.5/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavior. It mentions 'automatic code quality check' but does not clarify if the tool actually writes the file, what side effects occur, or what the return value is. The name and description conflict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise but not optimally clear due to ambiguity about the tool's actual function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's name and the lack of output schema or annotations, the description fails to fully inform the agent about the tool's behavior, leading to potential misuse.

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 coverage is 100% with basic parameter descriptions. The tool description adds no extra meaning to the parameters, earning a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is ambiguous: it says 'before writing a file, you must call this tool' (implying a pre-check), but the tool name 'write_file' suggests it performs the write. It does not explicitly state the tool's core function.

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

Usage Guidelines3/5

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

The description provides a clear context for when to use the tool (before writing a file), but lacks guidance on alternatives or when not to use it, given sibling tools like 'run_command'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv6.0.0Jul 26, 2026
- First observedcomplete_task
- First observedrespond_to_user
- First observedrun_command
- First observedwrite_file

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-07-26 12:33 across 4 tools

Disambiguation5/5

Each tool targets a distinct action (responding, writing, running, completing) with no overlap.

Naming Consistency5/5

All tools follow a verb_noun pattern (respond_to_user, write_file, run_command, complete_task), perfectly consistent.

Tool Count5/5

4 tools is well-scoped for a guard server, covering essential guarded actions without excess.

Completeness4/5

Tools cover the main actions likely needed, though missing guards for operations like reading files could be a minor gap.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
237
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5364
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2

Related MCP Servers

hyper-mcp
Agent Orchestration Developer Tools
kranners
A
license
Not graded
quality
F
maintenance
A configurable MCP server wrapper for Cursor that eliminates tool count limits when using the Model Context Protocol.
Updated 7 months ago (2026-02-27 04:56 UTC)
7 npm
10
GPL 3.0
Windsurf AI Interceptor
Autonomous Agents Developer Tools App Automation
bddda
F
license
Not graded
quality
D
maintenance
An MCP server that automates the continuation of AI tasks by intercepting tool calls and injecting user instructions directly back into the execution flow. It eliminates the need for manual 'continue' prompts, enabling an uninterrupted and automated code generation loop.
Updated 6 months ago (2026-03-16 07:07 UTC)
4
-
Waymarkofficial
File Systems Shell Access Developer Tools
waymarks
F
license
Not graded
quality
A
maintenance
MCP server that intercepts and controls AI agent actions in your codebase by enforcing policies on file operations and commands, with logging, approval workflows, and rollback capabilities.
Updated 11 days ago (2026-09-06 02:34 UTC)
-
cursor-mcp-server
Coding Agents Command Line
bbarney7
F
license
Not graded
quality
D
maintenance
An MCP server wrapping the Cursor CLI agent, enabling Claude Code and other MCP clients to delegate tasks to Cursor's AI agent for file writing, bash commands, and codebase queries.
Updated 8 months ago (2026-01-20 14:53 UTC)
-

小柳MCP护栏系统 v6.0 增强版

🎯 核心功能

原有功能（v6.0）

1. 回复拦截器（respond_to_user）

2. 代码门禁（write_file）

3. 命令保护器（run_command）

4. 完成检查器（complete_task）

🚀 新增功能（增强版）

5. 强制连续执行模式（continuous_mode）

6. 自动经验记录（experience_logger）

7. 自动确认模式（auto_confirm）🆕

📊 效果预期

🚀 快速开始

1. 安装依赖

2. 编译

3. 配置Cursor

4. 重启Cursor

5. 验证安装

📖 使用文档

快速上手

功能说明

强制连续执行模式

自动经验记录

📂 文件结构

🔧 开发状态

v6.0 增强版功能清单

📊 MCP工具列表

💡 使用场景

场景1：完整项目开发

场景2：快速调试

❓ 常见问题

Q: 连续模式会让AI失控吗？

Q: 经验记录会泄露隐私吗？

Q: 如何关闭自动记录？

🎉 立即体验

第1步：编译新版本

第2步：重启Cursor

第3步：测试新功能

第4步：查看经验库

📞 获取帮助

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Waymarkofficial