Loading ToolBench
A TypeScript MCP server for Google Gemini — text, chat, search, code execution, and image generation.
The server defines 7 tools with generally clear descriptions and well-structured input schemas using Zod validation. All tools have descriptions (130-200 chars typical), documented parameters with type constraints, and enum values where appropriate. However, output schemas are partially documented (structuredContent present but incomplete documentation in source), and several tools lack explicit error recovery guidance. Tool naming follows verb_noun conventions consistently. Parameter descriptions are adequate but could be more specific about format/constraints. No parameter descriptions include examples of valid inputs or edge case handling. Security is solid (API key via env var, no secrets in params). Composition is clean, each tool has a single responsibility. The chat tool handles session state elegantly with timeout cleanup.
Multi-turn conversation with session management. Omit sessionId to start a new session; include it to continue an existing one.
Execute Python code in a sandboxed environment. Gemini generates and runs code, returning both the code and results.
Edit an image using a text prompt. Send a base64-encoded image and describe the desired changes.
Edit or compose images using multiple reference images (up to 14). Uses gemini-3-pro-image-preview (Nano Banana Pro).
Generate an image from a text prompt using Gemini image models (Nano Banana Pro by default).
Generate text using Google Gemini models with configurable model, temperature, and system instructions.
Output schemas documented in code but not formally declared in schema registration. The structuredContent pattern is correct but the MCP server registration does not include outputSchema fields, preventing clients from understanding the return type structure before invocation.
Error handling returns formatToolError() output format but no error response guidance in descriptions. LLMs cannot determine what to do next when a tool call fails (e.g., 'API quota exceeded' vs 'invalid model name'). Error messages should categorize as retryable/user-fixable/fatal.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Generate text with Google Search grounding for up-to-date, cited responses.
Parameter descriptions lack constraint details. E.g., temperature is described as 'Sampling temperature (0-2)' in the input schema, but the description field itself only says 'Sampling temperature', no mention of the range. Descriptions should state: 'Temperature for sampling (0.0 - 2.0; 0=deterministic, 2=maximally random).'
edit_image and edit_image_multi are similar but have slightly different names. 'edit_image' handles single images; 'edit_image_multi' handles multiple. Name distinction could be clearer, consider 'edit_image' (single) and 'compose_images' (multiple) to avoid confusion.
code_execution description says 'Gemini generates and runs code' but does not clarify that the LLM cannot directly see stderr/stdout beyond what Gemini's codeExecution tool returns. If code hangs or crashes, the LLM's visibility is limited. Clarify constraints.