Skip to main content
Glama

maimemo_create_notepad

Destructive

Create a cloud wordbook in Maimemo to organize vocabulary and study materials by providing a title, content, and tags.

Instructions

创建云词本

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes暂无文档
confirmYes用户已明确授权本次写入。须为 true。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it never mentions the mandatory user-authorization gate (confirm must be true), that retries are not idempotent, or what the write does. With annotations carrying the burden, the description earns only minimal credit for adding no new context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single line is not wasteful, but this is under-specification rather than conciseness. For a tool with a nested object payload and a write-authorization parameter, one sentence is far too thin to be considered appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a nested object schema, two required parameters, a destructive write annotation and no output schema. The critical behavioral fact that the agent must have explicit user authorization before setting confirm=true is nowhere in the description; it appears only inside the schema's field description, making the definition incomplete for a destructive operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3: title, brief, content, tags and the status enum are all documented in the schema itself. The description contributes no additional meaning about the nested body structure or the confirm flag, but it does not need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (创建云词本 / create cloud notepad), which is unambiguous on its own and lets an agent distinguish it from maimemo_update_notepad, delete_notepad, get_notepad and list_notepads. It does not explicitly name any sibling or clarify scope, which is what separates a 4 from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no statement of prerequisites, and no mention of how this differs from maimemo_update_notepad or maimemo_create_note. The agent must infer entirely from the name that this is for brand-new notepads.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.