A
licenseA
qualityB
maintenanceA Model Context Protocol server that empowers AI agents with metacognitive monitoring to detect reasoning loops and provide intelligent recovery using case-based reasoning and statistical analysis.
9
12 npm
9
MIT
Vibe Check MCP
by PV-Bhat
🧠 Vibe 检查 MCP
还可以在以下网站找到 Vibecheck： mcpservers.org 、 Glama.ai 、 mcp.so
当你的 AI 无法自己做橡皮鸭时，它的内部就是橡皮鸭。
什么是 Vibe Check？
在**“氛围编码”**时代，人工智能代理现在拥有令人难以置信的能力，但问题已经发生了变化：
从
“我的人工智能代理真的能完成这个复杂的任务吗？”
到
“我的人工智能代理能否理解我想编写一个简单的程序，而不是为一家价值数十亿美元的科技公司编写基础设施？”
它提供了 AI 代理目前所不具备的“等等……这不是它”的关键时刻：一个内置的自我修正监督层。它是 Vibe Coder 的权威健全性检查 MCP 服务器：
通过实施战略模式中断来防止 AI 工作流程中的级联错误。
使用 LearnLM 1.5 Pro（Gemini API）的工具“Vibe Check”，针对教学法和元认知进行微调，以增强复杂的工作流程策略，并防止出现隧道视觉错误。
实施“Vibe Distill”以鼓励计划简化，防止过度设计解决方案，并最大限度地减少代理中的上下文漂移。
自我改进的反馈循环：代理可以将错误记录到“Vibe Learn”中，以提高语义回忆能力，并帮助监督 AI 随着时间的推移瞄准模式。
TLDR；实施一个经过微调的代理，以停止您的代理并让其在自信地实施错误操作之前重新考虑。
Related MCP server: Visum Thinker MCP Server
问题：模式惯性
在氛围编码运动中，我们都在使用 LLM 来生成、重构和调试代码。但这些模型有一个关键缺陷：一旦它们开始推理，即使这条路径明显错误，它们也会继续下去。
You: "Parse this CSV file"
AI: "First, let's implement a custom lexer/parser combination that can handle arbitrary
CSV dialects with an extensible architecture for future file formats..."
You: *stares at 200 lines of code when you just needed to read 10 rows*这种模式惯性导致：
🔄隧道视野：你的代理陷入一种方法，无法看到其他选择
📈范围蔓延：简单的任务逐渐演变为企业级解决方案
🔌过度设计：向不需要的问题添加抽象层
❓错位：解决与你要求的问题相邻但不同的问题
特点：元认知监督工具
Vibe Check 通过三个集成工具为您的代理工作流程添加了元认知层：
🛑 vibe_check
通过元认知提问打破隧道视野的模式中断机制：
vibe_check({
"phase": "planning", // planning, implementation, or review
"userRequest": "...", // FULL original user request
"plan": "...", // Current plan or thinking
"confidence": 0.7 // Optional: 0-1 confidence level
})⚓ vibe_distill
重新校准复杂工作流程的元思维锚点：
vibe_distill({
"plan": "...", // Detailed plan to simplify
"userRequest": "..." // FULL original user request
})🔄 vibe_learn
随着时间的推移建立模式识别的自我改进反馈循环：
vibe_learn({
"mistake": "...", // One-sentence description of mistake
"category": "...", // From standard categories
"solution": "..." // How it was corrected
})氛围检查正在进行中
氛围检查之前：
尽管存在歧义，Claude 仍然假设 MCP 的含义，导致所有后续步骤都存在这个错误的假设
氛围检查后：
Vibe Check MCP 被调用，并指出了模糊性，这迫使 Claude 承认缺乏信息并主动解决它
安装和设置
通过 Smithery 安装
要通过Smithery自动为 Claude Desktop 安装 vibe-check-mcp-server：
npx -y @smithery/cli install @PV-Bhat/vibe-check-mcp-server --client claude通过 npm 手动安装（推荐）
# Clone the repo
git clone https://github.com/PV-Bhat/vibe-check-mcp-server.git
cd vibe-check-mcp-server
# Install dependencies
npm install
# Build the project
npm run build
# Start the server
npm run start与克劳德的整合
添加到您的claude_desktop_config.json ：
"vibe-check": {
"command": "node",
"args": [
"/path/to/vibe-check-mcp/build/index.js"
],
"env": {
"GEMINI_API_KEY": "YOUR_GEMINI_API_KEY"
}
}环境配置
在项目根目录中创建一个.env文件：
GEMINI_API_KEY=your_gemini_api_key_here代理提示指南
为了有效进行模式中断，请在系统提示中包含以下说明：
As an autonomous agent, you will:
1. Treat vibe_check as a critical pattern interrupt mechanism
2. ALWAYS include the complete user request with each call
3. Specify the current phase (planning/implementation/review)
4. Use vibe_distill as a recalibration anchor when complexity increases
5. Build the feedback loop with vibe_learn to record resolved issues何时使用每个工具
工具 | 何时使用 |
🛑 vibe_check | 当你的代理开始为待办事项应用程序解释区块链基础知识时 |
⚓ vibe_distill | 当你的代理人的计划包含的嵌套要点比你的整个技术规范还多时 |
🔄 vibe_learn | 在你手动引导你的代理脱离复杂性深渊之后 |
API 参考
请参阅技术参考以获取完整的 API 文档。
建筑学
Vibe Check 实现了基于递归监督原则的双层元认知架构。关键见解：
模式惯性阻力：LLM 代理在其推理路径中自然表现出类似动量的属性，需要外部干预来重定向。
相位共振中断：元认知提问必须与代理的当前阶段（计划/实施/审查）保持一致，以实现最大的纠正影响。
权威结构整合：必须明确提示代理将外部元认知反馈视为高优先级中断而不是可选建议。
锚压缩机制：复杂的推理流必须提炼为最小的锚链，以作为有效的重新校准点。
递归反馈循环：必须存储并利用所有观察到的失误来构建纵向故障模型，以提高中断效率。
有关底层设计原则的更多详细信息，请参阅哲学。
氛围检查实际操作（续）
文档
贡献
欢迎为 Vibe Check 贡献代码！无论是修复错误、添加功能，还是改进文档，都可以查看我们的贡献指南开始使用。
执照
Available Tools
2 toolsvibe_checkB
Metacognitive questioning tool that identifies assumptions and breaks tunnel vision to prevent cascading errors
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | The agent's current goal | |
| modelOverride | No | ||
| plan | Yes | The agent's detailed plan | |
| progress | No | The agent's progress so far | |
| sessionId | No | Optional session ID for state management | |
| taskContext | No | The context of the current task | |
| uncertainties | No | The agent's uncertainties | |
| userPrompt | No | The original user prompt |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool's cognitive effects (identifying assumptions, breaking tunnel vision, preventing errors) but lacks details on how it operates (e.g., does it generate questions, provide feedback, modify plans?), what it returns, or any constraints like rate limits or permissions. This leaves significant gaps in understanding its behavior.
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?
The description is a single, efficient sentence that front-loads the key purpose ('metacognitive questioning tool') and elaborates with clear outcomes. Every word earns its place, avoiding redundancy or fluff, making it highly concise and well-structured for quick understanding.
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 complexity (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how it uses the parameters (e.g., 'modelOverride' for AI model selection), or behavioral details like state management with 'sessionId.' For a metacognitive tool with rich inputs, more context is needed to guide effective use.
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 schema description coverage is high (88%), so the schema already documents most parameters well (e.g., 'goal,' 'plan,' 'uncertainties'). The description doesn't add specific meaning beyond the schema, such as explaining how parameters like 'modelOverride' or 'sessionId' relate to the tool's purpose. Baseline 3 is appropriate as the schema does the heavy lifting, but no extra value is provided.
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 the tool's purpose as a 'metacognitive questioning tool' that 'identifies assumptions and breaks tunnel vision to prevent cascading errors.' It uses specific verbs ('identifies,' 'breaks,' 'prevent') and describes the cognitive function, though it doesn't explicitly differentiate from its sibling 'vibe_learn' beyond the general domain of 'vibe' tools.
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 implies usage in scenarios involving assumptions, tunnel vision, or error prevention, suggesting it's for reflective or corrective moments. However, it doesn't provide explicit guidance on when to use this tool versus 'vibe_learn' or other alternatives, nor does it specify prerequisites or exclusions, leaving the context somewhat open-ended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vibe_learnC
Pattern recognition system that tracks common errors and solutions to prevent recurring issues
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category (standard categories: Complex Solution Bias, Feature Creep, Premature Implementation, Misalignment, Overtooling, Preference, Success, Other) | |
| mistake | Yes | One-sentence description of the learning entry | |
| sessionId | No | Optional session ID for state management | |
| solution | No | How it was corrected (if applicable) | |
| type | No | Type of learning entry |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions tracking and prevention but fails to detail critical aspects like whether this is a read/write operation, data persistence, permissions needed, or error handling. This leaves significant gaps for a tool with 5 parameters and potential data mutation.
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?
The description is a single, efficient sentence that directly states the tool's purpose without redundancy or unnecessary details. It is front-loaded and appropriately sized for its informational content.
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 complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, output expectations, and differentiation from siblings, making it inadequate for guiding an agent in practical use beyond a high-level purpose.
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 schema description coverage is 100%, providing clear documentation for all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 without compensating or enhancing the schema's information.
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 the tool's purpose as a 'pattern recognition system that tracks common errors and solutions to prevent recurring issues,' which specifies the verb (tracks) and resource (errors/solutions). However, it doesn't explicitly differentiate from its sibling 'vibe_check,' leaving room for ambiguity about their distinct roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, including its sibling 'vibe_check.' It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on the purpose alone.
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.
2 tool updates
v1.0.0- First observed
vibe_check - First observed
vibe_learn
TDQS
B3.3/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: vibe_check focuses on metacognitive questioning to prevent immediate errors by identifying assumptions, while vibe_learn focuses on pattern recognition to prevent recurring issues by tracking errors and solutions. There is no overlap or ambiguity between them.
Naming Consistency5/5
Both tools follow a consistent 'vibe_' prefix pattern with descriptive suffixes (check and learn), making them predictable and readable. The naming style is uniform throughout the set.
Tool Count3/5
With only 2 tools, the set feels thin for a server named 'Vibe Check MCP', which suggests a broader scope for metacognitive or error-prevention functionality. While the tools are well-defined, the count is borderline low for typical MCP server purposes.
Completeness3/5
The tools cover two key aspects of error prevention (immediate and recurring), but there are notable gaps such as tools for applying learned patterns, adjusting strategies based on feedback, or integrating with external systems. The surface is functional but not fully comprehensive for the inferred domain.
Maintenance
ActivitySlowing
ResponsivenessSlow
Related MCP Connectors
Adversarial behavioural-bias engine — audits your decisions for cognitive biases via your own AI.
Patterns for designing and reviewing AI skills, agents, and multi-agent workflows. Find guidance on context economy, delegation, verification, and tool design; inspect claims, worked examples, maturity labels, and source references. Five read-only tools let agents discover relevant patterns, compare concise cards, read specific sections, and explore relationships. Hosted Streamable HTTP at https://agentic-atlas.dev/mcp/ — no installation, account, or API key required. Browse the atlas at https://agentic-atlas.dev/.
Goal and task planning MCP for Codex and AI agents, with evidence-backed completion.
A governed, nonclinical reasoning system that helps people and AI agents make sense of difficult moments and choose a grounded next step. Use Clarity OS for overthinking, emotional activation, uncertainty, decision friction, conflicting priorities, repeating patterns, or difficult conversations. It returns structured, safety-governed clarity while preserving uncertainty, personal agency, and appropriate nonclinical boundaries.
Related MCP Servers
- AlicenseBqualityNot gradedmaintenanceProvides structured sequential thinking capabilities for AI assistants to break down complex problems into manageable steps, revise thoughts, and explore alternative reasoning paths.29-
- AlicenseNot gradedqualityDmaintenanceProvides structured thinking tools including mental models, design patterns, debugging approaches, decision frameworks, and multi-persona reasoning to enhance AI assistant problem-solving capabilities.7 npmMIT
- AlicenseNot gradedqualityDmaintenanceProvides a 'reflect' tool that creates cognitive checkpoints for AI assistants, forcing structured step-by-step reasoning through complex problems to improve accuracy and maintain context during task execution.4 npm6MIT