TrainingPeaks-MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.1.3
Disambiguation4/5
Most tools target a distinct resource and action, and descriptions clearly separate overlapping concepts like workout notes vs. comments and cardio vs. strength workouts. A few pairs (tp_get_workout vs. tp_get_strength_workout, tp_get_workout_note vs. tp_get_note_comments) require careful reading, but no tools appear to do exactly the same thing.
Naming Consistency4/5
The vast majority follow a consistent tp_verb_noun snake_case pattern (e.g., tp_get_workouts, tp_update_ftp, tp_delete_equipment). Minor exceptions like tp_auth_status and tp_log_metrics break the pattern slightly, but the overall convention is highly predictable.
Tool Count2/5
85 tools is far beyond the typical well-scoped MCP server and even for a broad platform this creates a significant navigation burden. While each tool may have a legitimate purpose, the sheer number makes it difficult for an agent to efficiently discover and select the right tool.
Completeness4/5
The tool surface is extremely comprehensive, covering workouts, strength training, events, notes, equipment, libraries, groups, metrics, and more. Minor gaps exist, such as no training plan creation/editing and no per-template library deletion, but these are workable and do not create dead ends for most coaching workflows.
Average 3.9/5 across 85 of 85 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 37 of 40 community issues answered or closed in the last 6 months
- 43 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows it's a non-read-only, non-destructive operation. However, the description adds no behavioral context beyond that—it does not mention what happens to existing zones, whether the update is a full replacement, or any side effects, which is a gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is extremely brief, but this is under-specification rather than conciseness. It provides no more information than the title and fails to earn its place by adding any useful detail for a tool with five parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with five parameters and no output schema, yet the description gives no information about parameter interactions, what 'updating zones' entails, or return behavior. It is completely inadequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'athlete' is described). The description itself mentions no parameters, leaving max_hr, resting_hr, threshold_hr, and workout_type completely unexplained. Since there is low schema coverage and no parameter information in the description, the agent cannot understand how to use these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('update') and the resource ('heart rate zones'), making it specific enough to know what the tool does. However, it does not distinguish itself from sibling tools like tp_create_zones or tp_update_speed_zones beyond the explicit resource name, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. The only contextual clue is the 'athlete' parameter description in the schema, but that is not part of the tool description and does not explain when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds no extra behavioral context (e.g., irreversibility, associated data effects, permissions), providing value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of fluff, but it is under-specified. It does not provide enough context to be considered appropriately structured; it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description should explain what deletion entails, the required identifier, and any side effects. It only says 'Delete equipment', leaving the agent without enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (athlete is described, equipment_id is not). The description does not mention any parameters or add meaning beyond the schema, failing to compensate for the missing equipment_id description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'equipment', distinguishing it from sibling tools like get/create/update equipment. However, it lacks any additional scoping or detail that would make it more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or context provided; the description only restates the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds no additional context about side effects, required fields, or behavior on update. It merely restates the action of editing, which is consistent with annotations but contributes no new transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, making it concise and front-loaded. However, it is minimal to the point of underspecification, which is a completeness issue rather than a conciseness flaw, so it earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 10 parameters, nested objects, and no output schema, the two-word description is grossly insufficient. It doesn't mention required fields (library_id, item_id), the effect on the template, or any constraints. The description is not complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'athlete' and 'workout_type_id' have descriptions), but the tool description provides zero parameter semantics. It does not explain any of the 10 parameters, their purpose, or how they map to a workout template. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a workout template' clearly identifies the action (edit) and the resource (workout template, which corresponds to a library item). It distinguishes from sibling create/delete tools by implying modification, though it doesn't explicitly differentiate from other update tools like tp_update_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. It does not mention that it updates an existing library item, nor does it reference sibling tools like tp_create_library_item or tp_get_library_item. Users are left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the write behavior is known, but the description adds no further context about duplicate handling, ownership, required permissions, or side effects. It does not contradict the annotations, but it also does not enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, which is structurally clean. However, it is so terse that it leaves substantial details to be inferred from other fields, making it slightly under-sized for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with 9 parameters, a nested object, and no output schema, a one-sentence description is inadequate. It does not mention required fields, the required structure object, or what the API returns after creation, leaving the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44% (4 of 9 parameters have descriptions), and the tool description mentions none of the parameters. Undocumented fields like tss, duration_hours, and description remain unexplained, and the nested 'structure' object is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Save' and names the resource ('workout template', 'library'), clearly distinguishing it from sibling tools like tp_create_library or tp_update_library_item. It does not list what fields the template includes, but the core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as tp_schedule_library_workout or tp_update_library_item. The description simply states what it does, leaving the agent to infer appropriate context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already declare. It does not disclose whether the update is partial or full replacement, what happens to omitted fields, or any side effects. The annotations indicate a non-destructive, idempotent write, but the description contributes no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single sentence with no filler words. It is front-loaded and readable. However, the brevity severely limits its informational value, though it does not contain unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with 11 parameters and no output schema, this description is materially incomplete. It fails to explain update semantics (partial vs. full), which fields can be updated, or what the result looks like. The annotations provide some safety context, but the description does not adequately support safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is very low (9%), and the description does not compensate by explaining any parameter semantics. It does not reference parameters at all, leaving the agent to infer meaning from parameter names alone, which is insufficient for a tool with 11 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (update) and resource (equipment), distinguishing it from sibling tools like tp_create_equipment, tp_get_equipment, and tp_delete_equipment. However, it is somewhat vague with 'details' and doesn't enumerate specific updatable fields, though the schema provides that information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives (e.g., create vs. update), nor does it mention any prerequisites, context, or exclusions. It simply restates the action without situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, and the description adds no behavioral context beyond the word 'Create'. It does not disclose whether duplicates are allowed, if existing notes are overwritten, or any auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description is too sparse. It does not explain response format, error behavior, or how a calendar note differs from an event, though the schema and sibling tool names provide some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. The schema provides descriptions for date and athlete only, leaving title and description without schema descriptions; the description does not compensate for this gap or add any parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and object 'calendar note', clearly indicating a write operation. It distinguishes from workout or event creation tools via the 'note' resource, though not explicitly from tp_create_event beyond the noun difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tp_update_note or tp_create_event. It also doesn't mention the coach-only athlete parameter or any prerequisites, leaving the agent to infer usage context from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, idempotent, and open-world hints. The description adds no behavioral context beyond the date range already evident in the schema, and doesn't disclose return format, aggregation details, or any special behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what 'nutrition data' includes and how it's returned over the date range. The minimal description leaves significant ambiguity about return values and data granularity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description adds no additional semantic meaning beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get nutrition data' with a date range scope, distinguishing it from sibling tp_update_nutrition. However, 'nutrition data' is somewhat vague and it doesn't explicitly differentiate from other getter tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like tp_update_nutrition or other data retrieval tools. The description only states what it does without any context on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-destructive, idempotent operation. The description adds no extra behavioral context, such as whether partial updates are supported or any prerequisites. It simply restates the tool's function without enriching the annotation-provided safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and free of filler. It is appropriately sized for a simple update tool, though the lack of elaboration is a minor trade-off. The brevity does not hinder clarity here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, schema, and annotations, the description is still thin. It provides no context on typical use cases, prerequisites, or expected outcomes. It does not explain what 'pace zones' means or how thresholds map to zones, and there is no output schema to clarify return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter meanings are well-documented. The description adds minimal value beyond confirming that run and swim thresholds are updated, but it does not introduce new semantic details or examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'run/swim pace zones', distinguishing it from sibling tools like tp_update_ftp and tp_update_hr_zones. It is concise and specific, though it could more explicitly frame the concept of pace zones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention coach/athlete context or that omitting parameters might leave zones unchanged. Usage must be inferred from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutating, non-idempotent operation, but the description adds no behavioral context beyond what the name and annotations already imply. It does not disclose any side effects, permissions, or creation specifics (e.g., whether it returns the created event). The description is neither contradictory nor enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without verbose filler. Every word contributes to the meaning, and it is as concise as possible for the information it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no output schema, and the description covers only a small fraction of the behavior and parameter space. It omits details about required fields (name, date), optional fields (event_type, distance, athlete), return values, and creation semantics. For a create tool of this complexity, the description is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for two parameters (priority and CTL target) by mapping them to the 'priority' and 'ctl_target' fields, which are otherwise undocumented in the schema. However, with schema description coverage at only 25% and six parameters lacking any explanation, the description fails to compensate for the overall lack of parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a clear resource ('race/event'), and highlights key parameters (priority and CTL target) that distinguish it from event management siblings. It clearly differentiates from tp_update_event and tp_delete_event by the action it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when creating a new race/event. However, it provides no explicit when-not-to-use guidance or mention of alternatives like tp_update_event for modifying existing events. The guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the action implied by the name and annotations (readOnlyHint=false indicates a write operation). It does not disclose side effects, permissions, naming constraints, or what happens if a group with the same name exists. Since annotations already carry the safety profile, the description adds no extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the action and resource with no wasted words. It is front-loaded with the verb, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter create tool with annotations and full schema coverage, the description is minimally adequate but lacks details about expected return values (no output schema) and any constraints on group names. It does not mention whether the group is created empty or if it can be immediately populated via sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the only parameter 'name' with the description 'The group name.' The tool description does not add any additional meaning or clarification for how the parameter should be used, so it stays at the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new athlete group' uses a specific verb ('create') and resource ('athlete group'), clearly distinguishing it from other group management tools like tp_rename_group or tp_list_groups. It adds the qualifier 'athlete' to differentiate from other create tools (e.g., tp_create_event).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as tp_add_athletes_to_group or tp_rename_group. It does not mention any prerequisites, follow-up actions, or contexts where this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, which covers the safety profile. The description adds no behavioral detail, but there is no contradiction and the annotations are sufficient for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At exactly one sentence, the description is concise and front-loaded. It says exactly what the tool does with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with rich annotations and a fully described optional parameter. However, with no output schema, the description does not explain what pool length settings are returned, which is a minor gap given the open-world hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter 'athlete' has a complete schema description, so the schema fully covers parameter semantics. The tool description adds nothing beyond the schema, but baseline 3 is appropriate given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get pool length settings' clearly states the verb (get) and resource (pool length settings). It is specific and distinct from sibling tools, though it adds no additional context beyond the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply restates the function without any contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal safety info (not read-only, not destructive). The description adds no additional behavioral context such as whether logging replaces existing metrics for the same date, whether it confirms the operation, or any side effects. Important side effects remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's primary action. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and sparse annotations, the description does not provide enough context for an agent to understand whether logging is additive, how the 'athlete' parameter works with coach accounts, or what a successful log returns. It is too shallow for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30% (date, injury, athlete have descriptions). The description mentions examples like weight, HRV, sleep, steps but does not add units, ranges, or relationships, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Log' with the resource 'health metrics' and scope 'for a date', clearly distinguishing it from sibling tools like tp_get_metrics which read metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for recording health metrics for a date, but it does not explicitly state when to use it over alternatives, mention exclusions, or provide prerequisites for coach accounts. Usage is implied rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so safety is covered. The description adds that the returned data includes 'goals and results', which is useful beyond annotations, but it doesn't disclose other behavioral traits like auth requirements or return format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly states the tool's purpose. Every word contributes meaning; there is no fluff or repetition. It is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with comprehensive annotations and a well-described schema, the description is largely complete. It tells the agent what the tool returns ('goals and results') and the resource type. However, it doesn't explain what 'A-priority focus event' means or clarify that omitting 'athlete' uses the caller's profile (latter is in schema). Given the low complexity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'athlete', with a full description covering name/ID and coach-only usage, yielding 100% schema coverage. The description itself adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the target resource ('A-priority focus event'), and also indicates the contents ('goals and results'). It distinguishes the tool from siblings like tp_get_events and tp_get_next_event by the unique 'focus event' resource, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of conditions like needing the focus event, or exclusions such as 'use tp_get_events for other events'. The schema mentions the optional athlete parameter for coaches, but the description itself lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only and non-destructive. The description adds date-range scoping but does not disclose what specific metrics are returned or any response structure, which is less critical given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that immediately conveys the operation and scope, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with rich annotations and full schema coverage, but since there is no output schema, the description could offer more about the return payload (e.g., typical metric names). It remains minimally viable for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters documented (start_date, end_date, athlete). The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves health metrics within a date range, using specific verb 'Get' and resource 'health metrics'. It is distinct from write tools like tp_log_metrics, though it doesn't explicitly differentiate from other metric-related getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied (retrieving metrics for a given date range), but the description offers no explicit guidance on when to choose this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's write behavior aligns. The description adds minimal context beyond the annotations, only specifying that it updates 'planned calories' but not disclosing how it handles existing values, whether it replaces or adjusts, or any side effects. Given the annotations cover the safety profile, the description provides acceptable but not rich behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and target. There is zero filler or redundancy, and the most critical information is front-loaded. This is an exemplary concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with annotations, the description is adequate but not complete. It doesn't mention what happens on success (e.g., return value or confirmation), whether the update applies to the current day or a specified date, or any prerequisites like coach permissions for updating athletes. The annotations and schema cover some context, but the lack of an output schema and minimal description leaves gaps for an agent deciding whether and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% because planned_calories lacks a description, but the description's phrase 'daily planned calories' partially clarifies the integer parameter's meaning. The athlete parameter is well-described in the schema. The description adds marginal value over the schema, as it doesn't explain units, allowed ranges, or the effect of omitting athlete. It barely compensates for the missing parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update daily planned calories' clearly identifies the action (update) and the specific resource (daily planned calories), making the tool's purpose immediately obvious. It is distinct from siblings like tp_get_nutrition and other update tools, though it doesn't explicitly reference them. The name and description are consistent and specific enough to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose as an update is implied, and the presence of a sibling tp_get_nutrition suggests this is for writing rather than reading. However, no explicit guidance on when to use this tool versus alternatives is provided, and there is no mention of when not to use it (e.g., for bulk updates or in read-only contexts). The usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the safety profile is clear. The description adds that the event is 'nearest future planned' but does not disclose return behavior when none exists, timezone handling, or field details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with the action and target front-loaded; no filler or redundancy. It earns every word at this length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with good annotations, the description is nearly sufficient. It misses a note on behavior when no future event exists and does not contrast with tp_get_focus_event, but the core operation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter is fully described in the input schema (athlete name/ID, coach-only, omit for own profile), so the description does not need to add much. The description itself adds no parameter details, which is acceptable given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('nearest future planned event'), making its function evident. It is distinguishable from sibling tools like tp_get_events and tp_get_focus_event by its 'nearest future' qualifier, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving the next upcoming event, with no mention of when to prefer tp_get_events or tp_get_focus_event. It provides the core trigger ('nearest future planned event') but lacks explicit exclusions or an alternative choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds the operational context that the tool is 'rarely needed' and that other tools work without it, which provides some value beyond the annotations. However, it does not describe what the profile contains or any response format, leaving the behavioral picture slightly incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two short sentences that front-load the core purpose. Every word earns its place, with no redundant phrasing or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description is largely sufficient. It conveys the core purpose and a useful usage hint, while the schema and annotations cover the remaining technical details. The only gap is that it doesn't mention what the returned profile contains or when the user might actually need it, but given the tool's simplicity and the 'rarely needed' note, the completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single optional parameter, with a detailed description explaining the 'athlete' field and the coach-account distinction. The description itself adds no parameter information, but since the schema already documents the parameter thoroughly, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets an athlete profile, which is a specific verb+resource combination. It adds the note 'Rarely needed - other tools work without it', which hints at its optional role but does not explicitly differentiate it from sibling tools like tp_get_athlete_settings. The purpose is clear and correctly reflects the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage guideline by saying 'Rarely needed' and 'other tools work without it', implying that this tool is not a prerequisite for most operations. However, it does not specify when the tool *should* be used or name any alternative tools. This is implied guidance rather than explicit when-to-use/when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description carries a low burden. However, it adds no extra behavioral context such as ordering of comments, permissions required, or behavior when no comments exist, so it only meets the baseline for annotation-covered tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. No filler or redundant content, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no output schema, the description is adequate but minimal. It doesn't specify the return format, ordering, or edge cases, leaving some ambiguity about the exact behavior. The annotations cover safety, so the description's brevity is acceptable but not outstanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both athlete and note_id have descriptions), so the description need not explain parameters. The description adds no additional parameter semantics beyond what the schema already provides, resulting in the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all comments on a calendar note' clearly identifies the verb (Get), the resource (comments), and the scope (calendar note), distinguishing it from the sibling tool tp_get_workout_comments which targets workout comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for calendar notes but does not explicitly state when to use this tool over alternatives like tp_get_workout_comments or mention any exclusions. The context of 'calendar note' provides some guidance, but no explicit when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly=false, destructiveHint=false, and idempotentHint=true. The description adds a behavioral requirement (at least one field must be provided) that is not in annotations. It does not disclose side effects, auth needs, or error behavior, so it adds only minimal context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, immediately conveying purpose and a key usage requirement. It is well-structured and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter update tool with no output schema, the description is minimal. It covers the core action and the at-least-one constraint, but omits the athlete parameter's role and any return/error information. This is adequate as a minimum viable description but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, covering date, athlete, and note_id. The description adds meaning to title, description, and is_hidden by listing them as updatable fields, but notably omits the athlete parameter, which has a rich schema description indicating coach-only targeting. This partial compensation is helpful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a calendar note' clearly states the action (update) and resource (calendar note), distinguishing it from note creation or deletion. However, it does not explicitly differentiate from sibling tools like tp_set_workout_note or tp_create_note, though 'calendar note' provides some context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage constraint: 'Provide at least one of: title, description, date, is_hidden.' This guides the agent on required inputs. However, it does not explicitly contrast with alternatives or mention when not to use this tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent, non-destructive write operation. The description adds that the workout is placed on the athlete's calendar and is structured into blocks, but it does not disclose potential side effects, permission requirements, or failure modes. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the first sentence front-loading the core purpose and the second compactly summarizing the block structure. Every word adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive schema and annotations, the description covers the essential facts: the tool creates a structured strength workout, places it on the calendar, and uses blocks with parameters. It mentions the dependency on tp_search_exercises. A brief note about the optional athlete parameter or possible errors would improve completeness, but the current description is adequate for selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full parameter descriptions, including a detailed breakdown of the blocks structure. The description adds the useful hint that exercises come from tp_search_exercises and lists example parameters, but this is largely redundant with the schema, so it does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and clearly identifies the resource as a 'structured strength/gym workout' on the athlete's calendar. It distinguishes this from generic workout creation tools by emphasizing the strength/gym focus and referencing tp_search_exercises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the workflow by stating blocks come from tp_search_exercises, which hints that users should search for exercises first. However, it does not explicitly state when to use this tool over siblings like tp_create_workout, nor does it provide when-not conditions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, which the description does not contradict. The description adds no additional behavioral context such as irreversibility, associated data deletion, or permission requirements, but given the annotation coverage, it provides adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and to the point, containing no fluff or redundant information. It fully communicates the essential action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two parameters and no output schema, the description, combined with the annotations and schema, provides sufficient context. No critical details about side effects or return values are required, and the tool is easy to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage, documenting both 'athlete' and 'workout_id'. The description's phrase 'by ID' aligns with the required workout_id parameter but does not add new meaning beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('strength workout') with the identifying method ('by ID'). This clearly distinguishes it from sibling tools like tp_delete_workout, which targets general workouts, and other delete tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for deleting strength workouts, but it does not explicitly state when to use this tool instead of tp_delete_workout or other alternatives. The presence of a sibling tool for regular workout deletion suggests a need for such guidance, so the usage context is only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the tool as destructive (destructiveHint=true) and non-read-only, so the bar is lower. The description adds useful context about the source of file_id (device_files/attachment_files) but does not disclose any additional behavioral traits such as irreversibility or permission requirements beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action and resource. Every word earns its place: it states what happens, with which identifier, and where to obtain that identifier, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with no output schema, the description plus annotations cover the essentials: the action, the target, and data provenance. It omits explicit mention of consequences (e.g., permanent deletion) but that is already implied by destructiveHint=true. The athlete param for coach accounts is in the schema, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with descriptions, so no heavy compensation is needed. The tool description reinforces the meaning of file_id by linking it to tp_get_workout, but adds no extra meaning for workout_id or athlete, which are adequately explained in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a workout file') and the required resource ('by file_id'), with a direct reference to obtaining the ID from tp_get_workout. It distinguishes the tool from related file operations like upload/download and from tp_delete_workout by specifying 'workout file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit guidance by telling users to get file_id from tp_get_workout, which implies a prerequisite call. However, it does not explicitly state when to use this tool vs alternatives (e.g., when you want to keep a copy) or mention the optional athlete parameter for coach accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds little beyond the schema, as it only restates the date-range scope without mentioning behavior such as return format or the optional athlete parameter for coach accounts. This is sufficient given the annotation coverage but adds minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one clear, front-loaded sentence with no redundant words. It immediately communicates the core function, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with strong annotations and fully documented parameters, the description is mostly complete. However, it does not explain what an 'availability entry' is, nor does it mention the optional athlete parameter, which is important for coach accounts. Since there is no output schema, a tiny bit more context about the return shape could help, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, including dates and the athlete field, so the description does not need to compensate. The description's mention of a 'date range' adds no new semantic meaning beyond what the schema already specifies. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('availability entries') with a specific scope ('for a date range'). This unambiguously distinguishes it from sibling tools like tp_create_availability and tp_delete_availability, making its purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for a date range), but it does not explicitly mention alternatives or exclusion cases, such as using tp_create_availability to add entries or tp_delete_availability to remove them. No when-not-to-use guidance is provided beyond the date range requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds only the resource scope (bikes, shoes) and does not disclose any additional behavioral traits beyond what annotations already provide. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 4 words ('List equipment (bikes, shoes).') with the verb front-loaded and no redundant information. It is an excellent example of concise, purposeful writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list with two optional parameters and strong annotations, the description is largely sufficient. The schema fills in details about the type enum and athlete filtering. Minor gap: the parenthetical could be misleading about the default 'all' type, but that is resolved in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides an enum for `type` with values 'bike', 'shoe', 'all' and a default of 'all', plus a description for `athlete`. The description's parenthetical aligns with the enum values but omits the 'all' option, which could be slightly ambiguous. It adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with the resource 'equipment' and adds a clarifying parenthetical '(bikes, shoes)'. This clearly distinguishes it from sibling write tools like tp_create_equipment, tp_update_equipment, and tp_delete_equipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'List' implies read-only usage, and the sibling tools have write verbs, so the intended context is inferred. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention the optional type/athlete filters or coach-only restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safe, read-only nature is covered. The description adds no behavioral context beyond the verb 'List,' which matches the annotations. There is no contradiction, but the description also provides no extra detail about return format, pagination, or coach-specific behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that says exactly what the tool does without filler. It is front-loaded with the verb and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with comprehensive annotations and full schema coverage, the description is sufficient. It lacks an explicit note about the optional athlete parameter or return shape, but these are either in the schema or inferable from the tool's simplicity. The presence of sibling tools like tp_get_library_items clarifies the domain context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single optional 'athlete' parameter with a clear description, so schema coverage is 100%. The description does not mention the parameter, but the schema already handles semantic meaning. Thus the description adds no extra value beyond the schema, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('workout library folders'), distinguishing it from sibling tools like tp_get_library_items and tp_get_library_item, which operate on items within libraries. It is unambiguous and directly tied to the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage—when you need to list workout library folders—but provides no explicit guidance on when to choose this tool over alternatives. It does not mention exclusions or relationships to sibling tools like tp_get_library_items, though the naming makes the distinction reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds what the summary contains but does not elaborate on return format, pagination, or any behavioral quirks. This is adequate but not rich beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and every word contributes. The parenthetical efficiently clarifies the summary content without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description partially compensates by naming the summary components (blocks/prescriptions/sets completed). With strong annotations and simple parameters, this is enough for an agent to invoke the tool, though a touch more detail about the response shape could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents workout_id and athlete parameters. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a precise resource ('strength workout's compliance summary') with clarifying details (blocks/prescriptions/sets completed). This clearly distinguishes it from sibling tools like tp_get_strength_workout, which presumably returns the full workout rather than a compliance summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need a compliance summary) but provides no explicit guidance about when to choose this tool over alternatives, nor does it mention exclusions or prerequisites. The sibling list shows similar getters, but the description does not directly address selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the return content (weeks, per-week duration/distance, sport breakdown, description), which goes beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Summary of one training plan') and then uses a colon-separated list to convey content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature and strong annotations, the description sufficiently conveys the tool's output. It could be improved by explicitly pointing to related tools (e.g., tp_list_training_plans for IDs, tp_get_training_plan_workouts for detailed workouts), but the summary by 'one plan' already avoids major ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (athlete and plan_id) fully described in the input schema. The description does not add further parameter-level meaning, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a summary of one training plan and lists specific content (weeks, per-week duration/distance, sport breakdown, description). This distinguishes it from sibling tools like tp_list_training_plans (multiple plans) and tp_get_training_plan_workouts (workouts, not summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It only implies scope via 'one training plan', but does not mention tp_list_training_plans for finding plan IDs or tp_get_training_plan_workouts for workout-level details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds that it is a combined summary and lists the included metrics, which is useful context, but it does not disclose any additional behavioral nuances beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core purpose, then specifics. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only summary tool with strong annotations and full schema coverage, the description adequately conveys the tool's purpose and key output contents. Some might benefit from a note about response format, but given no output schema, the listed metrics are sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully (athlete and week_of with descriptions). The description does not add parameter-specific guidance, but with 100% schema coverage, no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a combined view of workouts and fitness for a week, listing specific metrics (TSS, duration, CTL/ATL/TSB). This distinguishes it from sibling tools like tp_get_workouts and tp_get_fitness, which focus on individual workouts or fitness data separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied but not explicitly stated. The description explains what the tool returns, so an agent can infer when to use it for weekly summaries, but it does not mention alternatives or when-not-to-use, leaving some ambiguity among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds only the 'private' qualifier, which is a modest behavioral trait, but it does not disclose additional context such as authentication requirements, error conditions, or what to expect when no note exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the tool's purpose. It is well-front-loaded and contains no fluff or repetition, earning a perfect score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with no output schema and strong annotations, the description is sufficiently complete. It clearly defines the resource being fetched (the private workout note) and the target (a workout), which is all the agent needs to invoke the tool correctly. No additional return-value details are strictly necessary for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'athlete' parameter fully, but 'workout_id' has no description. The tool description does not add any parameter semantics beyond what the schema gives, and with a schema coverage of 50%, it fails to compensate for the undocumented parameter. The agent is left to infer what a workout ID is or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource (the private workout note for a workout), which precisely distinguishes it from sibling tools like tp_set_workout_note (which sets a note) and tp_get_workout (which retrieves workout details). The inclusion of 'private' adds specificity about the type of note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you use this tool when you need the private workout note for a given workout. However, there is no explicit guidance on when to use it versus alternatives (e.g., tp_get_workout_comments for comments, or tp_get_workout for broader workout data), nor any mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'calendar notes' and 'date range' context, but no additional behavioral traits (e.g., pagination, default ordering) are disclosed. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It efficiently communicates the action and scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, strong annotations, and full parameter schema, the description is adequate. It doesn't specify the return type, but 'List' implies an array, and the lack of an output schema reduces the need for detailed return documentation. The optional athlete behavior is covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (start_date, end_date, athlete) having its own description. The tool description adds little beyond restating the date-range scope, so it meets the baseline but does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), resource (calendar notes), and scope (date range). It is distinct from sibling tools like tp_get_note, tp_create_note, and tp_get_workout_note by specifying 'calendar notes' and the date-range filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing notes within a specified date range, which is clear from context. However, it does not explicitly state when to prefer this over alternatives like tp_get_note for single-note retrieval, nor does it mention the optional athlete param for coach accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write behavior (readOnlyHint=false), idempotency, and non-destructiveness. The description adds one important behavioral constraint: the default group cannot be renamed. This is useful context beyond the annotations, but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The primary action is front-loaded ('Rename an athlete group.'), and the second sentence adds a critical constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename operation with 2 well-documented parameters and annotations, the description covers the core purpose and a key restriction. No output schema is needed for a straightforward rename, though it might be slightly more complete if it clarified the meaning of 'default group' or success/failure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters ('Group (tag) ID' and 'The new group name'). The description itself does not add parameter-level detail beyond what schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Rename') and resource ('athlete group'), providing a specific verb+resource pair. It also distinguishes from sibling tools like tp_create_group and tp_delete_group by indicating the rename operation. The added constraint about the default group further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (rename an existing group) and provides a when-not condition ('The default group cannot be renamed'), but it does not explicitly discuss alternatives or context relative to other group tools. No sibling tool performs rename, so alternatives aren't needed, but the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context, essentially restating the action. Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false, which provide the safety profile. No additional behavioral traits (e.g., overwriting behavior, auth requirements) are disclosed beyond the schema's note about athletes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with the action. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with good schema coverage and annotations, the description is adequate. It lacks any mention of return values or related read tool, but the essential purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 2 of 3 parameters (note and athlete) with descriptions; the description itself does not explain parameters. It adds no meaning beyond the schema, such as clarifying that workout_id is a target identifier. Given 67% coverage, the description does not compensate for the missing workout_id description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set or update' and identifies the resource 'private workout note' for a workout. This clearly distinguishes it from sibling tools like tp_get_workout_note (read) and tp_add_workout_comment (comment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as tp_get_workout_note. The description implies usage for setting/updating a note, but does not mention when not to use it or point to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a read-only, non-destructive operation. The description adds value by disclosing the side effect of saving full time-series data to a JSON file, which is beyond what annotations convey about data store safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. The first sentence front-loads the core purpose with a list of result contents, and the second adds a key side effect. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool without an output schema, the description conveys the main return contents (metrics, zones, laps) and the JSON side effect. It is complete enough for most use cases, though it does not specify where the JSON file is saved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers only the athlete parameter, leaving workout_id undocumented (50% coverage). The description does not compensate by explaining workout_id format, purpose, or any constraints, so it adds no parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving workout analysis (metrics, zones, laps), which distinguishes it from sibling tools like tp_get_workout (basic details) or tp_get_metrics. The additional side effect of saving the time-series to a JSON file further differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when workout analysis data is needed, but it does not explain when to prefer this over alternatives such as tp_get_workout or tp_get_workout_prs. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavior beyond annotations by enumerating what is copied (structure, description, planned fields). This is useful context beyond the readOnlyHint/idempotentHint/destructiveHint annotations, which only indicate the safety profile. It does not contradict annotations, and though it could mention what is not copied (e.g., comments, results), it provides meaningful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundancy or fluff. It front-loads the primary purpose and then adds a clarifying detail about what is copied. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description is somewhat thin. It explains what gets copied but does not mention what happens on success (e.g., returns new workout ID), whether the source remains intact, or any caveats about existing workouts on the target date. Given the moderate complexity and lack of output schema, the description covers the basics but leaves gaps in expected behavior and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already well-documented. The description adds limited value by implying that target_date is the new date and workout_id is the source, but it does not explain the optional parameters title and athlete beyond what's in the schema. With high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies a workout to a new date, which is a specific verb+resource+target combination. It distinguishes from sibling tools like tp_create_workout and tp_update_workout by focusing on duplication rather than creation or modification. Mentioning that it copies structure, description, and planned fields adds specificity about what is copied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage: use when you need to duplicate an existing workout to another date. However, it lacks explicit guidance on when to use this tool versus alternatives like tp_create_workout or tp_update_workout. There is no mention of when not to use it or any prerequisites, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnly=false) and non-destructive behavior. The description adds one behavioral nuance: 'Duration is auto-computed only from simplified structure when not provided.' This is useful but limited; it does not disclose permissions, side effects, or response behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and includes only one additional behavioral note. Every word earns its place; no fluff or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, nested objects, no output schema), the description is minimal. It does not explain return values or provide a high-level workflow for using simplified structure vs native payload. However, the rich schema and the single auto-compute note provide some grounding. This is adequate but leaves clear gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 93%, so the schema already documents most parameters. The description adds a semantic rule connecting duration_minutes and structure ('Duration is auto-computed only from simplified structure when not provided'), which adds value beyond the schema. This justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a planned workout' with a specific verb and resource. It also distinguishes between two input modes (simplified interval structure vs native TP structured_workout payload), which aligns with the input schema. While sibling tools like tp_create_strength_workout exist, the 'planned workout' scope is clear enough for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context on when to use each structure option and notes that duration auto-computes from simplified structure, but it does not explicitly state when to use this tool versus alternatives like tp_update_workout or tp_create_strength_workout. It offers implied usage rather than explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and idempotentHint=true, and the description's 'Remove' is consistent with that. However, the description adds no extra behavioral context beyond what annotations provide, such as whether removal is permanent or how non-existent athletes are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose without any filler. It is well-structured and ideal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two fully described parameters, no output schema, and clear annotations), the description is complete enough for an agent to correctly invoke it. The behavior is straightforward and well-covered by the schema, annotations, and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (group_id as 'Group (tag) ID' and athlete_ids as 'Athlete IDs to remove'), so schema coverage is 100%. The description adds no further parameter meaning, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the target resource ('athletes from a group'), with scope ('one or more'). It is specific and distinguishes from sibling tools like tp_add_athletes_to_group or tp_list_athletes_in_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines are given about when to use this tool versus alternatives. The name and sibling context imply usage for removing athletes, but the description does not state exclusions or mention alternatives, leaving it to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a non-read-only, non-idempotent, non-destructive operation. The description adds coach-account requirements and multi-athlete capability, but does not disclose potential side effects like scheduling conflicts or overwriting existing workouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters and no output schema, the description covers the main action and athlete scoping, but does not explain library_id/item_id, return values, or scheduling behavior. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% (date, athlete, athletes are described), but library_id and item_id remain undocumented. The description adds no parameter-specific meaning, leaving a gap for the two required IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Schedule a library template to a calendar date.' It also clarifies the scope (self or athletes for coach accounts), which distinguishes it from other workout management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides good context by indicating it is for scheduling library templates and mentions the self vs. athlete modes. However, it doesn't explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnly=false) and idempotency. The description adds important semantics like 'Only the provided fields change' (partial update) and a boundary condition for old events. This supplements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each packed with relevant information: the action and fields, partial-update behavior, and ID source/limitation. No redundant or extraneous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with 10 parameters. It omits several updatable fields and doesn't clarify whether its parenthetical list is exhaustive. There is no mention of return values or side effects beyond the partial update, leaving gaps for the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description merely lists some parameter names without explaining formats or constraints. It omits several schema fields (e.g., athlete, event_type, ctl_target) and doesn't clarify the meaning of the listed fields beyond their names, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update fields on an existing race/event' and lists the specific fields that can be changed. This distinguishes it from sibling tools like tp_create_event and tp_delete_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides valuable usage context: 'Event ID from tp_get_events' indicates the prerequisite for obtaining the ID, and the 2-year resolution limit is a useful constraint. However, it doesn't explicitly describe when to use this tool over alternatives, though the update intent is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the copying behavior and the date-offset calculation, which adds context beyond the annotations' readOnlyHint/idempotentHint. It does not discuss duplication if applied multiple times, but the annotations already signal non-idempotency, so the added value is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the core action front-loaded. It contains no redundant filler and efficiently delivers the key behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and full schema coverage, the description is adequate. It explains the core operation and the athlete parameter. It could mention what happens on success (e.g., returning calendar entries), but that is not required given the output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all parameters (100% coverage). The description mentions the athlete parameter and start_date but largely repeats schema info. It adds minimal extra meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply') and the specific resource ('training plan'), and further explains the mechanism: copying each plan workout to start_date + its relative day. This distinguishes it from sibling tools like tp_get_training_plan or tp_list_training_plans, which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by explaining the action, but it does not explicitly indicate when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context by enumerating returned fields (athlete type, linked coach, preferences, units) and reinforcing that changes belong to separate update tools. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and object, followed by a concise pointer to relevant alternatives. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with strong annotations, the description adequately covers scope and return content. It does not describe the exact response format or athlete authorization details, but those are inferable from the read-only intent and the parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the only parameter 'athlete' is fully documented in the schema. The tool description itself adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') and resource ('athlete account settings and profile fields') with concrete examples (athlete type, linked coach, preferences, units). It distinguishes from update tools by naming them, though it does not explicitly distinguish from the sibling tp_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use the tool: 'To change training values use tp_update_ftp / tp_update_hr_zones / tp_update_speed_zones.' This provides a clear alternative and exclusion for mutation. It implies the read-only usage for retrieving settings but does not mention when to choose tp_get_profile over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the date-range scoping, which is also evident from the parameters. It does not disclose return format, ordering, or any caveats, but the annotation coverage lowers the burden and the description provides some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler. It directly states the tool's purpose and is easily scannable. It earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool, the description is adequately complete given the full schema and clear annotations. It identifies the main action and scope, while the schema explains the parameters. The lack of an output schema is not a major issue since 'list events' naturally implies returning event objects. It leaves minor ambiguity around ordering/pagination but that is acceptable for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, with each parameter (start_date, end_date, athlete) documented including the YYYY-MM-DD format and coach semantics, the description need not add more. The phrase 'in a date range' aligns with the required parameters, but it adds no new details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a precise action ('List') on a clear resource ('events') with a scope ('in a date range'). It distinguishes from sibling tools like tp_get_focus_event and tp_get_next_event, which retrieve single events, by clearly indicating this is a bulk listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for use: when you need to list events within a date range. It does not explicitly mention alternatives or when not to use it, but the purpose is straightforward enough that the agent will likely choose it correctly. No exclusions are stated, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful context that historical date ranges are supported, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the primary action and resource. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, four optional parameters with full schema descriptions, and robust annotations, the description is mostly complete. It lacks explicit output format details, but the mention of CTL/ATL/TSB provides enough context for an agent to infer what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description does not add parameter-specific meaning beyond the schema; the mention of CTL/ATL/TSB relates to the output data, not the parameters themselves. The schema already explains days, athlete, and dates adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the exact resource ('fitness/fatigue trend') with the metrics CTL/ATL/TSB, clearly distinguishing it from other getter tools in the sibling list. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving fitness/fatigue trends but provides no explicit when-to-use guidance or alternatives. It does not name other tools like tp_get_metrics or tp_get_weekly_summary, which could be confused with this one. The 'Supports historical date ranges' gives some context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds minimal behavioral context beyond the resource type ('calendar note'), but no additional details about return behavior or errors. This meets the baseline given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence states the essential function with no redundant words or filler. It is front-loaded with the action and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-by-ID tool with comprehensive annotations and full schema coverage, the description is adequate. It clearly identifies what the tool operates on and the primary parameter. A brief mention of the return value could improve completeness, but the absence is not a significant gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented. The description itself adds no extra parameter semantics beyond the schema, which already explains note_id and the athlete field's coach-only behavior. Baseline 3 is appropriate because the schema carries the parameter documentation load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('calendar note'), and a retrieval criterion ('by ID'). It clearly distinguishes from sibling tools like tp_list_notes (which lists notes) and tp_get_workout_note (which targets workout notes specifically), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for retrieving a single note when the ID is known, and the schema's required note_id reinforces this. However, it does not explicitly contrast with alternatives like tp_list_notes or note that this is for calendar notes only, so guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, setting the safety baseline. The description adds value by revealing the output structure (week/day organization and fields), which is behavior beyond what annotations capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that states the scope and enumerates included fields. No redundant words or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with 2 parameters and a well-described output, the description covers essentials. It could mention how to obtain plan_id (e.g., via tp_list_training_plans), but that is a minor gap given the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have complete schema descriptions (plan_id, athlete with coach guidance). The tool description adds nothing about parameters, so the baseline of 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies the exact resource ('workouts of a training plan') and output format ('laid out by week/day') with a clear list of fields. This distinguishes it from siblings like tp_get_training_plan (plan metadata) and tp_get_workouts (general workouts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need plan workouts in week/day layout) but does not explicitly state when not to use it or mention alternatives. Sibling tools are present but not referenced, so the agent must infer differentiation from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, safe behavior, so the description carries minimal burden. It adds no behavioral details beyond the schema (e.g., error handling, return format, or permission nuances). The 'Use after' note is a usage guideline rather than behavioral transparency, so this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately front-loading the core purpose. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-ID tool, the description is adequately complete. It identifies the resource, the operation, and a clear usage context (after listing workouts). No output schema exists, but the description doesn't need to explain return values for such a straightforward tool. The only minor gap is not mentioning optional parameter behavior, but the schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully described in the schema. The description does not add any additional meaning or context to the parameters. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the action ('Get workout details by ID'), clearly distinguishing it from the sibling tool tp_get_workouts (which lists workouts). The phrase 'by ID' establishes the scope and the resource being operated on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Use after tp_get_workouts' provides a clear workflow context, telling the agent when this tool should be invoked. While it doesn't explicitly mention alternatives or exclusions, this is sufficient guidance for a simple get-by-ID operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by explaining the merge semantics ('Attaches the completed data to the planned workout'). It does not contradict the readOnlyHint=false or idempotentHint=true annotations, and the non-destructive nature is consistent with destructiveHint=false. However, it does not clarify whether the completed workout remains after merging.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and outcome. Every phrase earns its place, with no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple operation with three parameters, full schema coverage, and relevant annotations, the description is sufficient. It does not explain return values, but no output schema exists, and the core merge behavior is covered. It could mention preconditions or post-merge state, but overall it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 itself adds no additional parameter semantics beyond what is already in the schema, but it does not need to given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Pair' with clear resources ('completed workout' and 'planned workout'), and explains the outcome ('merging them into one'). This clearly distinguishes it from sibling tools like tp_unpair_workout and tp_create_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (when you have a completed and planned workout to merge) but does not explicitly state when to avoid it or mention alternatives like tp_unpair_workout for reversing. No exclusions or comparison with related tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating idempotentHint=true and destructiveHint=false, the description adds the behavioral detail of extracting a cookie from the user's browser. It does not mention potential side effects like requiring user interaction or overwriting existing auth, but the annotations cover the safety profile sufficiently for a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes the key usage trigger. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the purpose, mechanism, and when to use it. It omits details about return values, but given the simplicity and strong annotations, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a full description for the 'browser' parameter (100% coverage), including enum and default values. The tool description's mention of 'user's browser' aligns with the parameter but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool refreshes auth by extracting a cookie from the user's browser, providing a specific verb, resource, and mechanism. It also distinguishes itself from siblings by noting it is used when other tools return auth errors, which differentiates it from tp_auth_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use when other tools return auth errors'), giving clear context. However, it lacks explicit 'when not to use' guidance or naming of alternative tools, so it doesn't fully cover exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as non-read-only and non-destructive. The description adds context by explaining the detach behavior and explicitly stating 'No data is lost,' which reassures about the destructive hint. It also reveals the creation of two separate workouts, beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action in the first sentence. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the action, its effect, and safety. Minor gap: no guidance on when to use versus alternatives, but that's more of a usage guideline issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with clear descriptions for both 'athlete' and 'workout_id'. The tool description doesn't add parameter-level detail, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Unpair a workout' and further clarifies by detaching the completed workout file from the planned workout, distinguishing it from related operations like pairing or deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a workout is paired and needs separation) but doesn't explicitly mention alternatives or exclusions. It provides clear context but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable behavioral context by disclosing that it rescales the matching power-zone set and preserves the calculation method. This goes beyond the annotations, though it does not detail the full nature of the rescaling or any potential side effects on existing workout data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence conveys the core purpose, action, and a critical side effect without redundancy. Every word contributes value, and the parenthetical clarifies FTP without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the tool is a simple update operation. The description covers the main behavior (FTP update) and the important side effect (zone rescaling with method preservation). It does not mention return values or post-conditions, but those are less critical for an update tool given the available annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description adds minimal parameter-specific meaning beyond the schema—'power threshold' clarifies FTP slightly, but the schema already documents units, defaults, and the athlete field's coach-only caveat. The description does not meaningfully extend parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Update') and identifies the exact resource ('FTP (power threshold)') and a key side effect ('rescale the matching power-zone set'), which clearly distinguishes it from siblings like tp_update_hr_zones or tp_update_speed_zones. It fully conveys the tool's unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to update FTP and rescale power zones. However, it does not explicitly state when not to use it or mention alternatives (e.g., for updating heart rate zones or speed zones). Context from sibling names helps, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate that this is a non-read-only, non-destructive mutation, and the description aligns by saying 'Create'. It adds value by clarifying the library starts empty and that the operation returns a library_id. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every part earns its place: it defines the tool, clarifies the empty state, mentions the return value, and points to the next logical tool. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with two parameters and no output schema, the description is sufficiently complete. It explains the core behavior, the return value, and the next step. It does not cover error cases or permission requirements, but these are not critical for a straightforward create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: the 'name' parameter lacks a description, and the tool description does not explain it. The 'athlete' parameter is already described in the schema. The description adds no parameter-specific information, leaving the required 'name' parameter without guidance beyond its type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (create), the resource (an empty workout library), and its purpose (a folder for reusable templates). It distinguishes this tool from tp_create_library_item by noting that empty libraries are created here and templates are added separately, and it also mentions the return value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by indicating that after creating the library, templates should be added using tp_create_library_item. This implies the intended workflow and differentiates from the sibling. It does not explicitly state when not to use this tool, but the guidance is sufficient for a simple creation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent behavior. The description adds context about period-based aggregation and PR type mappings, but it incorrectly claims the default days is 90 while the schema states 3650, and it does not describe the return format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences front-load the core action, then provide compact PR-type details and a cross-reference. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, period, PR types, and a key alternative, but lacks information about the returned data structure and contains a default-value mismatch. Given no output schema, a bit more detail about the expected result would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description enriches the days parameter as a period and maps PR types to sports, which is useful given only 50% schema coverage. However, the wrong default for days and the lack of elaboration on the athlete parameter weaken its semantic contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an athlete's top performances filtered by sport and PR type over a time period. It also explicitly differentiates from tp_get_workout_prs, making its unique purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives direct usage guidance by specifying the period-based context and explicitly names tp_get_workout_prs as the alternative for single-workout PRs. This is a clear when-to-use vs. when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations by disclosing that the operation fetches the existing workout, merges changes, and saves—a merge rather than a full replace. This is important for understanding how partial updates work. It also notes compatibility with tp_create_workout's structure format. Annotations already cover mutability and idempotence, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose and efficiently communicates key behavior (merge, structure format). Every clause serves a purpose, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, nested objects, no output schema), the description provides essential merge semantics and format linkage but lacks details about usage scenarios, response behavior, or constraints on which fields can be updated. It is minimally adequate for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 44% schema description coverage, the description partially compensates by explaining the relationship between 'structure' and 'structured_workout' and pointing to tp_create_workout for format details. However, it does not add meaning for many other undocumented parameters (e.g., tags, sport, title), leaving them unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update fields of an existing workout', which is a specific verb+resource pair. It also distinguishes from tp_create_workout by mentioning the shared interval structure format and the merge behavior, making its scope clear relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It references tp_create_workout for the structure format, guiding users to consult that tool for details. The merge behavior ('fetches existing, merges, and saves') implies partial updates are supported, which is useful usage context. However, it does not explicitly state when to use this tool over alternatives or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the write nature is already known. The description adds that only .fit, .tcx, and .gpx files are accepted, which is useful, but it does not disclose what happens on overwrite or duplicate uploads, nor any side effects implied by openWorldHint=true. Overall, limited behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, target, and format constraints with no filler words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema. The description covers the core function and allowed formats but does not specify the success/error response, whether the upload replaces an existing file, or any prerequisites beyond the workout existing. While the annotations and schema fill in some gaps, the description alone is not fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 5 parameters, so baseline is 3. The description enriches the schema by specifying the accepted file extensions for file_path/file_data_base64 and confirming that the workout must already exist, adding value beyond the property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Upload' with the resource 'workout file' and clarifies allowed formats (.fit, .tcx, .gpx) and that the target is an 'existing workout', clearly distinguishing it from sibling tools like tp_download_workout_file or tp_delete_workout_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for attaching a file to an already-created workout and implies you should use it when you have a file to upload, but it does not explicitly name alternatives or exclusion criteria. The context is clear, but there is no direct comparison or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, and the description adds the explicit warning 'Repeating the call posts a duplicate,' which reinforces the non-idempotent behavior. It also clarifies that comments are appended to a thread, providing useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each with a distinct purpose: the action, the non-idempotency warning, and the prerequisite source. No wasted words, effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple append-comment tool, the description covers the action, side effect (duplicate posting), and necessary prerequisite. It lacks return value details, but without an output schema, this is not a major gap. The sibling context and annotations round out the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds value by explaining where to get the note_id, but does not elaborate on 'comment' or 'athlete' beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Append') and resource ('calendar note's thread'), clearly distinguishing it from sibling tp_add_workout_comment. It also mentions the source of note_id (tp_list_notes or tp_create_note), adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have a calendar note and want to append a comment) and references prerequisite tool calls for obtaining the note ID. It does not explicitly exclude alternatives like tp_add_workout_comment, but the phrase 'calendar note' differentiates it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations offer minimal cues (readOnlyHint=false, openWorldHint=true, etc.), so the description carries the burden. It adds two meaningful behaviors: rejecting bike-only fields on shoes and returning no ID on creation, prompting verification. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, second sentence adds crucial operational details with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the main behavior and verification path, but for a 12-param tool with no output schema it leaves gaps about response format and the exact semantics of many optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% of parameters having schema descriptions, the description's note on the 'type' enum and bike-only field rejection adds some meaning, but it doesn't compensate for the 8 undocumented parameters like brand, model, notes, or is_default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the verb 'add' and names the resource ('bike or shoes') and scope ('athlete's equipment list'), clearly distinguishing it from sibling tools like tp_get_equipment, tp_update_equipment, and tp_delete_equipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the use case of creating equipment without explicitly mentioning when not to use it. It does direct you to verify via tp_get_equipment afterward, offering a clear follow-up, but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a useful context clue about where to obtain file_id, but doesn't elaborate on return format or error scenarios. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. Every word adds value: the action, the resource, the key parameter, and the source of that parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward download tool with 4 parameters and annotations, the description is sufficient. It covers the essential hook (file_id source) and the schema handles parameter details. However, it doesn't mention behavior when output_path is omitted or whether the tool returns a path vs. binary content, which would be useful but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic value by specifying that file_id comes from tp_get_workout and referencing device_files/attachment_files, which helps the agent understand the parameter's origin. This exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download'), the resource ('workout file'), and the key identifier ('file_id'). It distinguishes this tool from siblings like tp_upload_workout_file and tp_delete_workout_file by focusing on retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage hint: 'Get file_id from tp_get_workout device_files/attachment_files.' This explains a prerequisite and implies when to use this tool (after fetching workout details). It doesn't explicitly exclude alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds value by disclosing the 'Max 90 days' date-range limitation and the specific return content (weekly TSS targets, training periods, races), which are not inferable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (12 words) and front-loaded with the core purpose. Every element earns its place: the resource, the contents, and the critical 90-day limit. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with strong annotations and a simple 3-parameter schema, the description covers the essentials: what the tool returns and a key constraint. It lacks explicit differentiation from the sibling tp_get_training_plan and does not mention the optional athlete parameter, but these are not critical given the schema and annotations. Overall, it is sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters (athlete, start_date, end_date). The description does not add further meaning or clarify parameter formats beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Annual Training Plan', and further specifies what it returns (weekly TSS targets, training periods, races). The mention of 'Annual' and the specific content distinguishes it from generic training plan tools like tp_get_training_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing the plan content and adds a concrete usage constraint ('Max 90 days'). However, it does not explicitly state when to use this tool over alternatives like tp_get_training_plan or exclude other types of plans, so it falls short of explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds context about return contents (author and timestamp) and the distinction from notes, but does not mention pagination, ordering, or empty-result behavior. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, source of required ID, and alternative. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with strong annotations, the description covers the essential elements: what is returned, where to get the required parameter, and a clear alternative. It doesn't detail the return format further, but that's acceptable given no output schema and the simple nature of the data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: athlete has a description, workout_id does not. The description partially compensates by noting that the workout ID comes from tp_get_workouts, but it does not elaborate on the athlete parameter. Adds some value but doesn't fully bridge the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource (comment thread on a workout), with added detail about athlete/coach comments and author/timestamp. It also distinguishes itself from the sibling tp_get_workout_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use this for workout comment threads, and directs users to tp_get_workout_note for the private workout note. Also gives a prerequisite by telling users the workout ID comes from tp_get_workouts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds scope context (account-level, coach-only), which is useful but does not disclose other behaviors like return format or pagination. This is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and contains no unnecessary words. It earns its place by adding the account scope and coach qualification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, a rich annotation set, and no output schema, the description sufficiently states what it returns (athletes available to the account). It could mention output shape, but for a simple list tool, this is adequate. The coach-account context adds necessary usage information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to compensate for schema gaps. The phrase 'available to this account' adds contextual meaning beyond the empty schema, reinforcing the scope of the returned data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('athletes'), with a scope qualifier ('available to this account'). The parenthetical '(coach accounts)' clarifies the intended audience and distinguishes it from sibling tools like tp_list_athletes_in_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it lists athletes available to the coach's account. While it doesn't explicitly name alternatives, the scope is specific enough to imply that group-specific listing should use tp_list_athletes_in_group. No exclusions are mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose non-read-only, idempotent, open-world, and non-destructive traits. The description adds the key behavioral nuance that adding to a new group also removes from the old one, which is useful beyond schema/annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, front-loaded with the action, and every word adds value. The move clarification is essential and efficiently worded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers the core operation and the important edge case of moving athletes. Annotations handle safety traits, and no output schema is needed. The description is complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (group_id, athlete_ids) are fully described in the schema with 100% coverage. The description does not add additional parameter-level detail beyond 'one or more athletes', so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add one or more athletes to a group') and the resource. It also distinguishes the tool from sibling tp_remove_athletes_from_group by explaining move semantics, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides usage guidance: use this tool to add athletes, and if moving an athlete, it handles both add and remove. It does not explicitly mention alternatives or when not to use, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the tool as destructive and non-read-only. The description adds meaningful behavioral context by stating that athletes inside the group are not deleted and that the default group cannot be deleted, which are important side-effect constraints not captured in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, direct sentences with no filler. The first sentence states the core action and the key exception (athletes not deleted); the second adds the important restriction about the default group. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers all essential aspects: what is deleted, what is preserved, and a critical constraint. The annotations provide the safety profile, so no further return-value or error details are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter group_id with a description ('Group (tag) ID'). The tool description does not add any additional parameter-level detail, so it stays at the baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete an athlete group') with a specific resource, and immediately clarifies that only the grouping is removed, not the athletes. This distinguishes it from sibling tools like tp_remove_athletes_from_group, which removes members while keeping the group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool deletes the group container itself, not the athletes inside it. It does not explicitly name alternative tools for removing athletes, but the implication is clear given the sibling list and the clarifying phrase 'athletes are not deleted.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond these: names are resolved from the coach's roster (which implies the output includes names, not just IDs). It also clarifies this operates on a single group. This is meaningful for an agent without an output schema, though it doesn't disclose edge cases like missing groups or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences. The first sentence states the action and object, and the second gives a practical cross-reference. No redundant or vague wording appears; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and strong annotations, the description covers the key aspects: what it lists, the single-group scope, the roster-based name resolution, and how to obtain the required group_id. It is complete enough for an agent to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the group_id parameter already described as 'Group (tag) ID from tp_list_groups.' The main description echoes this by saying 'Use tp_list_groups to get group_id,' which reinforces but does not add new semantic information. The parameter is simple and self-explanatory, so the description provides only marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('athletes in one athlete group'). It distinguishes the tool from sibling tp_list_athletes (which likely lists all athletes) and tp_list_groups (which lists groups). The added detail about names being resolved from the coach's roster further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on a prerequisite: 'Use tp_list_groups to get group_id.' This tells the agent how to obtain the required parameter. However, it does not explicitly contrast with tp_list_athletes or mention when to prefer this over listing all athletes, so it lacks a full when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable context by listing the output fields and specifying the scope (coach's authored plans), though it does not mention pagination or error conditions. This is sufficient given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes the key output fields without any extraneous content. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and no output schema, the description is complete: it specifies the resource, owner scope, and returned attributes. The annotations cover safety and idempotency, so no further clarification is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a complete description of the 'athlete' parameter, including its purpose and constraints, covering 100% of the parameters. The tool description does not add additional parameter-level semantics beyond what the schema already explains, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List', identifies the resource as 'coach's authored multi-week training plans', and enumerates the returned fields, making it clear and distinct from sibling tools like tp_get_training_plan which retrieves a single plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys that this tool is for listing training plans, and the optional athlete parameter provides context for coach accounts. However, it does not explicitly contrast with alternatives such as tp_get_training_plan or state when not to use it, so it lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds value by explaining what the tool returns (library exercise IDs, native parameters, demo video URL) and that it works offline, which are useful behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Search'), specifies the target resource, lists what is returned, and notes the offline constraint. Every phrase adds value and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with no output schema, the description adequately explains the return value (IDs, native parameters, video URL) and ties it to the broader workflow (tp_create_strength_workout). The input schema handles parameter details, so the description covers what the schema cannot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for query, limit, and muscle_group. The description reinforces that search is by name (query) and mentions the offline nature, but does not add substantive parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('built-in strength exercise library'), and clearly states the offline nature and the purpose of the returned IDs (for use in tp_create_strength_workout). This distinguishes it from sibling tools like tp_get_library_items, which likely handle user-created libraries rather than the built-in strength library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to find a strength exercise by name to include in a workout. It also notes the offline capability and mentions the downstream use case. However, it does not explicitly exclude alternatives or state 'use this instead of X', which would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the annotations: it warns that 'Repeating the call posts a duplicate,' which is a meaningful non-idempotency disclosure. It also clarifies the audience (both athlete and coach). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action, and includes a targeted alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description plus annotations cover the core use case: append a visible comment, with a warning about duplicates and a sibling note. However, it could mention the optional 'athlete' parameter (coach accounts) and that no return value is specified, but these are minor gaps given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only 'athlete' described in the schema. The description does not explain 'workout_id' or 'comment' semantics, nor does it add any parameter-level details. Since coverage is low, the description fails to compensate, leaving the agent to infer meanings from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append a comment'), the target resource ('workout's thread'), and the visibility scope ('visible to both athlete and coach'). It also distinguishes itself from the sibling tp_set_workout_note, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative usage: 'For a private note use tp_set_workout_note instead.' This tells the agent when not to use this tool and names the correct sibling, satisfying the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds usage context but no additional behavioral details such as what the status response contains or whether it performs a network verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and wastes no words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description states the action and intended usage, which is sufficient for basic invocation, though it does not spell out return format or possible outcomes. Given the simplicity, it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema imposes no burden. The description does not need to explain parameter fields; the baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' with resource 'auth status', clearly stating functionality. It distinguishes from sibling 'tp_refresh_auth' by focusing on status verification rather than token refresh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Use only when other tools return auth errors' provides explicit when-to-use context, giving a clear threshold for invoking this tool. It implies a diagnostic fallback role and helps avoid unnecessary calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds valuable context beyond annotations by explaining the limited flag semantics, sport_types list meaning, and the returned availability_id. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and then key nuances. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficiently complete for a create operation: it explains the main behavior, the limited/sport_types interaction, and the return value (in the absence of an output schema). It does not cover edge cases like overlapping availability, but that is not necessary for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), but the description compensates for the undocumented 'limited' parameter by explaining its boolean behavior and the role of sport_types. It also clarifies the output (availability_id) which the schema does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Mark a date range as unavailable for training (or limited to certain sports).' It clearly distinguishes this from sibling tools like tp_delete_availability and tp_get_availability by stating the create action and returning an availability_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool creates availability entries, and the mention of 'needed for tp_delete_availability' provides lifecycle context. It does not explicitly list alternatives or exclusions, but the purpose is self-evident among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, but the description adds the critical detail that the comment thread is also deleted, which is a non-obvious side effect. It also emphasizes 'irreversible', reinforcing permanence beyond the generic destructive hint. This provides value beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with intent, plus a short second sentence for the ID source. There is no redundancy or filler. Every clause contributes critical operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive tool with rich annotations, the description covers the primary effect, irreversibility, and dependency on a list operation. With no output schema, it need not explain return values. It omits explicit mention of the optional athlete parameter, but that is clearly specified in the schema. Overall, it provides sufficient context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only documents the 'athlete' parameter, leaving 'note_id' undocumented. The description compensates by pointing to tp_list_notes as the source for note_id, giving it meaning. The athlete parameter's purpose is already clear from its schema description. Thus both parameters acquire adequate semantic grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Permanently delete a calendar note and its comment thread'. This uses a specific verb (delete), specific resource (calendar note), and adds the scope (its comment thread), distinguishing it from other note-related tools like tp_get_note or tp_update_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete prerequisite: 'Note ID from tp_list_notes', which tells the agent where to obtain the required identifier. It also warns that the operation is 'irreversible', which is important usage guidance. It does not explicitly state when not to use this tool or compare to alternatives, but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by revealing that strength workouts live on a separate API and are absent from tp_get_workouts, plus it lists the exact return fields (date, title, duration, compliance, set totals, exercise preview). This is stronger than the baseline but stops short of detailing pagination, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each serving a distinct purpose: stating the function, clarifying the relationship to sibling tools, and enumerating the return fields. It is front-loaded with the core action and contains zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides the only information about return values, listing key fields. It also clarifies the separate API and points to the detailed retrieval tool, covering the essential context for a listing operation. However, it omits details like ordering, pagination, or any potential limitations when using the optional athlete parameter, leaving a minor gap for a tool with three parameters and no structured output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for all three parameters (athlete, start_date, end_date). The description does not add any extra meaning about parameters—it merely references the date range in general terms. Since the schema fully documents the parameters, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('structured strength/gym workouts') and scope ('in a date range'). It strongly distinguishes itself from sibling tools by explicitly stating that strength workouts do NOT appear in tp_get_workouts and that this tool is used to find them and their IDs, which is more than a generic restatement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to find strength workouts and their IDs, and provides a clear alternative (tp_get_workouts) while also directing users to tp_get_strength_workout for full detail. This gives explicit usage context and exclusions, far exceeding a vague 'use for listing workouts.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavior that an empty list is returned when no PRs exist, and scopes the operation to completed workouts. With annotations already declaring read-only, idempotent, and non-destructive behavior, this is useful supplemental context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the core purpose, the second provides the empty-list behavior and the alternative for period-based PRs. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of a clear purpose, empty-list return behavior, and explicit alternative make the description reasonably complete for a simple read-only query. Without an output schema, mentioning what fields a PR record contains would have been extra, but not strictly necessary since the description scopes the data sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the athlete parameter (coach accounts, omit for own profile) but leaves workout_id undocumented. The description implies workout_id refers to a completed workout, adding some semantic clarity, but it does not explain format or how the athlete parameter interacts with the result, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('personal records set during one completed workout'), clearly distinguishing it from tp_get_peaks, which covers period-based bests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool (for one completed workout) and points to tp_get_peaks as the alternative when the athlete's bests across a period are needed. This is clear usage guidance with an alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds value by stating the output: 'Returns block count, duration, estimated IF/TSS,' which clarifies expected results. It does not disclose failure behavior (e.g., error on invalid structure), but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: two sentences, no redundant words. Every clause adds information: what it validates, that it avoids creation, and what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter validation tool, the description is nearly complete. It explains purpose, output, and the relationship to tp_create_workout. The main gap is not describing what happens when validation fails (e.g., error codes or return structure for invalid input), which could be important for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the parameter's format via the reference to 'same format as the structure field in tp_create_workout,' which is useful for users familiar with that tool. It does not fully define the structure grammar but compensates with the cross-reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Validate workout interval structure without creating a workout.' It uses a specific verb ('validate'), a resource ('workout interval structure'), and explicitly contrasts with creating a workout, distinguishing it from sibling tools like tp_create_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without creating a workout' implies this tool is for pre-validation before creation, providing clear context. It also references tp_create_workout's structure format, linking it to the creation workflow. However, it does not explicitly state 'use this before creating' or mention alternative validation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral consequence that dates become plannable again, which goes beyond the destructiveHint annotation. It does not contradict any annotations; the idempotentHint is not mentioned but that is acceptable since the annotation already covers it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the action and effect front-loaded in the first sentence and a short, focused follow-up about the ID source. There is no unnecessary wording or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward delete operation, the description covers the purpose, the source of the required parameter, and the resulting state. Since there is no output schema, no return-value details are needed, and the annotations handle the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides essential guidance for the 'availability_id' parameter, directing the agent to tp_get_availability or the create response, which compensates for the parameter's missing description in the schema. The 'athlete' parameter is already adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and resource 'availability entry', making its purpose unmistakable. It also states the outcome (dates become plannable again) and clearly distinguishes from sibling tools like tp_get_availability and tp_create_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (to remove an availability entry) and gives a practical hint for obtaining the required ID. However, it does not explicitly discuss alternatives or exclusions, though no relevant alternatives exist among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description elaborates on the irreversible nature ('Permanently delete', 'irreversible') and the cascading effect ('every template inside it'). It also discloses the limitation of no per-template delete, adding valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and consequences, and every clause contributes critical information. It is concise but complete, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a single required parameter, rich annotations, and no output schema, the description covers the essential context: the destructive scope, irreversibility, and a warning to preserve important items. It is fully sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: athlete is documented in the schema, but library_id is not. The description does not address parameters directly, but the required library_id is self-evident from the tool name and phrase 'delete a library'. The optional athlete is already explained in the schema, so the description adds little parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Permanently delete a library AND every template inside it'. It specifies the resource (library) and the action (delete), and distinguishes from siblings by noting there is no per-template delete, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Schedule anything you want to keep first' and explicitly warns about the lack of per-template delete, which frames when to use this tool. It does not explicitly name alternative tools, but the context makes it clear this is the only way to delete a library and its contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true. The description adds context by emphasizing 'irreversible' and specifying that it applies to both planned and completed workouts—useful behavioral details beyond the raw hint. It does not mention auth or rate limits, but annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, followed by a caveat and a parameter hint. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with no output schema and two parameters, the description covers purpose, scope, irreversibility, and parameter sourcing. It is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; 'athlete' is described but 'workout_id' is not. The description compensates for 'workout_id' by telling the agent to obtain it from tp_get_workouts, adding practical meaning. The 'athlete' parameter remains covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Permanently delete a workout from the calendar.' It also clarifies scope ('planned and completed workouts alike'), distinguishing it from sibling tools like tp_update_workout or tp_create_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by instructing to get the 'Workout ID from tp_get_workouts,' which establishes a necessary prerequisite and workflow. It does not explicitly name alternatives or exclusions, but the use case is evident from the destructive scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and non-destructive, so the safety profile is covered. The description adds valuable detail about the response contents (prescribed vs executed values, RPE, feel, compliance), which is especially useful since no output schema is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the core purpose and immediately provides essential context (where to find IDs). Zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description covers all key aspects: what it returns, how to identify the workout, and implicitly when to use it. With read-only annotations, no output schema, and 2 simple parameters, this is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing descriptions for both workout_id and athlete. The description adds extra guidance by telling users to get IDs from tp_get_strength_workouts, enriching the meaning of workout_id beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a strength workout's full detail by ID, listing specific contents (blocks, exercises, sets, RPE, feel, compliance). This distinguishes it from siblings like tp_get_strength_workouts (list) and tp_get_workout (general).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to get IDs from tp_get_strength_workouts, providing a clear prerequisite. It does not explicitly mention alternative tools or exclusions, but the context of full-detail-by-ID is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds behavioral detail beyond that: it probes the zone calculator to fingerprint methods by zone labels, and it explains that `derives_threshold` indicates threshold derivation from a test, so a direct threshold can't be set. This is meaningful context not captured in annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first gives the main action; the second gives the tool's reason for existence; the third explains a key output field and scope. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately covers return values (zone count, zone labels, `derives_threshold` flag), internal behavior (probing the zone calculator), and scope (coach-scoped). The tool is simple and has one optional parameter, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of the only parameter `metric`, including an enum (power/heartrate/speed) and the instruction 'Limit to one metric. Omit to list all three.' The tool description only restates the metric names without adding extra semantics, so the baseline 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List available zone-calculation methods per metric (power / heartrate / speed), each with its zone count and zone labels.' This is a specific verb (List) plus a clear resource, and it distinguishes the tool from sibling zone tools like tp_update_hr_zones or tp_create_zones, which modify zones rather than list methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the context and rationale: 'TP has no method-names endpoint and settings store only an opaque method int; this probes the zone calculator...' It also provides a clear scope exclusion: 'Coach-scoped (uses your own user), not athlete-specific.' However, it does not explicitly name alternative tools for when not to use this one, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value beyond annotations by specifying the return schema (id, name, athlete_count, is_default) and the fact that groups are exposed as tags, which is useful for data representation. This exceeds the baseline but doesn't cover pagination or limits, though these are likely unnecessary for this simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and includes the essential return fields. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with strong annotations and no output schema, the description fully covers what the tool returns, the tag nuance, and the coach scope. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and coverage is effectively 100%. The baseline for zero parameters is 4, and the description correctly adds no extraneous parameter details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'coach's athlete groups' and clarifies that TP exposes these as tags, which distinguishes it from sibling tools like tp_list_athletes and group mutation tools. It also names the return fields, fully specifying the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: it's for retrieving athlete group metadata. It doesn't explicitly mention alternatives or when not to use it, but the simple zero-parameter nature makes the usage obvious. A more explicit pointer to sibling tools like tp_list_athletes_in_group would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only indicate it's not read-only), the description discloses that bands are computed by TrainingPeaks' calculator, and reveals two specific behavior outcomes: ZONES_EXIST if already present and TEST_BASED_METHOD for unsupported methods. This concrete behavioral context is highly valuable for an agent deciding whether to call this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: two sentences deliver the primary purpose first, then the exceptions and redirects. Every clause earns its place, with no filler or redundant rephrasing of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema), the description covers purpose, use conditions, and unsupported cases effectively. It even mentions two return statuses. However, it does not outline the success response shape or fully explain how parameters interrelate for different sports, leaving a slight gap in an otherwise thorough description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is moderate (56%), and the description adds some context by explaining that calculation_method determines how bands are computed and pointing to tp_get_zone_methods. However, it does not clarify cross-parameter dependencies (e.g., which parameters apply to power vs. heartrate vs. speed), so the agent may still be uncertain about required inputs for each metric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a NEW per-sport zone set' with a specific verb and resource, and immediately distinguishes itself from sibling tools by naming tp_update_ftp/hr_zones/speed_zones for modifying existing sets. This makes the tool's unique role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool only when the athlete has no existing set for that sport, and points to the update tools for existing sets. It also excludes test-derived methods (Distance/Time) from being created here, directing to the TP UI instead. This is clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds context about the interval structure being included and the intended reuse scenario, which goes beyond the structured hints. However, it does not detail return format or edge cases, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the main purpose and immediately provides usage context and ID sourcing in a compact way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has strong annotations, and the description covers the core purpose, return expectation (full template with intervals), and usage context. There is no output schema, but the description's detail about interval structure helps set expectations. A small gap is not specifying possible response variations, but overall it is sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only athlete described). The description compensates by indicating that IDs come from tp_get_library_items, which effectively explains the library_id and item_id parameters. It does not describe each parameter individually, but the provided sourcing hint adds meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single workout template in full, including its interval structure. It distinguishes itself from the plural list tool tp_get_library_items and from tp_schedule_library_workout by emphasizing the full detail retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use this tool: before tp_schedule_library_workout or when reusing the structure. It also points to tp_get_library_items for the source of IDs, giving concrete guidance on how to obtain valid inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds context with 'slim listing' (implying a lightweight response) and the relationship to other library tools. It does not detail pagination or return fields, but the annotation coverage lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the purpose front-loaded and each sentence adding essential value: the first defines the scope, the second covers parameter sourcing and an alternative for related functionality. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and strong annotations, the description covers purpose, parameter source, and alternative usage. The lack of return payload details is partially mitigated by 'slim listing', but the absence of any output schema means a bit more detail on response structure would be ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes 'athlete' but leaves library_id undocumented. The description compensates by explaining that library_id comes from tp_get_libraries and is the identifier for the library being listed. This provides meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'List' and resource 'workout templates in one library', immediately clarifying the tool's function. It also distinguishes from siblings by noting 'slim listing' and explicitly referencing tp_get_library_item for full interval structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: library_id should come from tp_get_libraries, and if full interval structure is needed, use tp_get_library_item instead. This clearly communicates when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive (destructiveHint=false) and not read-only, so the description's 'preserves everything else' aligns and adds specificity about Garmin-derived TSS and attached FIT file. It further explains why in-place update is safe for training load, providing context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and key operations, followed by a high-value usage warning. Every sentence earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-param mutation tool with no output schema, the description covers core behavior, the primary use case, and the critical preservation guarantee (TSS, FIT file). It doesn't describe return format or auth, but the schema and annotations cover the details, making this sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds workflow-level meaning by linking mode and mark_complete to the device-synced workout scenario, and clarifies that omitting blocks preserves existing structure. This goes beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing strength workout 'in place' with specific operations: replace/append blocks, retitle, or mark complete. This specific verb+resource combination distinguishes it from siblings like create, delete, and get strength workouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is 'the correct way to fill in a device-synced workout' and warns 'Never delete-and-recreate for that' because exercise detail is rebuildable but HR-derived training load is not. This gives clear when-to-use and when-not-to-use guidance including an alternative to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds valuable behavioral context by emphasizing 'irreversible' and 'permanently delete', which goes beyond the annotation. It also clarifies that this tool only affects calendar events, not workouts, preventing misuse. This is useful context despite the annotations covering the core destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. Each sentence earns its place: the first states the destructive nature, the second provides the source of the ID and the alternative for workouts. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter destructive tool with no output schema, the description covers all needed context: irreversibility, how to get the ID, and the distinction from workout deletion. The schema covers the athlete parameter adequately, and the description fills the gaps. Nothing critical is missing for the agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for only the 'athlete' parameter (50% coverage), leaving 'event_id' undocumented. The description compensates for this gap by explicitly stating 'Event ID from tp_get_events', adding crucial meaning to the event_id parameter. It does not repeat the athlete schema description, which is already clear. This adds meaningful information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Permanently delete a race/event from the calendar'. It uses a specific verb ('delete') and resource ('race/event from the calendar'), and directly distinguishes itself from the sibling tool tp_delete_workout by noting calendar workouts are separate. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: it tells the agent to obtain the event ID from tp_get_events, and explicitly directs that calendar workouts should be deleted with tp_delete_workout instead. This gives clear context for selecting this tool over alternatives and names the specific sibling tool, which is exactly what the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the tool returns all sport types and subtypes with IDs, and that it is intended for finding subtype_id. This is useful context beyond the annotations, though it doesn't delve into edge cases like pagination or extremely large lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two short, purposeful sentences. The first states the core behavior, and the second provides the key usage context. There is no redundancy or filler, making it ideal for quick agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and a simple lookup operation, the description is fully adequate. It states what is returned (all types and subtypes) and why to use it (to get subtype_id for create/update). This is all the agent needs to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is trivially 100%. Since there are no parameters, the description doesn't need to explain them, but it does clarify the output (IDs) which is helpful. The baseline for 0 parameters is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all sport types and subtypes with IDs', which is a specific verb and resource that clearly states what the tool does. This distinguishes it from sibling tools that focus on individual workouts or notes, as it uniquely handles type/subtype lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to find subtype_id for create/update', giving a clear when-to-use directive tied to downstream operations. This is a strong usage guideline, even without naming alternatives, because the tool's purpose is unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds valuable behavioral detail: it clarifies the operation affects only display order and requires the complete set of workout IDs. This reduces ambiguity about side effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and immediately follow with the key usage instruction. Every sentence earns its place, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reordering tool with full schema coverage and good annotations, the description explains the scope, the required input, and the limits of the operation. No significant gaps remain for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters, but the description adds crucial semantics for workout_ids: they must include every workout ID for that day and come from tp_get_workouts. This enhances the schema's 'desired display order' by specifying the required completeness and source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reorder') and the resource ('workouts displayed on a single day'), and explicitly distinguishes it from other tools by noting it only changes display order, leaving dates and content untouched. This distinguishes it from sibling tools like tp_update_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context: reordering workouts on a day, and explicitly instructs to pass every workout ID from tp_get_workouts. It does not explicitly name an alternative tool, but the 'Changes display order only' exclusion provides implicit guidance for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, but the description adds crucial behavioral constraints: the maximum 90-day range and the exclusion of strength-builder workouts. This goes beyond annotation-only information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, dense sentences. No filler. The most important information (what it does, usage tip, and exclusion) is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description covers all necessary context: what it lists, what to query, the day limit, the exclusion, and the alternative tool. It is complete enough to use without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameter descriptions, so the baseline is 3. The description adds the meaningful constraint that the date range must be within 90 days, which directly informs how start_date and end_date should be used. This slight addition justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List') and resource ('workouts') with a clear scope ('in date range'). It distinguishes itself from siblings by explicitly mentioning it excludes strength-builder workouts and points to the alternative tool tp_get_strength_workouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Query only days needed' and 'Max 90 days', which helps avoid excessive requests. It also tells when NOT to use it (strength-builder workouts) and names the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![TrainingPeaks-MCP MCP server](https://glama.ai/mcp/servers/JamsusMaximus/TrainingPeaks-MCP/badges/card.svg)](https://glama.ai/mcp/servers/JamsusMaximus/TrainingPeaks-MCP)

Score Badge

Copy to your README.md:

[![TrainingPeaks-MCP MCP server](https://glama.ai/mcp/servers/JamsusMaximus/TrainingPeaks-MCP/badges/score.svg)](https://glama.ai/mcp/servers/JamsusMaximus/TrainingPeaks-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JamsusMaximus/TrainingPeaks-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server