Vibe Check MCP
🧠 バイブチェックMCP
Vibecheck は、 mcpservers.org 、 Glama.ai 、 mcp.soでも見つかります。
AI が自分でアヒルの姿になれないときの AI 内部のアヒルの姿。
バイブチェックとは何ですか?
「バイブコーディング」の時代では、AI エージェントは驚異的な能力を備えていますが、問題は次のようになります。
から
「私の AI エージェントは本当にこの複雑なタスクを実行できるのでしょうか?」
に
「私の AI エージェントは、私が数十億ドル規模のテクノロジー企業向けのインフラストラクチャではなく、単純なプログラムを書きたいのだということを理解できるでしょうか?」
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 は、次の 3 つの統合ツールを使用して、エージェントのワークフローにメタ認知レイヤーを追加します。
🛑 バイブチェック
メタ認知的質問によってトンネルビジョンを打破するパターン中断メカニズム:
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({
"plan": "...", // Detailed plan to simplify
"userRequest": "..." // FULL original user request
})🔄バイブラーン
時間の経過とともにパターン認識を構築する自己改善フィードバック ループ:
vibe_learn({
"mistake": "...", // One-sentence description of mistake
"category": "...", // From standard categories
"solution": "..." // How it was corrected
})バイブチェックの実践
バイブチェック前:

クロードはMCPの意味が曖昧であるにもかかわらずそれを前提としており、その後のすべてのステップでこの誤った前提が採用されることになる。
バイブチェック後:

バイブチェックMCPが呼び出され、曖昧さを指摘し、クロードはこの情報不足を認め、積極的に対処することを余儀なくされました。
インストールとセットアップ
Smithery経由でインストール
Smithery経由で Claude Desktop 用の vibe-check-mcp-server を自動的にインストールするには:
npx -y @smithery/cli install @PV-Bhat/vibe-check-mcp-server --client claudenpm による手動インストール (推奨)
# 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各ツールをいつ使用するか
道具 | いつ使うか |
🛑バイブチェック | エージェントがToDoアプリのブロックチェーンの基礎を説明し始めたら |
⚓バイブ・ディスティル | エージェントのプランに、技術仕様全体よりも多くの箇条書きが含まれている場合 |
🔄バイブラーン | エージェントを手動で複雑性の深淵から戻した後 |
APIリファレンス
完全な API ドキュメントについては、テクニカル リファレンスを参照してください。
建築
Vibe Checkは、再帰的監視原理に基づく二層メタ認知アーキテクチャを実装しています。主な知見:
パターン慣性抵抗: LLM エージェントは、推論パスにおいて自然に運動量のような特性を示し、方向転換するには外部介入が必要です。
位相共鳴中断: メタ認知質問は、是正効果を最大限に高めるために、エージェントの現在のフェーズ (計画/実装/レビュー) と一致する必要があります。
権限構造の統合: エージェントは、外部のメタ認知フィードバックをオプションの提案ではなく、優先度の高い割り込みとして扱うように明示的に指示される必要があります。
アンカー圧縮メカニズム: 複雑な推論フローを最小限のアンカー チェーンに凝縮して、効果的な再調整ポイントとして機能する必要があります。
再帰フィードバック ループ: 観察されたすべてのミスステップを保存し、活用して、中断の有効性を向上させる長期的な障害モデルを構築する必要があります。
基礎となる設計原則の詳細については、 「哲学」を参照してください。
バイブチェックの実践(続き)




ドキュメント
書類 | 説明 |
エージェント統合の詳細なテクニック | |
フィードバック連鎖、信頼度レベルなど | |
完全なAPIドキュメント | |
Vibe Checkの背後にあるAIアライメントの原理 | |
Vibe Check の実際の使用例 |
貢献
Vibe Check への貢献を歓迎します。バグ修正、機能追加、ドキュメントの改善など、まずは貢献ガイドラインをご覧ください。
ライセンス
Available Tools
2 toolsvibe_checkB
Metacognitive questioning tool that identifies assumptions and breaks tunnel vision to prevent cascading errors
| 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
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.
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.
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.
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.
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.
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
| 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
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.
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.
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.
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.
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.
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
Scored across 2 tools
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.
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.
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.
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
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
- AlicenseAqualityBmaintenanceA 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.912 npm9MIT
- 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