commit_count

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

With no annotations, the description carries the full burden and does well: it discloses the clustering input, lidar-based deduplication, the publish target, and the fact that geometry rather than a parameter determines the result. It stops short of describing stateful details such as whether looks are consumed or reset, but these are not critical for a zero-parameter tool.

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?

Three short sentences, with the core action first and supporting clarifications after. Every sentence adds value and the '4, not 8' example is worth more than a longer explanation.

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?

The tool is simple enough that this description is nearly complete: input is empty, output schema already exists, and the dedup behavior is explained. The only gap is not making the prerequisite explicit ('call this after completing count_in_view looks'), though that is strongly implied by the first sentence.

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?

There are no parameters, and the description adds a meaningful clarification that the count is not passed by the caller ('You do not pass the number — geometry does'). This goes beyond the empty schema by explaining why the schema is empty, so the baseline-4 case is fully met.

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 names a precise operation ('Cluster every count_in_view look by lidar position') and a concrete output ('publish one integer on /numerical_response'). The dedup example ('4, not 8') makes the behavior unmistakable and distinguishes it from a raw counter like count_in_view.

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?

It clearly situates the tool after one or more count_in_view looks and tells the agent not to supply a count ('You do not pass the number'). It does not explicitly name excluded alternatives, but the context is clear enough for an agent to know this is the aggregation/dedup step.

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