Verschiebt ein bestehendes Board in ein anderes Board (wird dessen Unter-Board; im Ziel entsteht eine Verweis-Karte). Mit target_board_id = 0 wird das Board wieder auf die oberste Ebene geholt. Nur Eigentuemer.
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | Das Board, das verschoben werden soll | |
| target_board_id | Yes | Ziel-Board (wird zum Eltern-Board); 0 = zurueck auf oberste Ebene |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key side effects: the board becomes a sub-board, a reference card is created in the target, and setting target_board_id=0 moves it to top level. It also states the permission requirement. This is thorough 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 description is three short sentences, each providing necessary information: the core action, the top-level exception, and the access constraint. No redundant or filler content, and key information is front-loaded.
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 the tool's moderate complexity (hierarchy change with side effects), the description fully covers what happens when moving a board, including the reference card creation, the top-level reset, and ownership requirements. No output schema exists, but for a mutation tool the description is sufficiently complete for correct invocation.
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% and both parameters have descriptions. The tool description adds no new parameter-specific meaning beyond what the schema already provides; it merely reinforces the target_board_id=0 behavior already documented. Thus a baseline score of 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 clearly states the action ('Verschiebt ein bestehendes Board') and the target resource ('in ein anderes Board'), distinguishing it from siblings like move_card. It also explains the resulting sub-board relationship and reference card, making the purpose explicit.
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 provides clear context for use: moving a board into another board or to the top level with target_board_id=0. It also states the owner-only restriction. However, it does not explicitly compare with sibling tools like move_card, but the resource differs enough that no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action (board, column, card, tracker, field, entry) with no overlapping purposes. Even closely related operations like add_card vs add_entry operate on different entity types.
Tool names consistently follow a verb_noun pattern (e.g., create_board, add_card, delete_entry, update_tracker). The mix of 'create' for top-level entities and 'add' for sub-entities is a minor deviation but still predictable.
24 tools is somewhat high but well-justified given the server covers two resource families (boards and trackers) with full lifecycle operations. Each tool has a clear role in the overall surface.
The tool set provides comprehensive CRUD coverage for boards, columns, cards, trackers, and entries. The main gap is the lack of an update_field tool, but this can be worked around by deleting and recreating fields.