Creates a new mind map after confirming the title with the user and verifying no matching map exists. Use it to add missing maps, optionally as TODO maps.
新しいマインドマップ(マップ)を1つ作成する。list_mapsで確認して該当するマップが無いときだけ呼ぶこと。呼ぶ前に、会話でタイトル案をユーザーに提示し、明示的な確認を得ること(自動判断で勝手に作成しない)。
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | マップのタイトル | |
| isTodo | Yes | TODOマップ(要素にチェックボックスを付ける)にするかどうか |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add real behavioral context: a mandatory user-confirmation step and an explicit prohibition on autonomous creation. It does not describe the success/duplicate/error behavior of the create itself, so it falls short of fully covering the write semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place, with the primary action stated first and the guardrails (list_maps check, user confirmation) following in priority order. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-required-parameter create tool with no output schema, the definition covers the purpose, precondition, and confirmation workflow. It is nearly complete, though it could note what happens on success or when a duplicate title is used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'title' and 'isTodo' are already documented in the schema, and the description adds no additional syntax or format detail beyond them. Per the baseline rule for high coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('新しいマインドマップを1つ作成する'), specifying cardinality ('1つ'). It is immediately distinguishable from siblings like list_maps, edit_element, or delete_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing rules: call only after list_maps confirms no matching map exists, and require a user-confirmed title proposal first. The alternative (list_maps) and the precondition are both named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.