fenbs_list_items

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

With no annotations, the description carries the full behavioral burden. It discloses only that this is a filtered listing; it says nothing about the required 'board' argument's role, result size or pagination, ordering, or whether hidden/done items are included by default. For a 7-parameter list tool with no safety annotations, that is a significant 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?

Two tightly written sentences, front-loaded with the core action and scope; the parenthetical terminology clarification is high-value and the filter list is compressed into a single clause. No filler.

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 board-scoped list tool with no output schema and no annotations, the description covers what the tool does and what can be filtered, but omits pagination/result-size behavior and the meaning of the mandatory board parameter. Adequate but with clear gaps for an agent that needs to know what comes back.

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 86%, so the schema already documents board slug, lane keys, project, category, q, and flag semantics. The description's filter list largely restates those dimensions and adds nothing about the required board parameter or the flag filter. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource (list tasks on a board) and disambiguates terminology by noting that a task is called an 'item' in this API, which matters given sibling names like fenbs_get_item and fenbs_create_item. It does not, however, name which sibling to prefer when the agent wants a cross-board or filtered search rather than a board listing.

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 enumeration of filter dimensions ('by lane, kind, project, category or free text') implies when the tool is useful, but there is no explicit when-to-use vs. alternative guidance despite siblings such as fenbs_search, fenbs_list_boards, and fenbs_get_item that overlap in intent. Usage is inferable but not routed.

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