check_constitution
Return the current constitution rules for this session
LABSCO SUMMARY
The moment an agent should stop and doubt itself becomes a call it can actually make.
The checkpoint takes the plan and the uncertainties as explicit arguments, so the agent has to state both before it can be challenged on either — that framing does as much work as the answer does. Pointing the override at a different model than the one being questioned is the difference between a review and an echo.
What it is
A metacognitive interrupt for agent runs: one tool that questions the current plan, one that files mistakes against their fixes, and three that maintain a session-scoped set of rules. The questioning itself runs on an LLM you supply a key for.
What you get
- A checkpoint call that takes the goal, the plan, progress so far and the stated uncertainties, and returns questions aimed at the assumptions underneath them
- A model override on that call, so the questioning can run on a different model than the agent being questioned
- A choice of provider behind it — Gemini by default, or OpenAI, Anthropic or OpenRouter — with the model pinned or left at the provider's default
- A record of mistakes paired with their solutions, filed by category and type, so a recurring error becomes visible as a pattern
- A session constitution you can append to one rule at a time, overwrite wholesale, or read back mid-run
- Stdio for a local client, or streamable HTTP for a shared one
Requirements
Node.js, and at least one provider key: GEMINI_API_KEY is the default path, with OPENAI_API_KEY, ANTHROPIC_API_KEY and OPENROUTER_API_KEY as alternatives selected through DEFAULT_LLM_PROVIDER — the checkpoint is an LLM call, so without a key there is nothing to ask. OpenRouter additionally needs DEFAULT_MODEL named. Constitution rules are held in memory for the session, so they exist only as long as the process does. The project is in maintenance mode: security and bug fixes only, no new features. MIT licensed.
Setup effort
One command plus a key — npx -y @pv-bhat/vibe-check-mcp start --stdio, then supply credentials
USE CASES
01
Catching an over-engineered plan before it is built
State the goal, the plan and what you are unsure about, and get back the questions that expose the assumption underneath.
02
Having the reviewer be a different mind
Point the checkpoint at another provider or model, so the critique does not come from the same reasoning that produced the plan.
03
Setting the rules a run must hold to
Append the constraints at the start, read them back when the agent drifts, and reset them for the next run.
04
Noticing you keep making the same mistake
File each error against the fix that worked, so what looked like bad luck shows up as a pattern.
5 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
reset_constitution
Overwrite all constitutional rules for this session
update_constitution
Append a constitutional rule for this session (in-memory)
vibe_check
Metacognitive questioning tool that identifies assumptions and breaks tunnel vision to prevent cascading errors
vibe_learn
Pattern recognition system that tracks common errors and solutions to prevent recurring issues
BEFORE YOU INSTALL
What to know first
Tools you get
5 tools when we connected.
Requires
- npx on PATH
- GEMINI_API_KEY in your environment
Where it runs
All 4 documented clients run the server on your machine.
CONTEXT COST
Light Standing cost
Rated by the size of the 5 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
npx -y @pv-bhat/vibe-check-mcp start --stdioMCP Clients
Claude Desktop, Cursor, Windsurf
Save GEMINI_API_KEY in ~/.vibe-check/.env first. The server looks the key up in your environment, then the project's .env, then ~/.vibe-check/.env, so the block itself carries no key.
JSON
{
"mcpServers": {
"vibe-check-mcp": {
"command": "npx",
"args": [
"-y",
"@pv-bhat/vibe-check-mcp",
"start",
"--stdio"
]
}
}
}VS Code
Save GEMINI_API_KEY in ~/.vibe-check/.env first. The server looks the key up in your environment, then the project's .env, then ~/.vibe-check/.env, so the block itself carries no key.
VS CODE · JSON
{
"servers": {
"vibe-check-mcp": {
"command": "npx",
"args": [
"-y",
"@pv-bhat/vibe-check-mcp",
"start",
"--stdio"
]
}
}
}
