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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so safety and purity are covered. The description adds genuine domain scope (walking only, no running/cycling/gym, not for children or medical plans), but says nothing about the estimation model, accuracy limits, or output units, so the added value is moderate.

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, zero filler: the first front-loads the purpose and trigger phrases, the second front-loads the exclusion boundary. Nothing is repeated from the schema or annotations.

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 deterministic calculation with 100% schema coverage and full safety annotations, the description covers purpose, triggers and exclusions adequately. The one gap is that with no output schema it never states what comes back (calories in kcal, presumably), though the title largely implies it.

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 the baseline is 3 and the schema already documents steps, weight_kg, height_cm and the pace enum. The example queries go slightly beyond that by showing how natural-language values map onto weight_kg ("70 kg") and pace ("brisk"), which helps an agent extract parameters from free-form requests.

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+resource (calories burned for a given number of steps) and reinforces it with three concrete example queries, so the agent immediately knows the computation performed. It does not, however, mention or distinguish itself from the sibling steps_to_burn, leaving the reverse-direction tool unaddressed.

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 gives clear positive triggers via realistic user phrasings ("10000 steps calories burned 70 kg", "how many calories in 5000 steps") and explicit exclusions (running, cycling, gym workouts, children, medical exercise plans). What is missing is a named alternative — it never says to use steps_to_burn for the inverse query — so it stops short of full when/when-not/alternatives guidance.

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