Loading ToolBench
Every tool description, input schema and shared extraction rule of the Eigma MCP connector, plus a runnable example server.
Strong foundation with well-structured tool definitions and clear descriptions. All 6 tools have detailed, context-aware descriptions (150-250 chars each) that explain WHEN to use each tool and what it returns. Input schemas are present with type declarations. However, output schemas are not explicitly documented in the visible code, and some parameter descriptions lack format/constraint details. Tool naming follows verb_noun convention (browse, search, read, resolve, save, suggest). The server demonstrates sophisticated composition (e.g., resolve_pages pre-save check, tiered outline for large wikis) and thoughtful error tolerance (skipping malformed entries rather than rejecting batches). Missing: explicit output schema documentation, per-parameter validation rules, and error recovery guidance.
Use this when you need to navigate the wiki structure: pass a category_path to drill into that chapter and see its subcategories + pages, or omit it for the top-level table of contents. Returns the outline formatted for weak models: category names in quotes, pages numbered in display order with one-line summaries. For large wikis (>100 pages), returns a tiered overview (top-level categories with counts + subcategory names); drill in with eigma_search_wiki to find specific pages.
Use this when you need one existing Eigma page's FULL body: before integrating an update into it, or to answer a question grounded in it. Pass a `title` (and category if known) for ONE page; pass a `category_path` with NO title to read a whole chapter at once (before reorganizing it). Returns the body, summary, tags, and the page's quizzes as {id, prompt}; a miss means treat the concept as new. Reuse the returned page id when a later edit targets this page, and a quiz's id to remove or replace that exact quiz via eigma_suggest_edits (edit_quizzes).
Use this once before eigma_save_notes, with ALL your drafted pages: it returns, per draft, the existing pages it may duplicate (title + category + summary) plus the wiki's chapter list, so you update the right page instead of creating a near-copy. Read-only, and only for the pre-save check - to answer a question about the wiki or look a concept up, use eigma_search_wiki or eigma_browse_wiki.
Save new pages to the review inbox. Pass an array of pages, each with a title, category_path, summary, and body_md. The server queues them for review; the user integrates them into the wiki from the app. Tolerant: a page with no usable title is skipped, not rejected; the response reports how many were queued and how many were dropped.
Output schemas not explicitly documented. Tool descriptions state what is returned (e.g., 'Returns the body, summary, tags, and quizzes as {id, prompt}') but formal JSON Schema output definitions are absent from visible code. LLMs cannot reliably parse unstructured responses or plan downstream tool calls without documented return types.
Parameter constraints not formalized. 'category_path' and 'query' parameters lack format/length/pattern constraints in schema. Descriptions mention 'any language' and 'optional' but do not specify max length, character restrictions, or validation rules. LLMs may pass oversized or malformed inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2025-06-18+ | v2 |
Use this when you need to find existing Eigma pages by concept or keywords, anywhere in the wiki (matches title, summary, category): to locate the page to update, or the page(s) that answer a question. Returns matching page titles + categories + one-line summaries, not full bodies. A page's full text comes from eigma_read_page; an identical repeated search returns the same results.
Propose edits to existing pages. Pass an array of operations (move, merge, delete, rename, update_page, edit_quizzes, add_page) targeting pages by exact title or {title, category_path}. Each operation is validated and queued; the user reviews and applies them from the app. Tolerant: malformed or inert operations are dropped; the response reports what was queued.
Error handling guidance missing. No documented error responses or recovery paths. E.g., eigma_read_page states 'a miss means treat the concept as new' but does not specify the error structure (404 vs null vs error object). eigma_save_notes mentions 'dropped' pages but does not explain how to detect or handle them programmatically.
Batch operation error reporting unclear. eigma_save_notes and eigma_suggest_edits accept arrays but response structure for per-item success/failure is not documented. If 3 of 10 pages fail, does the response list which ones, or just a count? LLMs cannot retry selectively without per-item status.
Idempotency not declared. eigma_save_notes and eigma_suggest_edits are write operations but lack idempotent hints or deduplication guidance. If an agent retries after a network timeout, will duplicate pages/edits be created? No confirmation or dry-run pattern documented.