pace-calculatorGiven any two of distance, total time, or pace-per-mile, calculate the third. Returns pace per mile, per km, splits, and speed.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Which field to solve for. | |
| totalSeconds | No | Required for mode "pace" or "distance". | |
| distanceMiles | No | Required for mode "pace" or "time". | |
| paceSecondsPerMile | No | Required for mode "time" or "distance". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and non-destructive hints. The description adds meaningful behavioral context by specifying the outputs (pace per mile/km, splits, speed), which goes beyond the annotations. No contradictions.
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 concise sentences, front-loaded with the primary function and output summary. No filler words or redundant 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?
Given the simplicity of the calculator tool and the rich schema, the description is sufficiently complete. It lists the key outputs and clarifies the input relationships, though it does not cover edge cases like zero values, which are unlikely to be required.
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?
The schema covers all parameters with descriptions, so the baseline is 3. The description adds semantic meaning by explaining the interdependency of the parameters (any two determine the third), which is not apparent from the schema alone.
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 clearly states the tool's purpose: given any two of distance, time, or pace, it calculates the third. This specific verb+resource combination distinguishes it from siblings like race-time-predictor.
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 core usage rule (any two inputs to compute the third), but it does not explicitly state when to use this tool over alternatives or mention exclusions. Sibling tools like fueling-plan or race-time-predictor are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, but heat-adjustment and hydration both estimate fluid needs based on temperature and humidity, which could cause an agent to select the wrong one. The other tools (carb-loading vs fueling-plan, pace-calculator vs race-time-predictor) are well-differentiated by their pre-race vs during-race and basic vs predictive focus.
All tool names are lowercase and use hyphens to join words (e.g., carb-loading, fueling-plan). The pattern is consistent and predictable, with no mixing of camelCase, snake_case, or other conventions. Even 'hydration' fits as a single-word name matching the overall simplicity.
Seven tools is a well-scoped set for a running-fueling domain. Each tool addresses a distinct aspect of race preparation and execution, and none feel redundant or unnecessary. This is squarely in the optimal 3-15 range.
The tool surface covers the full pre-race and race-day fueling workflow: pace/race-time prediction, fueling plan generation, hydration, heat adjustment, carb-loading, and gel selection. No obvious gaps exist for the stated purpose of creating and refining race fueling strategies.