kaiten_add_project_card

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only repeats the obvious mutating action. It does not mention permissions, idempotency, whether the card must already exist, what happens to existing project-card relationships, or the nature of the mutation beyond 'add'.

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, concise sentence with no filler or redundant wording. It is not poorly structured, though it is minimal to the point of omitting useful context.

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 mutating tool with no annotations, no output schema, and many closely related sibling tools, the description is too thin. It omits the key distinction from card-creation tools, does not explain the operation's effect on project membership, and provides no safety or prerequisite context.

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 schema already documents both parameters clearly ('Card ID to add' and 'Project ID'). The description adds no additional semantic value for the parameters, so the 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 states a clear action ('add') and resource ('card to a Kaiten project'), making the core operation understandable. However, it does not explicitly clarify that this adds an existing card to a project versus creating a new card, which would help distinguish it from siblings like kaiten_create_card.

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 no guidance on when to use this tool versus alternatives such as kaiten_create_card, kaiten_move_card, or kaiten_remove_project_card. There are no stated preconditions, exclusions, or context that would help an agent choose this tool correctly.

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