add_kanban_card_tool

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

No annotations provided, so the description carries full burden. It discloses performance (<500ms for 1000 cards), card format details, and that it preserves existing board structure. While it could mention conflict handling or authentication, it provides sufficient behavioral context for an add operation.

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 well-structured with clear sections (card format, when to use, performance, returns). It is slightly verbose but each sentence adds value, and it avoids redundancy with the schema.

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 complexity (8 parameters, no output schema), the description covers purpose, usage, performance, and return format. It lacks details on optional parameters like due_date format but schema covers those. It is complete enough for an add operation tool.

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 88% (high), so baseline is 3. The description adds general context about optional metadata and insertion position but does not significantly elaborate beyond what the schema provides for each parameter.

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 explicitly states 'Add a new card to a Kanban board column' and details the card format, distinguishing it from sibling tools like create_task_tool or toggle_kanban_card_tool. It provides specific verb and resource with clear context.

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?

A 'When to use' section lists specific scenarios such as adding tasks to project boards and batch card creation. Although alternatives are not mentioned, the contexts are clear and practical.

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