Loading ToolBench
Reference MCP server for the Org Context Spec — serves organizational context to AI agents and lets them propose changes
Four tools with clear verb-noun naming (get_, propose_, search, fetch). All have descriptions (194 - 392 chars, within baseline). Input schemas present with Zod validation. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) correctly applied. Key gaps: output schemas not documented in code; error handling lacks recovery guidance; parameter descriptions are minimal (e.g., 'Search query' for search.query); no pagination support for search results despite potentially large result sets.
Read one organizational context file by id (its path, as returned by search).
Read the organizational context (Org Context Spec repo). Without arguments: returns the context README (the reading order and writing rules — always start here) plus a list of all context files — or, for a new/empty repository, onboarding instructions for seeding it. With a path: returns that file, or its starter template if the file does not exist yet. Read the relevant context BEFORE writing code, stories, or product documents. If you know which team you work for, read teams/<team>.md early — it maps the team's tracker, systems, and product areas.
Propose one coherent change to the context — one or several files that together make up a single logical decision. Bundle everything that belongs together into ONE call: one proposal becomes one commit (and one pull request for review), never one per file. IMPORTANT: the model recommends, a human decides — show the user exactly what will change and get their explicit approval BEFORE calling this tool. Provide the complete new content of each file.
Search the organizational context files. Returns matching files; use fetch to read one.
Output schemas not documented. Tools return text responses via text() helper, but LLMs cannot infer structure of search results (hits array with id/title/url/score) or get_context audit findings. Downstream tools cannot reliably extract and chain results.
search tool lacks pagination. No limit, offset, or page_size parameters. Large context repositories could return hundreds of files, exhausting context window. Baseline: paginated tools accept limit (1 - 100) and return total_count or next_cursor.
Parameter descriptions are minimal. search.query is 'Search query' (12 chars, below 20-char floor). fetch.id is 'File path, e.g. organisation/constraints.md' (41 chars, acceptable but sparse). LLMs need format hints: 'Search query (case-insensitive, space-separated terms)' or 'File path relative to repo root, e.g. products/parking/product.md'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. templateFallback() and auditSource() errors are caught but responses do not guide LLM on next steps. E.g., 'File not found. Try search() to find similar files' or 'Audit failed. Retry or contact admin.' Current: raw error thrown.
propose_context_change lacks dry-run or confirmation step. Tool directly calls source.writeFiles() without agent confirmation. Agents can propose destructive changes (delete entire files) without explicit user approval. Should return a preview and require explicit confirmation before writing.