Skip to main content
Glama
deenesjakoruzh
PV-Bhat

Vibe Check MCP

by PV-Bhat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

🧠 Проверка вибрации MCP

Версия Лицензия Статус моделизначок кузнеца Vibe Check MCP-сервер

Также ищите Vibecheck на: mcpservers.org , Glama.ai , mcp.so

Внутренний резиновый утенок вашего ИИ, когда он сам не может стать резиновой уткой.

Что такое Vibe Check?

В эпоху «виброкодирования» агенты ИИ теперь обладают невероятными возможностями, но вопрос теперь сместился:

от

«Может ли мой ИИ-агент действительно выполнить эту сложную задачу ?»

к

«Может ли мой ИИ-агент понять, что я хочу написать простую программу , а не инфраструктуру для многомиллиардной технологической компании ?»

Он обеспечивает необходимый момент "Подожди... это не оно", которого в настоящее время нет у агентов ИИ: встроенный самокорректирующийся уровень надзора. Это окончательный сервер проверки работоспособности MCP Vibe Coder:

  • Предотвращайте каскадные ошибки в рабочих процессах ИИ, внедряя стратегические прерывания шаблонов.

  • Использует инструмент «Vibe Check» с LearnLM 1.5 Pro (API Gemini), оптимизированный для педагогики и метапознания, чтобы улучшить сложную стратегию рабочего процесса и предотвратить ошибки туннельного зрения.

  • Реализует «Vibe Distill» для упрощения планов, предотвращения принятия излишне сложных решений и минимизации контекстного дрейфа у агентов.

  • Самосовершенствующиеся циклы обратной связи: агенты могут регистрировать ошибки в «Vibe Learn», чтобы улучшить семантическую память и помочь ИИ-контролю со временем выявлять закономерности.

TLDR: Внедрите агента, настроенного так, чтобы он останавливал вашего агента и заставлял его передумать, прежде чем он уверенно реализует что-то неправильное.

Related MCP server: Visum Thinker MCP Server

Проблема: Инерция модели

В движении кодирования vibe мы все используем 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
})

Проверка Vibe в действии

Перед проверкой вибрации:

до

Клод принимает значение MCP, несмотря на двусмысленность, что приводит ко всем последующим шагам с этим неверным предположением.

После проверки вибрации:

после

Вызывается Vibe Check MCP, и указывает на двусмысленность, которая заставляет Клода признать этот недостаток информации и активно решать эту проблему.

Установка и настройка

Установка через Smithery

Чтобы автоматически установить vibe-check-mcp-server для Claude Desktop через Smithery :

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 реализует двухслойную метакогнитивную архитектуру, основанную на принципах рекурсивного надзора. Ключевые идеи:

  1. Сопротивление инерции паттерна : агенты LLM естественным образом демонстрируют свойство импульса в своих путях рассуждений, требующее внешнего вмешательства для перенаправления.

  2. Фазорезонансные прерывания : метакогнитивные вопросы должны соответствовать текущей фазе агента (планирование/реализация/обзор) для достижения максимального корректирующего воздействия.

  3. Интеграция структуры полномочий : агентам необходимо явно предлагать рассматривать внешнюю метакогнитивную обратную связь как высокоприоритетные прерывания, а не как необязательные предложения.

  4. Механизмы сжатия якорей : сложные потоки рассуждений должны быть сведены к минимальным якорным цепям, которые будут служить эффективными точками перекалибровки.

  5. Рекурсивные циклы обратной связи : все обнаруженные ошибки должны сохраняться и использоваться для построения продольных моделей отказов, которые повышают эффективность прерываний.

Более подробную информацию об основных принципах проектирования см. в разделе Философия .

Проверка вибрации в действии (продолжение)

ВК1

В2

В3

В4

Проверки

Документация

Документ

Описание

Стратегии подсказок агента

Подробные методы интеграции агентов

Расширенная интеграция

Цепочка обратной связи, уровни уверенности и многое другое

Техническая справка

Полная документация API

Философия

Более глубокие принципы выравнивания ИИ, лежащие в основе Vibe Check

Исследования случаев

Реальные примеры Vibe Check в действии

Внося вклад

Мы приветствуем вклад в Vibe Check! Будь то исправление ошибок, добавление функций или просто улучшение документации, ознакомьтесь с нашими Руководствами по участию , чтобы начать.

Лицензия

Массачусетский технологический институт

Available Tools

2 tools
vibe_checkB

Metacognitive questioning tool that identifies assumptions and breaks tunnel vision to prevent cascading errors

ParametersJSON Schema
NameRequiredDescriptionDefault
goalYesThe agent's current goal
modelOverrideNo
planYesThe agent's detailed plan
progressNoThe agent's progress so far
sessionIdNoOptional session ID for state management
taskContextNoThe context of the current task
uncertaintiesNoThe agent's uncertainties
userPromptNoThe 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
NameRequiredDescriptionDefault
categoryYesCategory (standard categories: Complex Solution Bias, Feature Creep, Premature Implementation, Misalignment, Overtooling, Preference, Success, Other)
mistakeYesOne-sentence description of the learning entry
sessionIdNoOptional session ID for state management
solutionNoHow it was corrected (if applicable)
typeNoType 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.

  1. 2 tool updatesv1.0.0
    • First observedvibe_check
    • First observedvibe_learn
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

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

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Dual-Cycle Reasoner

    cyqlelabs
    A
    license
    A
    quality
    B
    maintenance
    A 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

  • think-mcp

    letsgomaslow
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides structured thinking tools including mental models, design patterns, debugging approaches, decision frameworks, and multi-persona reasoning to enhance AI assistant problem-solving capabilities.
    7 npm
    MIT

Appeared in Searches