Loading ToolBench
MCP server for MaiMemo vocabulary learning platform, providing tools to manage interpretations, notes, notepads, phrases, and vocabulary
This MCP server has a respectable breadth of 18 tools for the MaiMemo vocabulary platform, but suffers from systematic gaps in input schema completeness and inconsistent parameter documentation. Most tools lack visible input schemas in the source code, only a subset (create_interpretation, update_interpretation, create_note, update_note, list_notepads, create_notepad, update_notepad, create_phrase, update_phrase) have schemas explicitly visible via jsonschema.For[...] calls. Tools like list_interpretations, delete_interpretation, list_notes, delete_note, get_notepad, delete_notepad, list_phrases, delete_phrase, and get_vocabulary lack visible input schema definitions in the provided code, which is a critical gap. Descriptions are present and reasonably detailed (average ~120 chars), exceeding the 10-char minimum and falling within the 10-1024 baseline, but several lack LLM-optimized clarity. Parameter descriptions are present but uneven, some parameters are well-documented (e.g. 'voc_id' in list_interpretations), while others rely on enum constraints without explanatory text. Error handling is minimal, the code shows `Err(err.Error())` calls but no structured guidance for recovery or classification. Tool naming follows verb_noun conventions consistently (list_, create_, update_, delete_, get_), which is a strength. No tool accepts natural identifiers (username, email), all require opaque IDs like voc_id, interpretation_id, note_id, phrase_id, notepad_id, forcing prerequisite lookup calls. Destructive operations are labeled with warnings but lack dry-run or confirmation patterns. Output schemas are inferred from structs (e.g., ListInterpretationsOutput) but are not explicitly documented in the tool registration. The server overall demonstrates domain competence but falls short of production-grade quality due to schema visibility, error guidance, and composition patterns.
为指定单词创建一个新的释义。成功后会返回新创建的释义对象。
为指定单词创建一个新的助记。成功后会返回新创建的助记对象。
创建一个新的云词本。成功后会返回新创建的云词本对象。
为指定单词创建一个新的例句。成功后会返回新创建的例句对象。
删除一个指定的释义。注意：这是一个不可恢复的危险操作，请谨慎使用。
删除一个指定的助记。注意：这是一个不可恢复的危险操作，请谨慎使用。
删除一个指定的云词本。注意：这是一个不可恢复的危险操作，请谨慎使用。
Nine tools lack visible input schemas in source code (list_interpretations, delete_interpretation, list_notes, delete_note, get_notepad, delete_notepad, list_phrases, delete_phrase, get_vocabulary). These tools have only Name and Description registered, no InputSchema field.
All tools require opaque system IDs (voc_id, interpretation_id, note_id, phrase_id, notepad_id) with no support for human-friendly identifiers (e.g., word spelling, user names). This forces prerequisite lookup calls and breaks the chat data model. E.g., list_interpretations requires voc_id but users naturally say 'show interpretations for hello', must call get_vocabulary first every time.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
删除一个指定的例句。注意：这是一个不可恢复的危险操作，请谨慎使用。
获取单个云词本的完整信息。返回的结果可用于 update_notepad() 工具。
通过拼写获取一个单词的核心信息，主要是它的唯一ID（voc_id）。这是执行其他需要 voc_id 操作（如 list_interpretations()）的前置步骤。
获取指定单词下所有自己创建的释义列表。
查询云词本列表，支持分页。
获取指定单词的所有助记列表。
获取指定单词的所有例句列表。
全量更新一个已有的释义。重要：由于 API 限制，此操作流程固定：1. 调用 get_vocabulary() 获取 voc_id。2. 调用 list_interpretations() 获取所有释义。3. 在本地修改后调用本工具。如果用户只提供 interpretation_id，你必须向用户询问该释义所属的单词。
全量更新一个已有的助记。重要：操作流程类似于更新释义，需要先获取再更新。如果只提供 note_id，必须向用户询问其所属单词。
全量更新一个已有的云词本。注意：这是一个全量替换操作，必须提供云词本的所有字段。推荐的操作流程是：1. 先使用 get_notepad() 获取云词本的当前完整信息。 2. 在获取到的信息基础上修改（例如增删单词）。 3. 使用修改后的完整对象调用本工具。
全量更新一个已有的例句。重要：操作流程类似于更新释义，需要先获取再更新。如果只提供 phrase_id，必须向用户询问其所属单词。
Destructive operations (delete_interpretation, delete_note, delete_notepad, delete_phrase) warn 'not recoverable' but lack confirmation/dry-run patterns. Agents make mistakes, no way to preview or confirm before executing irreversible actions.
Error handling is minimal. Code shows `Err(err.Error())` returning raw error messages (e.g., 'network timeout', '404 not found') with no guidance on recovery. Errors are not classified as retryable, user-fixable, or fatal. LLM has no actionable next step.
Output schemas are not explicitly documented. Tools return structs (ListInterpretationsOutput, etc.) but these are not visible in tool registration. LLMs cannot see expected response fields to plan downstream calls.
Tool descriptions for read-only list tools (list_interpretations, list_notes, list_phrases, list_notepads) lack clarity on pagination behavior, result limits, and when to use them. E.g., 'Get all interpretations' is vague, does it paginate? How many max results? Description should state limit and pagination strategy.
Enum constraints in parameter descriptions are presented as 'itemEnum' in JSON Schema but text descriptions do not enumerate valid values. LLMs may not parse itemEnum from schema, they rely on description text. E.g., create_notepad 'tags' param lists 20 enum values in code but description says only 'tags array', needs explicit list in description.
Multi-step workflows (e.g., 'to update interpretation, call get_vocabulary first, then list_interpretations, then update') are documented in descriptions but not enforced. No discovery or help tools to guide agents through these chains. Agents must infer the sequence.