Loading ToolBench
MCP server for interacting with Evernote notebooks and notes
The Evernote MCP server has well-chosen tool names following the verb_noun pattern (list, read, create, update, count), but suffers from significant gaps in parameter documentation and inconsistent output schema declaration. All 7 tools are explicitly registered with names and descriptions. However, only 2 of 7 tools have documented output schemas (list_evernote_notebooks and list_evernote_notes via z.object definitions). The remaining 5 tools (count_evernote_notes, read_evernote_note, read_evernote_notes, create_evernote_note, update_evernote_note) lack declared outputSchema fields, their actual return structures are only visible in the implementation, not the registered schema. This violates the critical rule that 'tools returning structured output must document the output schema so LLMs know what fields to expect.' Parameter descriptions are completely absent from all tools, input parameters lack human-facing guidance on format, constraints, or semantics. The long description for list_evernote_notes is run-on text concatenated without punctuation, making it hard for LLMs to parse. No tools provide error guidance, recovery hints, or actionable error messages. The server lacks basic validation (e.g., validating enum values for 'order' parameter, checking guid format). No tool declares destructive/idempotent hints despite having read-only vs write tools. Security: the Evernote client is initialized at module scope with credentials injected via environment (correct pattern), but no per-tool scope declarations are present.
Count notes matching a filter.
Create a new evernote note.The content is in ENML (Evernote Markup Language).ENML is formally defined in http://xml.evernote.com/pub/enml2.dtd.
List evernote notebooks title and guid
List evernote notes title and guid.You can filter notes by following parameters:order: The NoteSortOrder value indicating what criterion should be used to sort the results of the filter.ascending: If true, the results will be ascending in the requested sort order. If false, the results will be descending.words: A search query string that will filter the set of notes to be returned. Accepts the full search grammar documented in the Evernote API Overview.notebookGuid: The Guid of the notebook that must contain the notes.tagGuids: The list of tags (by GUID) that must be present on the notes.timeZone: The zone ID for the user, which will be used to interpret any dates or times in the queries that do not include their desired zone information.inactive: If true, then only notes that are not active (i.e. notes in the Trash) will be returned. Otherwise, only active notes will be returned. There is no way to find both active and inactive notes in a single query.emphasized: A search query string that may or may not influence the notes to be returned, both in terms of coverage as well as of order. Think of it as a wish list, not a requirement. Accepts the full search grammar documented in the Evernote API Overview.includeAllReadableNotebooks: If true, then the search will include all business notebooks that are readable by the user. A business authentication token must be supplied for this option to take effect when calling search APIs.offset: The offset of the first note to return. This is useful for paging through results.maxNotes: The maximum number of notes to return. This is useful for limiting the number of results returned.
5 of 7 tools lack outputSchema declarations. Schemas are only visible in implementation code, not registered with the tool. LLMs cannot know what fields to expect without explicit schema documentation.
No input parameters across any tool have descriptions. Each parameter (guid, notebookGuid, order, words, tagGuids, etc.) lacks guidance on format, constraints, or valid values. LLMs cannot infer parameter semantics from names alone.
list_evernote_notes description is 780+ characters of run-on text (parameters concatenated with '+' operator, no punctuation). Exceeds the 10-1024 character baseline and becomes a wall of text that LLMs struggle to parse effectively.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Read evernote note content
Read multiple evernote notes content by an array of guids.
Update an existing evernote note.The content is in ENML (Evernote Markup Language).ENML is formally defined in http://xml.evernote.com/pub/enml2.dtd.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles. create_evernote_note and update_evernote_note modify state but lack destructiveHint annotations. read_* tools are safe but unmarked as read-only.
No error handling, recovery guidance, or validation. Tools do not document what happens on invalid input (e.g., non-existent guid, malformed notebookGuid, out-of-range offset). LLMs have no guidance on retry vs user correction.
Parameters lack constraints and validation rules. 'order' accepts a number with no enum values documented; 'offset' and 'maxNotes' accept unbounded numbers with no min/max constraints stated. LLMs may pass invalid values.
Pagination support is incomplete. list_evernote_notes accepts offset and maxNotes but does not return a total count or next_cursor, making it hard for LLMs to iterate through all results reliably.
No scope declarations (e.g., 'read:notes', 'write:notes') or permission gates. All tools assume full access; no guidance on required permissions or least-privilege configuration.