Loading ToolBench
MCP server for Review Ready — run pre-PR checks (debug statements, secrets, TODO debt, complexity) from Claude
Review Ready MCP provides two well-named tools with comprehensive descriptions and partial schema definitions. Tool names (check_changes, check_content) follow verb_noun convention clearly. Descriptions are detailed (180-250 chars each) and explain what each tool detects. Input parameters are documented with types (string, number) and optional flags. However, output schemas are NOT formally documented in the code, responses use structuredContent and text content fields but lack a declared schema specification. Error handling is absent, no guidance on what happens if git operations fail, if paths don't exist, or how LLMs should recover. Parameter constraints exist (e.g., complexity_threshold) but are not enforced with enums or ranges in the schema. The code shows tool registration with Zod schema objects, but these are not fully visible in the excerpt provided, limiting verification of schema completeness. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are correctly present and accurate.
Run Review Ready pre-PR checks on all changed files in a git repository. Detects: - Debug statements (console.log, debugger, print(), etc.) - TODO/FIXME/HACK markers in newly added lines - Potential secrets (API keys, AWS credentials, tokens, passwords) - Accidentally staged large files (>500KB) - Source files missing corresponding test files - High cyclomatic complexity in JS/TS additions Returns a summary of issues with file paths and line numbers.
Run Review Ready checks on a code snippet directly — no git repository needed. Useful when reviewing a code block that Claude just generated, or when checking a file's content before committing. Detects: debug statements, TODO markers, secrets, and complexity issues. Note: test coverage check requires knowing all project files, so it's skipped in this mode.
Output schemas are not formally documented. Responses return structuredContent with fields like 'status', 'filesChecked', 'totalIssues', 'errors', 'warnings', 'infos', 'results', but no schema definition is visible in the source. LLMs cannot predict output structure without explicit schema documentation.
No error handling or recovery guidance. The code does not document what happens if: repo_path is invalid, git operations fail, file parsing fails, or git diff returns no changes. Error responses should tell LLMs what to do next (e.g., 'Invalid repo path: is this a git repository? Try running git init.').
Parameter constraints not enforced. 'complexity_threshold' is optional and defaults to 10, but no min/max bounds are declared. LLMs could pass absurd values (e.g., 999999 or negative numbers) that break checks or cause unexpected behavior. Add numeric bounds to the Zod schema: z.number().min(1).max(100).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
check_content does not perform test coverage check (as documented), but the tool description does not explicitly mention this limitation. Users/LLMs might expect it to work like check_changes and be surprised when test files are ignored. Clarify: 'Note: test file checks require full project context and are skipped in snippet mode.'
Parameter descriptions lack context on when parameters are needed. 'base_sha' and 'head_sha' are optional, but the description does not explain: 'If omitted, diffs against staged/unstaged changes. If provided together, diffs between those two commits.' This forces LLMs to guess the behavior.
Result structure is complex (nested CheckResult objects with fields: severity, rule, message, file, line) but not documented in the tool description. LLMs cannot reliably extract actionable data from results without knowing the output schema. Document the structure: 'Results are ordered by severity (errors, warnings, info), with each entry containing {severity, rule, message, file, line}'.