BlindReview MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REVIEWER_MODEL | No | Reviewer model id | gpt-5-mini |
| REVIEW_TIMEOUT | No | Timeout for the whole review in ms (AbortController) | 120000 |
| TELEMETRY_PATH | No | Relative paths resolve against the repo root | ./data/reviews.jsonl |
| REVIEWER_API_KEY | No | API key for the reviewer provider (omit for local servers) | |
| MAX_REVIEW_TOKENS | No | Near-hard cap on cumulative tokens (prompt + completion) across all phases | 20000 |
| REVIEWER_BASE_URL | No | Any OpenAI-compatible /chat/completions base URL | https://api.openai.com/v1 |
| TELEMETRY_ENABLED | No | Opt-in local JSONL telemetry. Booleans accept true/false, 1/0, yes/no, on/off; anything else is a startup error | false |
| REVIEWER_MAX_TOKENS | No | Max completion tokens per call | 4000 |
| BLINDREVIEW_ENV_FILE | No | Set to use a different .env file instead of <repo>/.env | |
| REVIEWER_TEMPERATURE | No | Optional 0..2; not sent when empty, dropped automatically if rejected | |
| BLINDNESS_LEAK_THRESHOLD | No | Proposal/blind-field 5-gram containment at which blind_first refuses (BLINDNESS_LEAK) | 0.5 |
| BLINDNESS_WARN_THRESHOLD | No | Containment at which meta.blindness_warning is set | 0.15 |
| REVIEWER_REASONING_PARAM | No | reasoning_effort (OpenAI/xAI) or reasoning_object (OpenRouter reasoning: {effort}); auto-detected from the URL | auto |
| REVIEWER_REASONING_EFFORT | No | low / medium / high; dropped automatically if the API rejects it |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| review_decisionA | Get ONE independent external review before an expensive decision (architecture, DB schema/migration, public API, key dependency, large refactor, security/performance, multi-hypothesis debugging). Default blind_first: the reviewer first solves the problem WITHOUT seeing proposed_solution, then the proposal is revealed and compared. Returns a compact verdict (KEEP | MODIFY | REPLACE | INSUFFICIENT_EVIDENCE), risks, an optional better alternative and the cheapest falsification probe to run. Costs one or two LLM calls; skip it for trivial changes (see should_review). BLINDNESS CONTRACT: describe the problem in objective/constraints/context/environment/evidence and put your plan ONLY in proposed_solution. Do not mention, hint at or paraphrase your planned solution in the other fields. decision_type and risk_level are visible to the blind phase. If proposed_solution is largely copied into the other fields, blind_first refuses with BLINDNESS_LEAK. |
| should_reviewA | Deterministic (no LLM, free) check whether a decision is expensive enough to justify review_decision. Advisory only. |
| record_outcomeA | Append an outcome record for a past review (local telemetry only, requires TELEMETRY_ENABLED=true). Use review_id from review_decision meta. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools serve clearly distinct roles: review_decision performs the review, should_review is a deterministic gate, and record_outcome is telemetry. No overlap in purpose or output.
All names use snake_case, but the pattern is not uniform: review_decision and record_outcome are verb_noun, while should_review is a modal-verb question form. Minor deviation but still readable.
Three tools is well-scoped for a focused review workflow; each tool has a clear, non-redundant purpose. No bloat or missing essentials.
The core lifecycle (should_review → review_decision → record_outcome) is covered. A minor gap exists: no tool to list or retrieve past reviews/outcomes, but telemetry is append-only and the main workflow has no dead ends.