Loading ToolBench
MCP Server for shared project context across multiple LLMs (Claude, Gemini, Copilot)
Solid foundation with 11 well-named tools using verb_noun convention (create_, save_, get_, list_, search_). All tools have descriptions (avg 150 chars, within baseline 194). Input schemas are comprehensive with Zod validation and nested object support. Tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Key gaps: output schemas not documented in code; error handling guidance absent; no pagination parameters on list_sessions despite potential large result sets; parameter descriptions could be more prescriptive about constraints and formats.
Initialize or retrieve a project in the context hub. Call this first when starting work on any project. Returns the project details and whether it was newly created.
Retrieve code patterns for a project, optionally filtered by category, language, or keyword search.
Retrieve the most recent (or specific) context snapshot for a project. Use this when taking over from another LLM — it tells you exactly what was done and what to do next.
Retrieve architectural decisions for a project, optionally filtered by status.
Get a complete overview of the project: architecture, stack, patterns, decisions, and recent sessions. Perfect starting point for any LLM entering the project.
List all saved sessions for a project with their LLM, timestamp, and task summary.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns the project details') but no structured schema is visible in code. LLMs cannot plan downstream tool calls or extract specific fields without knowing response structure.
list_sessions lacks pagination parameters (limit, offset, cursor). Tool accepts only projectId and limit, but no offset/cursor for continuation. Large session lists will blow context window without pagination support.
Error handling guidance absent. No tool description explains what to do if a projectId is invalid, a sessionId does not exist, or a write operation fails. LLMs have no recovery path.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Record an architectural decision with its context, rationale, and consequences. Status must be one of: proposed, accepted, deprecated, superseded.
Save or update the project's architecture overview, technology stack, and environment template. Call this when you learn the project structure so future LLMs understand it immediately.
Save a reusable code pattern or template (e.g. JWT interceptor, FCM handler, error boundaries). Saves over an existing pattern with the same name if one exists.
Save the current working state so another LLM can pick up exactly where you left off. Call this proactively as you work and always before your context runs out. If you use the same sessionId again, the snapshot is updated in place.
Search across all project context: patterns, decisions, and snapshots. Returns matching items with excerpts.
Parameter constraints not prescriptive. E.g., 'status' in save_architectural_decision lists allowed values in description ('proposed, accepted, deprecated, superseded') but should use enum constraint in schema for machine-parseable validation.
Nested object schemas (architecture, stack, codeContext) lack required field declarations. LLMs cannot determine which nested fields are mandatory vs optional, risking incomplete payloads.