Loading ToolBench
Model Context Protocol toolkit for elabftw (electronic lab notebook). Stdio MCP server + programmatic eLabFTW v2 client. Search, read, and write experiments, items, attachments, comments, steps, and links from any MCP-aware AI client.
11 tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools have names starting with action verbs (elab_search, elab_get, elab_create, elab_update, elab_add) and descriptions present. However, descriptions are minimal (10-50 chars), parameter descriptions lack detail on constraints/formats, and output schemas are not documented. No tool annotations (readOnlyHint/destructiveHint). Error handling and recovery guidance absent from descriptions. Composition is reasonable (search/get/create/update/add are distinct), but parameter relationships (e.g., team ID defaults) are underdocumented.
Add a comment to an experiment or item
Add a step to an experiment
Create a new experiment
Create a new item
Get a full experiment by ID
Get a full item by ID
Search across all teams (fanout aggregator)
Search experiments in eLabFTW
Descriptions are too brief (10-50 chars). Rubric baseline is 194 chars; descriptions lack WHEN to use, prerequisites, and return value guidance. LLMs cannot reliably select tools without richer context.
Output schemas not documented. Callers cannot know what fields to expect (e.g., does search return id, title, body, created_at, team_id?). Breaks tool chaining and forces LLM guessing.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
Search items in eLabFTW
Update an experiment
Update an item
Parameter descriptions lack constraints. 'team' param marked optional with 'uses default if not specified', but no description of what the default is, how it's determined, or whether it's per-user or global. Ambiguous defaults risk silent failures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe reads from destructive writes without parsing descriptions. elab_create_*, elab_update_*, elab_add_* should be marked destructiveHint=true.
No error handling guidance in descriptions. If a search returns no results, if an ID is invalid, or if a write fails due to permissions, LLMs have no recovery path. Descriptions should hint at common failures and next steps.