Loading ToolBench
MCP server for Notez — allows Claude Code to read and manage notes and tasks
Notez provides 35 well-named tools with consistent verb_noun patterns (search_, get_, list_, create_, update_, delete_). All tools have descriptions (avg ~100 chars, within baseline 34-392). Input schemas are present and typed for all tools, with enums for constrained fields (status, priority, permission). However, descriptions are often terse (10-50 chars) and lack context on WHEN to use each tool or dependencies between them. Parameter descriptions are minimal, many lack guidance on format, range, or prerequisites. Output schemas are not documented in the source, forcing LLMs to infer response structure. Error handling is present but generic; no recovery guidance or actionable error messages visible. Security: no evidence of secret injection, permission gates, or audit logging in the tool definitions.
Add a link to a task.
Append content to an existing note. Content is added to the end.
Submit feedback about Notez.
Create a new folder.
Create a new note. Content should be HTML format.
Create a new task with optional priority, due date, and tags.
Delete a folder. Notes in the folder are moved to unfiled.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns matching notes with snippets') but do not specify the response structure, field names, or types. LLMs cannot plan downstream tool calls or extract required IDs without knowing response format.
Parameter descriptions lack actionable guidance. Many params have minimal descriptions (e.g., 'Folder UUID', 'Tag UUID') without explaining format, constraints, or when to use. Descriptions like 'Filter by folder UUID, or null for unfiled notes' are good, but most lack this depth.
No error handling guidance visible. Tool definitions do not indicate what errors are possible, whether they are retryable, or what the LLM should do next. E.g., notez_get_note_by_title does not document behavior when title is not found.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Delete a note (moves to trash).
Delete a notification.
Delete a tag. All notes with this tag will have it removed.
Delete a task (moves to trash).
Delete a link from a task.
Get a note by its ID. Returns full content including plain text version.
Find a note by its exact title (case-insensitive match).
Get notifications for the user.
Get a task by its ID. Returns full task details including links and tags.
Get the count of unread notifications.
List all folders for the user.
List notes with optional filters. Filter by folder, tag, or search text. Returns paginated results.
List recently modified notes, sorted by last update time.
List all shares for a note.
List all tags for the user.
List tasks, optionally filtered by status. Returns tasks sorted by priority.
Mark all notifications as read.
Mark a notification as read.
Rename a tag. All notes with the old tag name will have it updated.
Restore a note from trash.
Search notes by keyword or phrase. Returns matching notes with snippets.
Share a note with another user or make it public.
Remove a share from a note.
Update a folder's name or icon.
Update a note. Can change title, content (HTML), folder, or tags. Set folderId to null to unfile.
Update the permission level of a share.
Update a task. Can change title, description, status, priority, due date, folder, or tags.
Update a task link's URL or title.
Tool composition risk: notez_update_note and notez_update_task require full tag replacement (description: 'REPLACES all existing tags'). This forces agents to read the note first, merge tags, then write back, a multi-step pattern that risks race conditions and wastes tokens. Consider add_tag and remove_tag variants.
No permission or security declarations. Tools like notez_share_note and notez_delete_note do not declare required permissions (e.g., 'write:notes', 'share:notes'). No evidence of permission gates or audit logging in tool definitions.