Loading ToolBench
A notes management MCP server that allows creating, deleting, and searching personal notes
This server has significant definition quality gaps. While all three tools have descriptions and input schemas are present, the descriptions are inconsistent in depth, parameter descriptions are minimal, output schemas are not documented, and error handling provides no recovery guidance. The naming is verb-based (appropriate), but the overall implementation lacks the rigor expected for production use. All tools are explicitly registered with schemas visible in src/server.ts and src/tools/notes.ts, so inference penalty does not apply.
Add a new personal note with title and content
Create a random note with title and content
Delete a note by ID
No output schema documentation. Tools return text responses but do not document what fields to expect (e.g., create_note should document that it returns the created note's ID, title, creation timestamp). LLMs cannot plan downstream calls or extract structured data.
create_random_note has no input parameters (empty schema {}) but uses sampling/createMessage, a deprecated MCP pattern. Modern servers should integrate with the LLM provider API directly instead of invoking sampling on the client. Additionally, the tool has no clear success/failure contract, it catches errors silently and returns generic failure text.
Error handling is minimal and non-actionable. All three tools catch errors and return generic text like 'Failed to create note: [error]'. Per the recovery-guide pattern, errors should explain what the LLM should try next (e.g., 'Note not found. Call list_notes() to see available IDs.') and categorize errors as retryable vs. user-fixable.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Parameter descriptions are minimal or missing context. 'id' parameter in delete_note is simply 'The ID of the note to delete', it does not explain how to obtain a valid ID (e.g., 'Obtain from create_note response or list_notes()'), invite hallucination. 'title' and 'content' in create_note lack constraints (min length, max length, allowed characters).
Tool descriptions do not clarify state mutations. 'Add a new personal note' is correct but generic. A production description should state 'This tool creates and persists a new note. It is idempotent if called with the same title and content, but generates a new UUID each time, so repeated identical calls create duplicates.'
delete_note lacks a confirmation or dry-run mode. Destructive operations should support a safety pattern to prevent accidental deletion. Per pattern:confirmation-request, irreversible operations should require explicit agent intent (e.g., a 'confirm_delete' flag or a separate 'confirm_deletion' tool).