Loading ToolBench
MCP server that gives Claude Code persistent memory of your codebase, backed by Gemini's 2M-token context. Includes eager `ask`/`code` for cached repo Q&A and `ask_agentic` for agentic file access on repos that exceed the model's input-token limit.
Strong tool definitions with comprehensive parameter schemas and detailed descriptions. All 6 tools have clear names starting with action verbs (ask, code, clear, reindex, status). Descriptions are detailed (194 - 500+ chars), exceeding the 10 - 1024 baseline. Input schemas are fully specified with types, descriptions, and constraints (enums for model/thinkingLevel, numeric bounds for timeouts). However, output schemas are not explicitly documented in the visible source, responses are inferred from descriptions rather than formally declared. Error handling guidance is present in descriptions (e.g., 'WORKSPACE_TOO_LARGE' fallback, timeout kinds) but not structured as recovery patterns. Tool composition is excellent: ask/ask_agentic/code are distinct with clear separation of concerns; ask_agentic includes agentic file-access tools (list_directory, find_files, read_file, grep) with hard size limits documented. No security issues detected, no credentials in parameters, workspace paths are sandboxed. Naming is precise (ask vs ask_agentic vs code) and avoids ambiguity.
Q&A / long-context analysis against a workspace. Uses the Persistent Context Cache when available, reducing repeat-query cost and latency. First call on a workspace: ~30–45 s (upload + build). Subsequent calls with unchanged files: ~2–3 s.
Answers workspace questions without eager repo upload. Sends only the user's prompt + function-call tool declarations. Gemini decides which files to read via `list_directory` / `find_files` / `read_file` / `grep`. Loop runs until the model emits a text-only response (no more function calls), or until a guard trips (max iterations, token budget, no-progress loop). This path scales to any repo size — the model reads only what it needs for the specific question.
Delete the cached context and manifest entries for a workspace. The Gemini-side cache is also released. Useful before switching projects or when you want to reset state deliberately.
Dedicated coding delegation to Gemini. Uses native Gemini features: Thinking budget (reasoning tokens before generation), Optional Code Execution tool (Gemini runs Python in a sandbox), Coding-optimized system prompt, Structured output parser extracts code blocks and OLD/NEW diffs.
Output schemas not formally documented. Tool descriptions mention return types (e.g., 'structuredContent.apiCalls', 'caching.implicitHitRate') but no explicit JSON Schema for responses. LLMs cannot reliably extract fields from undocumented outputs.
Error handling lacks structured recovery guidance. Descriptions mention error codes (TIMEOUT, WORKSPACE_TOO_LARGE, EXCLUDED_FILE) but do not classify them as retryable/user-fixable/fatal or provide actionable next steps for LLMs.
Agentic tools (list_directory, find_files, read_file, grep) are not registered as top-level MCP tools. They are internal function-call tools used by ask_agentic, not exposed to the client. This is correct design but means they cannot be directly invoked by agents.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2025-06-18+ | v2 |
Clear the current Gemini Context Cache for a workspace and rescan the file tree. The next ask/code call will upload changed files and build a new cache. Use after a large refactor when hash-based invalidation would be slower than a full rebuild.
Inspect the cache state for a workspace: file count, cache ID, TTL remaining, cumulative cost, and savings from cache hits. Also lists models available to the current API key.
Tool descriptions use technical jargon (Persistent Context Cache, implicit caching, MRTR, structuredContent) without sufficient explanation for LLMs unfamiliar with Gemini internals. Descriptions should explain WHAT the tool does for the user, not HOW Gemini implements it.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in source. These are optional but recommended for protocol readiness. ask/status/clear/reindex/code should declare their risk profiles explicitly.