A note-taking and knowledge management application with AI-powered chat agents that can create and edit notes
Menerio is a note management MCP server with 5 tools, all properly named with action verbs and comprehensive descriptions. Tool names (create_note, list_note_folders, append_to_note, insert_into_note, replace_in_note) follow verb_noun convention and are unambiguous. All tools have detailed descriptions (145 - 340 chars) that explain WHAT, WHEN, and the consequence of actions. All parameters are typed (string, array, boolean, enum) and have descriptions. Schemas are visible and structured. However, the implementation lacks error handling guidance (no recovery hints in descriptions), and the server transport is UNKNOWN from the provided artifacts. Output schemas are not explicitly documented, and there is no evidence of tool annotations (readOnlyHint, destructiveHint) despite destructive operations like replace_in_note. The definitions are solid but incomplete for production use.
Append markdown text to the END of the current note. Existing content is never touched. If the same text is already in the note, nothing is written.
Create a NEW note in the user's brain. Use this whenever the user asks you to save, write, capture, draft or make a note. It only ever adds a new note, and can never change or delete an existing one. If the user named a folder, call list_note_folders first so you place it in the folder they already have instead of making a near-duplicate.
Insert markdown text at a precise location in the current note without removing anything. Either give `after_text` (an exact snippet that already exists in the note — the new text goes right after it) or `at` ('start' or 'end').
List the folders that already exist in the user's notes. Call this before create_note whenever the user names a folder, so you reuse their exact folder instead of creating a near-duplicate with different capitalisation.
Replace an exact snippet of the current note with new text. `find` must occur exactly once. Use ONLY when the user explicitly asked to change or remove that text. If the replacement removes a substantial amount of text, pass confirm_delete: true.
Tool annotations missing for destructive operations. replace_in_note modifies and deletes content but lacks destructiveHint annotation, making it harder for LLMs to recognize the risk and request confirmation.
No error handling guidance in descriptions. Tools lack recovery hints such as 'If the note is not found, try list_note_folders first.' or 'If find text fails, check exact formatting.' LLMs have no actionable next step on failures.
Output schemas not documented. Tool descriptions state WHAT they do but not the structure of return values. LLMs cannot plan downstream actions without knowing whether responses include timestamps, note IDs, or success flags.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
append_to_note description states 'If the same text is already in the note, nothing is written' but does not clarify return value, does it return success, a duplicate-skip indicator, or an error? This is ambiguous for LLM reasoning.
insert_into_note and replace_in_note require EXACT text matching ('find' must occur exactly once, 'after_text' must occur exactly once) but descriptions do not guide LLMs on whitespace sensitivity, case sensitivity, or how to handle multiline text. This invites silent failures.
create_note description recommends calling list_note_folders first, but list_note_folders has no indication it should be called as a discovery step. The dependency is one-directional and not clearly marked.