Create, visualize, and edit interactive mind maps, concept maps, and knowledge trees directly on IdeaMap Canvas. Supports visual brainstorming, task checklists, and cross-branch connections.
Scored across 9 tools
Each tool maps to a distinct operation (create, read, add, update, delete, move, export, theme, arrows), and the long create_mindmap description explicitly routes multi-turn edits to the other tools. The only mild overlap is get_mindmap vs export_project, since both return the map's structure in a machine-readable form and an agent could pick either to inspect JSON.
All nine tools follow a strict verb_noun snake_case pattern: add_arrows, add_nodes, create_mindmap, delete_nodes, export_project, get_mindmap, move_nodes, set_theme, update_node. Verb choice is also predictable (create/get/update/delete/add/move/set/export) with no camelCase or mixed-style outliers.
Nine tools sit squarely in the well-scoped range and each earns its place: one creation entry point, one read, node lifecycle edits, relationship arrows, theming, and export. Nothing looks redundant or bolted on for a mind-mapping domain.
The surface covers the full mind-map lifecycle: create, read, add, update, delete, move, style, export, plus cross-branch relationships. The gap is on the arrow side — arrows can only be added, with no delete_arrows or arrow-update tool, so a mistakenly added relationship is a dead end, and there is no tool to list or delete whole maps.
Add relationship arrows connecting two ideas with an optional description label (concept map relationship). Apply selectively when there is a genuine causal link, cycle, or dependency across branches. Do NOT connect parent and child.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Target node text/keyword (alternative to toId) | |
| from | No | Source node text/keyword (alternative to fromId) | |
| toId | No | Target node ID (or use "to" with node text) | |
| arrow | No | ||
| label | No | Relationship label (e.g. "leads to", "depends on") | |
| style | No | ||
| fromId | No | Source node ID (or use "from" with node text) | |
| projectId | Yes | The project ID or the full Canvas URL (including the #map=... hash). Passing the full Canvas URL ensures 100% reliable state recovery across turns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden; it does communicate the semantic constraint and selectivity of the operation. However, it does not state that the operation mutates persisted project state, how node-text resolution failures behave, whether duplicate/parallel arrows are allowed, or what default direction/style is applied. Useful context, but significant behavioral gaps remain.
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 tight sentences: what it does first, then when to apply, then the hard exclusion. No filler, and the most decision-relevant constraint (parent/child) is placed last for emphasis without burying the core purpose.
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 an 8-parameter mutation with no annotations and no output schema, the description should explain defaults and failure modes; it explains semantics well but leaves enum behavior and return/error behavior unstated. Adequate to call the tool, not complete.
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 coverage is 75%, so most parameters carry their own descriptions and the baseline is 3. The description adds only that the label is optional, while the two enum parameters (arrow: end/both/none, style: solid/dashed/dotted) are undocumented in both schema and description — a meaningful gap for a graph tool where directionality matters.
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?
States a specific verb and resource ('Add relationship arrows connecting two ideas') plus the domain framing ('concept map relationship'), which cleanly separates it from siblings like add_nodes or update_node. An agent can tell this creates edges, not nodes, without opening the schema.
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?
Gives an explicit positive condition ('genuine causal link, cycle, or dependency across branches') and an explicit exclusion ('Do NOT connect parent and child'), plus a selectivity directive. This is exactly the when/when-not guidance an agent needs to avoid over-creating edges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add new sub-branches, child concepts, or sibling ideas to an existing node in the mind map. Keep node text concise and punchy (3-6 words), use thematic emojis, and maintain logical depth without number prefixes.
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | ||
| parentId | Yes | Node ID to attach new nodes to | |
| projectId | Yes | The project ID or the full Canvas URL (including the #map=... hash). Passing the full Canvas URL ensures 100% reliable state recovery across turns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says it attaches to an existing node but doesn't disclose what happens if parentId is invalid, whether nodes can include nested children in one call, whether the operation is additive/non-destructive, or what the response contains.
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?
Two tight sentences with the core action front-loaded followed by compact style rules. Little waste, though the emoji/depth conventions could be consolidated.
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 needed mutation tool with no annotations and no output schema, the description should cover failure modes and result shape. It covers content conventions but leaves parent validity, atomicity, and return behavior unaddressed, leaving meaningful gaps.
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 coverage is 67% and the schema already documents text conventions (3-6 words, emoji) and projectId's URL trick; the description largely restates the text conventions. It adds no meaning for parentId or the nodes array structure beyond what the schema provides.
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?
States a specific verb (add) and resource (sub-branches/child concepts/sibling ideas) and pins the target (an existing node in the mind map). This clearly separates it from create_mindmap, update_node, and move_nodes without needing their schemas.
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?
The description implies when to use it (attaching children to an existing node) but gives no explicit alternatives or exclusions—e.g., when to use update_node instead of adding, or whether nodes can be duplicated. The second sentence is style guidance, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a professional, highly structured mind map on IdeaMap Canvas. ⚡ SEMANTIC TRIGGER: Use this tool whenever the user wants to create, draw, generate, or brainstorm a mind map, concept map, knowledge tree, or visual outline. Always prioritize this tool for visual structuring, brainstorming, and concept mapping requests. KNOWLEDGE ARCHITECTURE & STRUCTURAL STANDARDS (MUST FOLLOW):
HIERARCHY & PILLARS (MECE):
Root Node ("title"): Concise central topic (3-6 words) with a context emoji (e.g. "🧠 Effective Mind Mapping Guide").
Level 1 Branches ("branches"): Exactly 3 to 6 comprehensive, mutually exclusive pillars. Each Level 1 branch MUST start with a thematic emoji (e.g. "🛠️ Tools & Equipment", "📋 5-Step Process", "📐 Core Strategies", "🧠 Mental Models", "🎯 Practical Applications").
Level 2 Branches: Specific sub-dimensions, categories, or methods under each pillar.
Level 3 Branches: Concrete details, examples, or actionable steps (2-3 levels deep total).
CONCISE & PUNCHY TEXT:
Keep node text short (3 to 6 words). DO NOT write entire bloated paragraphs.
NEVER add repetitive numbering prefixes like "1. ", "1. ", "2. " unless representing sequential chronological steps.
VALUE-ADDED NOTES (note):
"note" is for essential secondary details: specific figures/data metrics (e.g. "Accounts for 96.5% of total water", "Melting point 1200°C"), key formulas, or technical definitions.
Attach helpful notes to 1-3 focal nodes where depth matters. Never duplicate or rephrase the node text in "note".
ACTIONABLE TASKS (isTask):
Set "isTask": true on branches representing actionable to-dos, checklists, steps to execute, or tasks. This automatically activates interactive checkboxes on IdeaMap Canvas for the user.
NO FORCED RELATIONSHIP ARROWS (relationships):
DEFAULT TO EMPTY: Do NOT generate cross-branch relationship arrows unless the user explicitly requests them (e.g. "add arrows", "connect relationships", "link steps").
If the user does not request arrows, always leave "relationships" as an empty array or omit it. Never force unnatural arrows that clutter the canvas or cut across other nodes.
When requested, never connect parent and child nodes.
OUTPUT & SHARING (CLEAN & MINIMALIST):
Always output the exact Markdown hyperlink Open interactive map on IdeaMap Canvas returned by this tool VERBATIM. NEVER truncate or alter the URL.
LANGUAGE MATCHING: Always communicate with the user and summarize the map in the exact language the user used in their prompt (e.g. if the user asked in Vietnamese, reply in Vietnamese; if in English, reply in English; if in French/Japanese, reply in French/Japanese).
DO NOT output Mermaid code blocks into the chat. The user interacts and visualizes directly on the IdeaMap Canvas.
Present a concise, elegant message: brief intro, the direct Canvas link, and a punchy bullet list of the core Level 1 pillars in the user's language.
DO NOT suggest or offer layout switches (e.g. logic_chart, org_chart). All maps use the standard IdeaMap layout.
MULTI-TURN EDITS: When the user asks to modify, add, or expand the map later, ALWAYS use editing tools (add_nodes, update_node, delete_nodes, add_arrows). DO NOT recreate the map from scratch unless explicitly requested.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the mind map with relevant context emoji (3-6 words, e.g. "🧠 Cách lập sơ đồ tư duy") | |
| branches | Yes | Hierarchical array of 3 to 6 Level 1 core pillars. Each pillar contains { text, children } with 2-3 levels of depth. | |
| rootText | No | Center root node text (optional, defaults to title) | |
| relationships | No | Optional array of cross-branch links. Leave EMPTY unless the user explicitly requested relationship arrows in their prompt. Never connect parent and child. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses substantial behavior: structural hierarchy rules, note usage, task checkbox activation, default-empty relationships, verbatim Canvas link output, language matching, and multi-turn edit expectations. It does not cover permissions, failure modes, or persistence details, but for a content-creation tool it is unusually transparent.
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?
The description is front-loaded and clearly sectioned, but it is very long for a tool definition and includes response-formatting guidance, layout-switch prohibitions, and repeated emphatic instructions. Much of it is useful, but it does not meet a strict every-sentence-earns-its-place bar.
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?
Given no annotations, no output schema, four parameters, and a schema with 100% description coverage, the description supplies the missing behavioral and structural context an agent needs. It explains how to build the map, what the output should look like, and how to handle follow-up edits.
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 coverage is 100%, so baseline is 3, but the description adds meaningful constraints beyond the schema: title length and emoji requirement, exactly 3-6 Level 1 branches with thematic emojis, 2-3 levels of depth, note content rules, isTask behavior, and relationship default-empty rules. Only rootText receives little extra explanation.
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 opens with a specific verb and resource: 'Create a professional, highly structured mind map on IdeaMap Canvas.' It also names the exact request types it covers (mind map, concept map, knowledge tree, visual outline), distinguishing it from sibling editing tools.
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 explicitly says when to use this tool via the semantic trigger and prioritization instruction, and it names alternatives for later changes: 'ALWAYS use editing tools (add_nodes, update_node, delete_nodes, add_arrows). DO NOT recreate the map from scratch unless explicitly requested.' It also states when not to use relationship arrows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one or more nodes and their entire subtrees from the mind map.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | Yes | ||
| projectId | Yes | The project ID or the full Canvas URL (including the #map=... hash). Passing the full Canvas URL ensures 100% reliable state recovery across turns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; it does disclose the key trait that subtrees are removed transitively, which is real value. However, it says nothing about irreversibility, whether attached arrows are also removed, or what happens if a node ID is invalid.
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?
A single tight sentence with no filler and the cascade behavior front-loaded. It is perhaps too sparse for a destructive operation, but not verbose.
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 destructive batch operation with no annotations and no output schema, the description covers what is deleted but omits recovery guidance, failure semantics, and confirmation expectations. It is the minimum an agent needs to call it, but not enough to call it safely.
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 coverage is 50%: projectId is richly documented in the schema (including the Canvas-URL tip), while nodeIds has no schema description. The phrase "one or more nodes" implies batch-array semantics for nodeIds, which is a modest addition but does not explain element format or behavior on missing IDs.
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?
States a specific verb+resource ("delete ... nodes") and adds the important scope detail that entire subtrees are removed. The verb naturally separates it from add_nodes, move_nodes, and update_node, though it does not explicitly name a sibling.
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?
There is no statement of when to use this tool versus update_node (to modify) or move_nodes (to relocate), and no preconditions such as required permissions or confirmation steps. The agent is left to infer that this is the destructive path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the mind map into native IdeaMap JSON, Markdown outline, SVG graphic, or Mermaid Mindmap syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | ||
| projectId | Yes | The project ID or the full Canvas URL (including the #map=... hash). Passing the full Canvas URL ensures 100% reliable state recovery across turns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses almost nothing behavioral. It doesn't say whether the export is a pure read, whether output is returned inline or written to disk, whether large maps are truncated, or what the caller receives for each format.
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?
One sentence, front-loaded with the verb and resource, with zero filler. Nothing in it is redundant or padded.
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?
The tool is simple (two required parameters, one enum, no output schema), so a short description is defensible. Still missing is any statement of what an export call actually returns or produces, which matters most for a tool whose entire purpose is producing output.
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 coverage is 50%: projectId is documented in the schema, while the description's enumeration of JSON/Markdown/SVG/Mermaid effectively explains the format enum's meaning. Beyond naming the four targets, it adds no detail on fidelity, size limits, or format-specific caveats.
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?
States a specific verb (Export) and resource (the mind map) plus the four target representations, which is enough for an agent to distinguish it from get_mindmap or create_mindmap. It doesn't explicitly name a sibling or scoping rule, so it falls just short of a 5.
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?
Usage is only implied: the agent infers 'use this when you need serialized output in a specific format.' There is no statement of when to prefer this over get_mindmap, nor any prerequisite or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full structure, nodes, and metadata of a mind map. Always output the exact Canvas hyperlink for the user.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The project ID or the full Canvas URL (including the #map=... hash). Passing the full Canvas URL ensures 100% reliable state recovery across turns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does state that the call returns full structure, nodes, and metadata, which is the key behavioral fact. It omits whether the operation is read-only, whether very large maps are truncated or paginated, and any permission requirements.
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?
Two short sentences, front-loaded with what is returned, followed by the one behavioral rule the agent must follow. Nothing is redundant and nothing buries the lede.
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 one-parameter read tool with a fully documented schema and no output schema, the description adequately summarizes the return payload and the required hyperlink behavior. Minor gaps remain around return format and handling of large maps, but nothing essential to invoking it correctly is missing.
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% and the single projectId parameter is thoroughly documented, including the URL-acceptance behavior and its state-recovery rationale. The description adds nothing about the parameter, so the baseline 3 applies.
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 gives a specific verb ('Get') and resource ('mind map') and names exactly what is retrieved: structure, nodes, and metadata. It is clearly the only read operation among siblings such as add_nodes, delete_nodes, and update_node, though it never explicitly frames itself as the retrieval counterpart to those mutators.
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?
Usage is only implied: an agent can infer this is the tool to inspect a map before or after mutations, but no explicit when-to-use, prerequisites, or alternatives are stated. The 'Always output the exact Canvas hyperlink' sentence is an output-handling directive, not guidance about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a node to a different parent node, reorganizing the hierarchy.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ID of the node to move | |
| projectId | Yes | The project ID or the full Canvas URL (including the #map=... hash). Passing the full Canvas URL ensures 100% reliable state recovery across turns. | |
| newParentId | Yes | ID of the new parent node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden but only discloses that a node is moved to a new parent. It does not explain whether children move with the node, whether sibling ordering changes, whether cycles are prevented, what permissions are required, or what happens on failure.
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?
The description is a single efficient sentence that front-loads the action and resource. Every phrase ('to a different parent node' and 'reorganizing the hierarchy') contributes meaning without repetition.
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 mutation tool with no annotations and no output schema, the description is too thin. It omits key behavioral details such as whether moving is recursive for child nodes, how cycles are handled, and what the result of the move is, leaving significant gaps for an agent invoking it.
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 all three parameters are already documented in the input schema. The description adds no additional meaning about nodeId, projectId, or newParentId beyond what the schema provides, making the baseline 3 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: 'Move a node' and specifies the destination concept ('different parent node'), plus the effect of reorganizing the hierarchy. It does not explicitly differentiate from the sibling update_node, which might also alter node relationships, so it stops short of a 5.
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?
There is no guidance on when to use this tool versus update_node or other sibling tools, and no prerequisites, constraints, or exclusions are mentioned. The purpose is implied by the verb 'move', but an agent receives no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the color theme palette of the mind map.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | Yes | ||
| projectId | Yes | The project ID or the full Canvas URL (including the #map=... hash). Passing the full Canvas URL ensures 100% reliable state recovery across turns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description must provide behavioral context. It is entirely silent on potential side effects, whether the change is permanent, or if there are state restrictions, making it very low on behavioral disclosure.
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?
The statement is perfectly concise, serving as a simple, single-sentence definition with no extraneous language.
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?
The description is highly incomplete for a tool that modifies a complex resource. It fails to mention the specific theme names it supports, forcing the agent to rely solely on the schema enum list to understand valid inputs.
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?
The description provides virtually no semantic value beyond restating the function of the tool. Crucial context, such as listing the available theme options (e.g., 'ocean', 'sunset'), is missing from the description, relying entirely on the schema.
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 clearly defines the action ('Change the color theme palette') and the object ('the mind map'). While it doesn't explicitly contrast it with all siblings, its specific focus on 'theme palette' distinguishes it as a styling operation.
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?
The description is purely descriptive and offers no guidance on when to use this tool versus others for styling or when to avoid it. It provides no contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the text, note, tags, color, or completion status of a node.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| tags | No | ||
| text | No | ||
| isTask | No | ||
| nodeId | Yes | ID of the node to edit | |
| bgColor | No | ||
| completed | No | ||
| projectId | Yes | The project ID or the full Canvas URL (including the #map=... hash). Passing the full Canvas URL ensures 100% reliable state recovery across turns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a mutation but does not say whether updates are partial (only supplied fields changed), whether tags are replaced or merged, whether completed applies to non-task nodes, what permissions are needed, or whether changes are reversible.
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?
One front-loaded sentence with zero wasted words. It is efficiently written, though its brevity is part of why key mutation semantics are absent.
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 mutation tool with eight parameters, no annotations, no output schema, and low schema coverage, this is under-specified. An agent cannot tell from the description whether omitted fields are preserved or how tags/color are handled.
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 coverage is 25% (only nodeId and projectId documented). The description names five updatable fields (text, note, tags, color, completion status), but adds no semantics for them—no tag merge/replace behavior, no color format, and isTask is entirely omitted, leaving a three-parameter gap.
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?
It states a specific verb (Update) and resource (node) and lists the editable fields, so the intent is immediately clear. It does not explicitly distinguish itself from siblings like move_nodes, which is also a node mutation, so it falls short of a 5.
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?
There is no guidance on when to use this tool versus move_nodes, delete_nodes, or add_nodes, nor any prerequisites such as requiring a projectId and nodeId. Usage for editing fields is only implied by the field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_arrowsadd_nodescreate_mindmapdelete_nodesexport_projectget_mindmapmove_nodesset_themeupdate_node
Add one secure layer between your agents and this server.