Skip to main content
Glama
Hackeatutiempo

Mapache

by Hackeatutiempo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Move a branch

move_node
Idempotent

Relocate a mind map node and its entire branch under a new parent, or reorder it among siblings by position. Saves instantly as a new board revision and updates live.

Instructions

Move a node, with its whole branch, under another parent (in the same board), or reorder it among its siblings by giving its current parent and a new position. A node cannot go under itself or its own children. It is saved at once as a new revision of the board and appears live in any browser that has it open (the person can undo it with Ctrl+Z). Returns a confirmation.

Input Schema

NameRequiredDescriptionDefault
nodeYesThe node to move. Node id (from read_board), its exact text, or a path like "Central idea > Branch"
boardYesBoard id or title. Use "open" for the board the person has open in the app
parentYesNew parent node (id, text or path). Pass its current parent to only reorder it
positionNoIndex among the new siblings, 0 = first (default: last)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.3
    • changedInput schema / properties / node / description
      Previous value: -"Node id (from read_board), its exact text, or a path like \"Central idea > Branch\""New value: +"The node to move. Node id (from read_board), its exact text, or a path like \"Central idea > Branch\""
    • changedInput schema / properties / parent / description
      Previous value: -"New parent node"New value: +"New parent node (id, text or path). Pass its current parent to only reorder it"
    • changedInput schema / properties / position / description
      Previous value: -"Index among the new siblings (default: last)"New value: +"Index among the new siblings, 0 = first (default: last)"
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: the change is saved immediately as a new board revision, appears live in any open browser, and is undoable via Ctrl+Z, and it returns a confirmation. Annotations (readOnly=false, destructive=false, idempotent=true) are consistent with an undoable mutation.

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

Conciseness5/5

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

Front-loaded with the core action and scoped parenthetically, then constraints, then side effects and return value. Every sentence carries information and nothing is padded.

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

Completeness5/5

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

With no output schema and full annotation coverage, the description still supplies the persistence model, live-update effect, undo path, and return value. An agent has everything needed to invoke and reason about the call.

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 coverage is 100% and each parameter already documents its accepted forms (id, text, path; board id/title/'open'; position index semantics). The description reinforces the parent/position reorder relationship but adds no syntax or meaning beyond the schema, so baseline 3 applies.

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

Purpose5/5

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

States a specific verb (move) plus resource (node/branch) and scope (under another parent in the same board, or reorder among siblings). This clearly separates it from add_nodes, update_nodes, and delete_nodes, so an agent can identify it 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.

Usage Guidelines4/5

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

Explains the two modes of use (reparent vs. reorder via current parent + new position) and states the important constraint that a node cannot go under itself or its own children. It does not explicitly name an alternative tool, but the usage context is unambiguous.

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

Deploy Server

Other Tools