create_list

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

The description discloses the behavioral consequence that cards placed in a 'closed' list will be closed by Planka, advising to use that type only for genuine done stages. This adds meaningful context beyond the annotations (readOnlyHint=false, destructiveHint=false) and the schema's parameter description.

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 just two sentences: the first states the tool's purpose, and the second provides a critical behavioral warning. It is concise, front-loaded, and every sentence earns its place.

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 simple create-list operation, the presence of an output schema, and full parameter schema coverage, the description covers the essential behavioral nuance (closed list behavior) without needing to explain return values or basic parameter mechanics. It is sufficiently complete for an agent to select and invoke the tool correctly.

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 parameters are already well-documented. The description's note about the 'closed' list type adds a behavioral caveat but does not significantly expand semantics beyond what the schema already states (e.g., 'closed (cards land here as finished)'). It also does not illuminate the 'after' or 'color' parameters beyond their schema descriptions.

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 ('Add a workflow stage to a project') with a specific resource (project) and implicit object (list). It distinguishes from sibling tools like create_board and update_list by focusing on workflow stages, though it does not explicitly name alternatives.

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?

No guidance is provided on when to use this tool versus alternatives such as create_board or update_list. The only usage-related note concerns the 'closed' list_type parameter, which is more about parameter selection than tool selection. There are no explicit prerequisites or exclusions.

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