Loading ToolBench
MCP server for adding Gemini context management with both session-based context and API caching
This server has significant definition quality gaps. The tool set exhibits duplicate tool definitions (search_context and get_context appear twice with different signatures), indicating either incomplete refactoring or serious registration issues. While most tools have descriptions and input schemas are present, the descriptions are generic and lack actionable context for LLM selection. Many parameters lack descriptions entirely (e.g., the 'includeSystem' parameter in the second get_context has no description). The server lacks output schema documentation, there is no visible specification of what fields are returned by any tool. Error handling descriptions are absent. The schema quality varies: some tools like add_context have well-structured nested objects, but others like list_caches have empty input schemas ({}), indicating tools that may not require parameters but lack documentation of their output structure. No tool returns are documented, violating the baseline that 100% of A+ tools have documented return types. Tool composition has issues: discover_capabilities and get_tool_help appear to be self-referential discovery tools rather than domain tools for context management, bloating the surface area. The server mixes high-level concerns (context session management via generate_text, get_context, add_context, clear_context, search_context) with infrastructure concerns (caching via create_cache, generate_with_cache, list_caches, update_cache_ttl, delete_cache), which should ideally be separated or clearly documented as distinct domains.
Add a new entry to the context
Clear the context for a session
Create a cache for frequently used large contexts
Deletes a cache
Returns a manifest describing all capabilities of this MCP server
Generate text using Gemini with context management
Generate content using a cached context
Tool definitions are duplicated: search_context appears twice with identical signatures; get_context appears twice with different signatures (one uses sessionId, one uses includeSystem boolean). This creates ambiguity for LLMs and indicates incomplete schema management.
No tool documents its output schema or return structure. LLMs cannot plan downstream calls or extract required fields without knowing what fields are returned. Baseline: 100% of A+ tools have documented return types.
list_caches has an empty input schema {} with minimal description (24 chars). It is completely undocumented, no pagination parameters, no filtering, no output structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Retrieve the current context for a session
Get the current context state
Get detailed help and examples for a specific tool
List all available caches
Search for relevant context using semantic similarity
Search for relevant context using semantic similarity
Updates a cache's TTL
Parameter 'includeSystem' in the second get_context tool has no description. Multiple parameters lack descriptions across the tool set, violating the baseline that 100% of A+ tool params have descriptions.
Destructive/irreversible operations (clear_context, delete_cache) are not marked with idempotentHint or destructiveHint annotations in the source code, and descriptions do not warn LLMs about irreversibility. Agents need explicit guidance to understand consequences.
Two meta/discovery tools (discover_capabilities, get_tool_help) do not advance the primary domain (context management). They inflate the tool surface area and lack clear use cases. Consider removing or documenting when LLMs should invoke them.
Descriptions for many tools are too short or generic: 'Clear the context for a session' (32 chars), 'Deletes a cache' (13 chars), 'List all available caches' (24 chars). These fall below the 10 - 1024 character guideline sweet spot (average 194 chars) and lack context for LLM selection. Cannot explain when/why to use tool vs. alternatives.
No error handling documentation. Tool descriptions do not explain what happens on failure (e.g., invalid sessionId, cache not found, TTL invalid). LLMs have no recovery guidance. Baseline: error responses must tell the LLM what to do next.