Loading ToolBench
Lightweight MCP server bridging Claude Code to Google's Gemini AI via official CLI
The Gemini Bridge server exposes 4 tools for executing Gemini CLI commands with varying file attachment modes. Tool naming follows a consistent verb_noun pattern (execute_gemini_*), which is positive. However, there are significant gaps in parameter descriptions, schema completeness, error handling guidance, and output documentation. All four tools have descriptions, but they are brief (43-79 chars) and lack depth about when to use each variant or what to expect in returns. Parameter descriptions exist but lack detail on constraints, ranges, or expected formats. The server reads files from disk with truncation logic (up to 256KB per file, 512KB total), but these limits are not exposed in parameter descriptions or output. No output schemas are documented, it is unclear what structure the Gemini CLI returns or how the MCP server transforms it. Error handling is minimal; validation failures would likely surface as subprocess errors rather than actionable guidance to the LLM. The tools are well-composed (each handles a different file attachment pattern), but the interface does not match the chat data model, users say 'ask Gemini about my code' but must explicitly construct file paths and choose an attachment mode.
Execute gemini CLI command for simple queries without file attachments.
Execute gemini CLI command using @ command syntax for file references.
Execute gemini CLI command with file attachments sent using the --files-inline flag.
Execute gemini CLI command with file attachments sent as inline content in the prompt.
Output schemas are not documented. Users of these tools have no way to know what fields the Gemini CLI returns or how the MCP server structures the response. This forces LLMs to guess at return types and fields, risking failed downstream compositions.
Parameter descriptions lack actionable detail. 'The prompt to send to Gemini' is minimal; it does not explain format expectations, token limits, or what kind of prompts work best. 'Optional timeout in seconds' does not specify valid range or server defaults. 'Optional model name' does not list valid models or what 'flash', 'pro', etc. mean.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Tool descriptions do not explain when to use each variant. execute_gemini_with_inline vs execute_gemini_with_attachments vs execute_gemini_with_at_command all attach files but with different mechanisms. The descriptions provide no guidance on which to choose for a given use case, forcing the LLM to guess or try all three.
File size constraints (MAX_INLINE_FILE_BYTES=256KB, MAX_INLINE_TOTAL_BYTES=512KB) are enforced in code but not exposed to the LLM via parameter descriptions or error messages. If a user tries to attach a 2GB video, they get a cryptic failure instead of 'Files must be <256KB each; total <512KB.'
The 'files' parameter in three tools lacks a type definition in the schema shown. It is described as 'List of file paths' but the JSON Schema type (array of what?) is not visible. If items are not typed as strings, the schema is incomplete.
No error handling guidance. The code checks file sizes, resolves paths, and calls subprocess.run(), but there is no documentation of what errors can occur, whether they are retryable, or how to recover. An LLM receives a generic error and cannot self-correct.
The 'model' parameter accepts free-form strings and relies on _normalize_model_name() to map aliases. The parameter description does not list valid models or aliases, so LLMs do not know which to try. The code accepts 'auto', 'flash', 'pro', '3-pro', '3.1-pro', etc., but this is hidden in implementation.
Tool naming does not distinguish the three file-attachment tools clearly enough. 'execute_gemini_with_inline' vs 'execute_gemini_with_attachments' vs 'execute_gemini_with_at_command' are all variations on the same operation. The names alone do not convey *why* or *when* to choose each.