Calories burned by a step count, and steps needed to walk off a food.
Scored across 2 tools
The two tools are inverse operations: steps_to_burn takes a calorie/food amount and returns steps, while steps_to_calories takes steps and returns calories. Their descriptions clearly specify the direction and example queries, but the similar 'steps_to_' prefix could cause momentary confusion for an agent skimming names.
Both tools follow the same snake_case 'steps_to_X' pattern, making the naming predictable and consistent. There is no mixing of conventions or verb styles.
Two tools is slightly below the typical 3–15 range, but for this very narrow calculator domain it is a reasonable minimum that covers both conversion directions. No tool feels redundant or out of place.
The server covers both directions of the steps/calories relationship for walking, including time estimates and weight input. Minor gaps exist (e.g., no food-calorie lookup, no distance-based output), but the stated scope is largely satisfied.
Use this when someone asks how many steps or how long a walk it takes to burn a food or calorie amount, such as "steps to burn a samosa", "how much walking to burn 1 roti" or "steps to burn 300 calories 75 kg". Do not use for running or gym workouts, children, eating-disorder questions, or medical exercise plans.
| Name | Required | Description | Default |
|---|---|---|---|
| food | No | A food: roti, samosa, rice, dal or paneer (or give kcal) | |
| kcal | No | Calorie amount to walk off, if not using a food | |
| pace | No | Walking pace, default normal | |
| height_cm | No | Optional height in centimetres for stride length | |
| weight_kg | Yes | Body weight in kilograms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), which this description correctly does not contradict. However, with no output schema present, the description never says what is actually returned (step count, walk duration, pace/stride assumptions), leaving the result shape entirely undisclosed.
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 trigger condition and immediately followed by the exclusions; no filler. The long embedded example list makes the first sentence slightly run-on but every clause carries information.
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 five-parameter, fully schema-documented tool with no output schema, the description covers invocation intent and domain limits well. The remaining gap is sibling disambiguation against steps_to_calories and any indication of what the tool returns.
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% with enums and ranges documented, so the baseline is 3. The description reinforces the food-vs-kcal choice and hints at combining weight with kcal ("300 calories 75 kg"), but adds no syntax or unit guidance beyond what the schema already states.
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 computation (steps or walking time to burn a given food or calorie amount) and illustrates it with realistic user phrasings. It never names its sibling steps_to_calories or explains that this tool is the reverse direction, so an agent must infer the boundary between the two.
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 explicit positive triggers with concrete example queries ("steps to burn a samosa", "how much walking to burn 1 roti") and explicit exclusions (running, gym workouts, children, eating-disorder questions, medical exercise plans). This is exactly the when/when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks how many calories a number of steps burns, such as "10000 steps calories burned 70 kg", "how many calories in 5000 steps" or "calories burned walking 8000 steps brisk". Do not use for running, cycling or gym workouts, children, or medical exercise plans.
| Name | Required | Description | Default |
|---|---|---|---|
| pace | No | Walking pace, default normal | |
| steps | Yes | Number of steps | |
| height_cm | No | Optional height in centimetres for stride length | |
| weight_kg | Yes | Body weight in kilograms |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
steps_to_burnsteps_to_caloriesKilocalories to kilojoules, number discarded
Daily calorie target to lose, keep or gain weight, plus a weight goal timeline.
Calories and nutrition for any food, chain meal or barcode, and meal ideas for a goal and diet.
Food logging, nutrition summaries, and meal photo calorie and macro estimates.
Add one secure layer between your agents and this server.