gel-comparisonReturn the FuelCenter gel catalog (SiS Beta Fuel, Maurten, Precision, GU, Tailwind, Spring, Carbs Fuel, neversecond, Huma) with carbs, price, caffeine, weight, and carbs-per-dollar. Optionally sort.
| Name | Required | Description | Default |
|---|---|---|---|
| sortKey | No | Column to sort by. Default "carbsPerDollar". | |
| sortDirection | No | Sort direction. Default "desc". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the description doesn't need to repeat that. It adds valuable scope context by listing the exact gel brands and fields returned, which clarifies the tool's output behavior beyond what annotations provide. No contradictions exist.
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?
The description is a single, well-structured sentence that front-loads the core action and includes necessary specifics (brands, fields, optional sorting). Every word adds value with no fluff or repetition.
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 read-only catalog tool with no output schema, the description adequately covers the return contents (brands and attributes) and optional sorting. It lacks details about return format or limitations, but the low complexity and rich annotations make this sufficient for agent selection and invocation.
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 coverage is 100% with both parameters (sortKey and sortDirection) having clear descriptions, defaults, and enums. The description only states 'Optionally sort', providing minimal added meaning. This matches the baseline for high schema coverage.
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 returns a specific resource (FuelCenter gel catalog) with a list of brands and fields. The verb 'Return' is specific and the description distinguishes it from planning tools by focusing on catalog data and sorting, rather than calculations or plans.
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?
Usage context is implied: you use this tool to get the gel catalog and optionally sort it. However, there is no explicit guidance on when to prefer this over siblings like fueling-plan or carb-loading, and no alternatives are mentioned. The description lacks direct 'use when' or 'use instead' phrasing.
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.