Loading ToolBench
MCP server for shared context caching with trust verification — AI agents share and verify computed results
Server has 8 tools with complete descriptions and basic input schemas. Naming follows verb_noun convention (cache_lookup, cache_store, etc.). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool. However, parameter descriptions lack format constraints (e.g., no regex for 'key' format, no enum for 'limit' bounds). Output schemas are documented in code but not formally declared in tool registration. Error handling returns JSON with 'error' field but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write semantics. Trust-score concept is well-explained but parameter relationships (e.g., min_trust in get_trusted) lack explicit bounds documentation.
Look up a cached result by key. Returns the stored value if found, with trust score. Use this BEFORE computing expensive results -- another agent may have already computed and cached the answer, saving tokens and latency. Higher trust_score = more agents have verified this result is accurate.
Search the shared cache by keywords. Find relevant cached results from other agents. Search before computing -- if another agent has cached a similar result, you can reuse it directly. Results include trust scores showing verification level.
Get cache statistics and analytics. Shows total hits, misses, agent contributions, and access patterns.
Store a computed result in the shared cache so other agents can reuse it. After computing an expensive result (web search, analysis, API call), store it here. Other agents will find it via cache_lookup or cache_search. The entry starts with trust_score=1 (you as the first confirmer). Other agents can use confirm_entry to increase the trust score.
Confirm a cached result is accurate. Increases the entry's trust score. When you use a cached result and verify it's correct, confirm it. This builds trust for other agents: entries confirmed by multiple agents are more reliable than unverified ones. NETWORK EFFECT: More agents confirming = higher trust = more reuse. Each agent can confirm an entry once. Duplicate confirmations are ignored.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear semantic differences. cache_store and confirm_entry are destructive writes; cache_lookup, cache_search, get_trusted, cache_stats, list_cache, get_analytics are read-only. LLMs cannot infer safety without explicit hints.
Parameter constraints lack formal specification. 'limit' in cache_search accepts 1-50 but no enum/min/max in schema. 'ttl_seconds' in cache_store has bounds (60-604800) documented in description only, not in schema. 'min_trust' in get_trusted defaults to 3 but no bounds declared.
Output schemas not formally documented. Tools return JSON strings with implicit structures (e.g., cache_lookup returns {found, key, value, trust_score, ...}). LLMs cannot plan downstream calls without knowing what fields to expect. No schema declaration in tool registration.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Get detailed analytics about cache usage, agent contributions, and trust distribution.
Get only cache entries confirmed by multiple agents (high trust). Returns entries with trust_score >= min_trust, sorted by trust score. These are the most reliable cached results -- verified by multiple independent agents. Use this to find the most trustworthy precomputed results available.
List all cache entries with their metadata. Shows keys, trust scores, tags, and hit counts.
Error handling lacks recovery guidance. Exception handler returns {error: str(e), key: key} but does not tell LLM what to do next. No categorization of errors as retryable vs fatal. No suggestions for alternative tools or corrective actions.
cache_stats and get_analytics have minimal descriptions (60 chars). 'Get cache statistics and analytics' and 'Get detailed analytics about cache usage' do not explain WHEN to call them, what fields they return, or how they differ from list_cache. Descriptions should be 100-300 chars with context.