Loading ToolBench
Enterprise Wiki Platform — reference implementation with MCP server adapter for search, page management, submission, and review operations
Strong schema coverage (all 12 tools have complete JSON Schema with types and descriptions) and clear naming conventions (verb_noun pattern: wiki_search, wiki_submit, wiki_get_page, etc.). Descriptions are detailed and reference internal architecture (04 §1, 05 §3, etc.), providing context for when to use each tool. However, descriptions are verbose (200-400+ chars, exceeding the 10-1024 baseline sweet spot of 50-200 chars) and include implementation details rather than LLM-optimized guidance. Parameter descriptions are present but often technical. Error handling guidance is minimal, tools raise exceptions but don't guide recovery. No output schemas documented. Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in the spec.
Create a new page in a workspace (04 §2) — the primary authoring entry point. Maps to `POST /pages`.
Delete a page from a workspace (04 §2) — soft-delete, preserving history. Maps to `DELETE /pages/{id}`.
Fetch a specific page by id, e.g. for an agent following a citation. Maps to `GET /pages/{id}`.
Poll the ingestion status of a source this principal submitted (05 §3, phase2-tasklist.md step 44) — the only read-only tool that's principal-specific rather than workspace-wide. Maps to `GET /sources/{id}`.
Browse/filter a workspace's pages — e.g. to walk its `index.md` catalog programmatically. Maps to `GET /pages`. `status="draft"` needs `contributor` (elevated scope, 04 §6's reasoning applied the same way `api.py`'s own `list_pages_endpoint` does).
List pending review items for a workspace (05 §4) — the human-in-the-loop gate's queue. Maps to `GET /review`.
Descriptions are verbose (200-400+ chars) and architecture-focused rather than LLM-optimized. Include internal section references (04 §1, 05 §3) that add no value to agent reasoning. Should be 50-200 chars, action-oriented, and answer: What does it do? When to use it? What does it return?
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what fields does wiki_search return? Is there pagination?). Every tool needs a documented return type.
Tool annotations missing. Risk classifications are documented in spec (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) but not exposed as MCP readOnlyHint/destructiveHint/idempotentHint. Agents cannot distinguish safe from dangerous operations without parsing descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Resolve one review item (approve/reject/dismiss, 05 §4) — the platform's human-in-the-loop gate for ingestion, curation, and indexing. Maps to `POST /review/{id}/resolve`.
Restore a deleted page to its previous state (04 §2) — reverses a soft-delete. Maps to `POST /pages/{id}/restore`.
Single-stage lexical/catalog search (04 §1) — ranked, cited page snippets, no synthesis. Maps to `GET /search`.
Submit pasted text as a new source for ingestion (05 §3, phase2-tasklist.md step 44) — the only delegated operation 06 §2 names (`acting_as` argument, 09 §5). Maps to `POST /sources`.
Thumbs-up/down (`rating`: `"up"` or `"down"`) on one result of a search call this same principal ran (07 §4, phase3-tasklist.md step 68) — the platform's relevance-regression signal, and a real "this isn't serving readers" input to the Maintenance Advisor's staleness detector. Maps to `POST /search/{query_id}/feedback`.
Update an existing page (04 §2) — creates a new version, preserving history. Maps to `PUT /pages/{id}`.
Error handling guidance absent. Tools raise McpAuthError and other exceptions but provide no recovery hints. Descriptions do not explain what to do if a call fails (e.g., 'If page not found, try wiki_search() first').
Parameter descriptions are technical and assume domain knowledge. E.g., 'workspace_id' lacks guidance on how to obtain one; 'acting_as' references '09 §5' instead of explaining delegation. Descriptions should be self-contained and actionable for agents unfamiliar with the platform.