Loading ToolBench
MCP server providing Gemini AI integration with file attachment and session management capabilities for Claude
6 tools with basic definitions but significant quality gaps. Tool names follow verb conventions (attach_, ask_, list_, remove_, clear_, get_) which is good. However, descriptions are inconsistent in detail and depth. Input schemas are present but lack comprehensive parameter descriptions in several cases. No output schema documentation visible. Error handling is minimal, no recovery guidance, retryability classification, or actionable error messages. Parameter constraints are under-specified (e.g., file_path accepts strings but no format/length guidance). The server relies on session state management across calls, which complicates composition and introduces ordering dependencies that agents must track. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk classifications in the metadata.
Send a message to Gemini with all attached files and context from the current session. Gemini will analyze the files and context to answer your question.
Attach a file to the current session for analysis. Files persist across multiple requests within a session, enabling iterative analysis.
Clear all files and context from the current session, starting fresh
Get information about the current session including file count and message history
List all files currently attached to the session
Remove a specific file from the current session
No output schema documentation. Tools describe what they do but not what structure they return. LLMs cannot plan downstream calls or extract returned data reliably. attach_file, ask_gemini, list_files, remove_file, clear_session, get_session_info all lack documented return types.
Parameter descriptions are minimal or missing. file_path in attach_file and remove_file has a description, but message in ask_gemini is vague ('Your question or request for Gemini to analyze'). No guidance on length, format, required fields, or constraints. Schema validation is weak.
No error handling guidance. Tools do not document failure modes or recovery steps. For example, attach_file could fail if file does not exist, is unreadable, or exceeds size limits, but no error responses guide the LLM on what to do next. Error responses must include actionable recovery suggestions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
Destructive operations lack confirmation step. clear_session and remove_file modify state irreversibly but have no dry-run or confirmation mechanism. Agents can accidentally destroy session data without a chance to verify intent first.
Tool annotations missing. Risk classifications are provided in metadata (READ_ONLY, WRITE) but not surfaced as tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot infer retry safety or side effects from names alone. All WRITE tools should declare destructiveHint:true.
Session-based composition requires state tracking. Tools depend on prior state (session must exist, files must be attached before ask_gemini is called). This violates single-responsibility and forces LLMs to maintain implicit ordering. Better: design tools to work independently or explicit dependency documentation.
No pagination or limit specification. list_files and get_session_info do not document result size limits. If a session accumulates many files, unbounded results could exhaust context windows. Add limit and offset parameters with documented defaults (e.g., limit=50).
Ambiguous session identity. Tools reference 'the current session' but do not accept a session_id parameter. How does an LLM operate on a specific session? Is there a default? Are sessions auto-created? This ambiguity forces agents to guess or fall back on undefined behavior.