kanbn_contributor_warnings

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Find' weakly implies a read-only operation, but the description does not explicitly state that it makes no modifications, does not explain how 'known contributor' is determined, and does not mention any configuration or data dependencies. For an unannotated tool this is a meaningful gap.

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?

A single sentence with zero filler, front-loaded with the action ('Find tasks') followed by the precise condition. Every word earns its place; nothing is redundant or missing from a conciseness standpoint.

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 simple one-parameter query tool, the description adequately conveys the core purpose, and the schema covers the input. However, with no output schema and no annotations, the description fails to disclose the return shape (tasks? warnings? counts?) or what defines a 'known contributor', leaving an agent to guess at the result format.

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% — the single 'path' parameter is already documented as 'Path to the project root directory'. The description adds nothing about the parameter, but the schema fully handles it, so the baseline 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 specific verb and resource — 'Find tasks' — and gives the precise filter condition: assigned user or comment author is not a known contributor. This is clear and specific enough to convey what the tool does, though it does not explicitly name or distinguish itself from siblings like kanbn_get_contributors, kanbn_find_contributor, or kanbn_contributor_usage.

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 given about when to use this tool versus alternatives such as kanbn_contributor_usage, kanbn_get_contributors, or kanbn_find_contributor, nor any exclusions or prerequisites (e.g., whether a contributor list must first be configured). Usage is only implied: it appears to be a diagnostic/audit operation.

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