Loading ToolBench
An unofficial MCP server for NotePM - a knowledge management platform
Server provides 8 tools with consistent naming conventions (verb_noun pattern: list_*, search_*, get_*, create_*, update_*) and explicitly defined input schemas via Zod. However, descriptions are sparse (average ~50-70 chars), parameter descriptions lack depth, and output schemas are not documented. Error handling is not visible in the provided code. Tool composition is clean but parameters could be more richly constrained. The codebase shows good engineering practices (TypeScript, Zod validation, modular structure) but falls short of production-grade definition quality expected for distributed AI agents.
Create a new page in NotePM. Note code and title are required. Optionally specify folder_id to create the page in a specific folder.
Create a new tag in NotePM.
Get a NotePM page. Retrieve title, body, tags and other details by page code.
List folders in a NotePM note. Returns folder hierarchy with IDs and names.
List all NotePM notes. Returns note codes, names, and descriptions.
List all tags in NotePM. Can filter by note code.
Search NotePM pages. Can filter by keyword, note, or tag.
Output schemas are not documented. LLMs cannot infer what fields are returned by each tool, forcing them to guess about downstream chaining and field extraction.
Descriptions are too brief (40-70 chars) and lack actionable context. Per pattern:tool-description, descriptions should be 10-1024 chars and state WHAT, WHEN, and any prerequisites. 'Create a new tag in NotePM' (34 chars) provides no guidance on tag naming conventions, when to call it vs search_tags, or what format it expects.
Parameter 'tags' in create_page and update_page is declared as type 'array' with minimal description. Missing: item type (string? objects with name/id?), length constraints, naming rules, what happens if an invalid tag is passed. Per pattern:constrained-input, array parameters need item-level schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Update an existing NotePM page. Page code is required. To move the page to a different folder, specify both folder_id and note_code.
Pagination parameters (page, per_page) in list_notes, search_pages, list_tags lack constraints and default values. Per pattern:paginated-result, should specify: minimum page (usually 1), per_page range (e.g. 1-100), and total count in response. No guidance on whether pagination is 0-indexed or 1-indexed.
No visible error handling or recovery guidance in tool handlers. Per pattern:recovery-guide, errors must tell LLMs what to do next (e.g. 'Invalid note_code. Call list_notes() to find valid codes'). Source code shows tool definitions but handlers are not included in the snippet.
Parameter descriptions across all tools are generic one-liners. 'The code of the page to retrieve' for page_code lacks format hints (alphanumeric? length?). Per pattern:tool-description, include format, range, examples, or constraints: 'A page code (alphanumeric, max 50 chars, e.g. PAGE_ABC123)'.
Unclear composition for multi-step workflows. create_page returns 'page_code', but does it also return folder_id, parent_id, and note_code? Without these chaining fields, an agent that creates a page may not be able to immediately update it (update_page requires page_code, note_code, and folder_id). Per pattern:tool-chain, output must include IDs downstream tools need.
create_tag description is 34 characters: 'Create a new tag in NotePM.' This violates the 10-1024 baseline from pattern:tool-description. It should explain when to create vs when to search existing tags, tag naming rules, and what triggers conflicts.