Loading ToolBench
A code review MCP server that analyzes code changes using Gemini AI and integrates with linters (ESLint, JSHint, TypeScript) to provide code quality feedback.
This server has a single tool 'review_code' with critical definition gaps. The tool has an empty input schema (no parameters defined), a description that exists but lacks LLM-optimized clarity, and no documented output schema. The tool name lacks a clear action verb (review_code is vague about what happens), and there is no parameter documentation whatsoever. The description is present (94 chars) but generic and lacks context about when to use this tool, what it returns, and dependencies. No error handling guidance, no output schema documentation, and no parameter constraints are visible in the code.
Analyzes code changes in a Git repository by detecting modified/added files, running linters (ESLint, JSHint, TypeScript), and sending the code with linter issues to Gemini for AI-powered code review feedback.
Tool name 'review_code' is vague and lacks specificity. Does it review one file, multiple files, all changed files, or uncommitted changes? Does it modify state or only report? Name should start with clear action verb and convey scope, e.g., 'analyze_code_changes' or 'audit_git_diffs_for_quality'.
Tool description (94 chars) is generic and lacks actionable clarity. Does not answer: (1) What input does the LLM need to provide? (2) What does the tool return? (3) When should it be called instead of other code analysis tools? (4) Does it modify state or only read? Current description assumes familiarity with Git/linter concepts but does not guide LLM selection.
No output schema is documented. The tool calls Gemini CLI and returns its output, but the structure (what fields, types, error format) is not visible to the LLM. Without documented output schema, LLMs cannot plan downstream operations or extract relevant data.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 16 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool accepts zero parameters but performs a complex multi-step operation (detect Git changes, run linters, invoke Gemini). This suggests either (a) parameters are missing from the schema, or (b) the tool hardcodes all behavior, making it inflexible and unable to accept user direction (e.g., which files to review, which linters to run, linter config paths).
Tool depends on external commands (git, eslint, jshint, tsc, gemini) that may not be installed or configured. No error handling guidance in the description. If gemini CLI times out or is missing, the LLM receives an unhelpful error and cannot self-correct.
Gemini API key is not visible in the provided source, but the tool invokes 'gemini' CLI directly. If the key is passed via environment variable, this is correct. However, there is no documentation of this prerequisite in the tool description. Agents may call the tool without knowing the setup requirement.
Tool description does not specify output format. Is the output structured JSON (e.g., {issues: [{file, line, message}]}), plain text, markdown, or raw Gemini response? Without format clarity, LLMs cannot parse or chain results.
No idempotency or dry-run capability documented. Does calling review_code twice on the same code produce identical output? Can it be safely retried on failure? Without idempotency guarantees, agents may be uncertain about retry safety.