List chute sessions

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the meaning of PROPOSED (assistant-built, awaiting in-app confirmation) and ACTIVE (resumable draft), which tells the agent these are workflow-state artifacts. However nothing is said about pagination defaults, result ordering, or scope limits.

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 sentences, front-loaded with the core action and scope, and the status semantics are attached to the filter they describe. The parenthetical example list is slightly dense but earns its place by disambiguating the domain term.

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?

With no output schema, no parameter descriptions, and four parameters, the description should carry more weight. It defines the resource and the status filter well but omits pagination behavior (take caps at 200) and the farm_id scoping rule, which an agent needs to call this list 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 0% across 4 parameters, so the description must compensate. It fully documents the status enum values, which is the parameter most likely to be misused, but says nothing about skip/take pagination semantics or farm_id scoping, leaving half the surface undocumented.

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 chute-mode work sessions on the farm') and immediately defines what a chute session is with concrete examples (weigh days, preg checks, vaccinations). This distinguishes it from sibling list tools such as list_records, list_workflow_templates, and list_farm_tasks.

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 explains the purpose of the status filter and what each status means, which implies when the filter is useful, but it never states when to call list_chute_sessions versus get_chute_session or the other session-related siblings. Usage context is present but no explicit alternatives or exclusions are given.

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