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

With no annotations, the description carries the burden of disclosing behavior. It clearly indicates a write operation ('add'), but doesn't mention permissions, side effects on existing comments, or whether the note must exist. It provides only the basic action with no extra context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence with no redundant words. It conveys the essential purpose perfectly and is well-structured for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple add operation with complete schema coverage and no output schema, the description is adequate. However, it lacks guidance on when to use vs. alternatives (tp_add_workout_comment) and doesn't state what the tool returns (e.g., success message or created comment).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all three parameters (athlete, comment, note_id) are already documented with descriptions. The tool description adds no additional parameter meaning beyond what the schema provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Add a comment to a calendar note.' It clearly distinguishes this from sibling tools like tp_add_workout_comment by specifying 'calendar note', and from read-only tools like tp_get_note_comments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when adding a comment to a note), but provides no explicit exclusions or alternatives. It doesn't mention that tp_add_workout_comment is for workouts or that tp_get_note_comments is for retrieval.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action without revealing whether comments are appended, if permissions are required, or what error behavior occurs. This is insufficient for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero fluff. It is appropriately concise for a simple operation, though it sacrifices detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no annotations, no output schema, and a one-sentence description. It lacks essential context such as return values, permission requirements, and behavior on invalid inputs, making it inadequate for reliable agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only 'athlete' is described), and the tool description adds no parameter details. The agent is left to guess the format and purpose of 'workout_id' and 'comment' beyond their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Add a comment to a workout' uses a specific verb and resource, clearly distinguishing it from sibling tools like tp_add_note_comment and tp_get_workout_comments. It unambiguously states the operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, such as needing coach accounts for the 'athlete' parameter, nor any contrast with read-only tools like tp_get_workout_comments.

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

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

With no annotations, the description carries the full burden and does disclose a key side effect: saving the full time-series to a JSON file. However, it lacks details such as whether the file is overwritten, where it is saved, or any permissions/rate limits, leaving uncertainty about the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the primary purpose and a key side effect. Every word earns its place, with no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives a brief overview of the tool's functionality and notes the JSON file side effect, but it lacks important context such as return value, file handling details, and differentiation from sibling tools. For a tool with a side effect and multiple related tools, more completeness is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50%, with only the 'athlete' parameter having a description. The tool description does not mention either parameter and provides no additional meaning for 'workout_id', the only required parameter, which remains undocumented. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves workout analysis including metrics, zones, and laps, and mentions saving full time-series to a JSON file. It has a specific verb ('Get') and resource ('workout analysis'), but does not explicitly differentiate it from sibling tools like get_workout or get_workout_prs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied through the mention of metrics, zones, laps, and saving to a JSON file, but there are no explicit when-to-use or alternative comparisons. The description does not state when to prefer this over similar tools like download_workout_file or get_workout.

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

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

No annotations are provided, so the description must disclose behavioral traits. The description claims a 'check' but does not explicitly state that it is read-only, has no side effects, or what the response contains. This is a minimal disclosure, leaving behavioral assumptions ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, each serving a purpose: the first defines the function, the second narrows usage. No redundant or extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain what the status check returns or indicates. It does not, leaving the agent unsure whether the output is a boolean, a message, or structured auth details. For a diagnostic tool, this gap is significant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters with a fully described empty schema, so the baseline is 4. The description correctly adds no parameter details since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool's verb and resource: 'Check auth status'. The description is specific and distinguishes it from sibling tools like tp_refresh_auth by implying a read-only status check rather than a refresh action, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: 'Use only when other tools return auth errors.' This tells the agent exactly when to invoke it, and implies not to use it otherwise. However, it does not mention alternative tools like tp_refresh_auth for resolving the errors.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what is copied (structure, description, planned fields) but omits critical details such as whether the copy overwrites an existing workout on the target date, whether comments/files are also copied, or any permission requirements. This is a notable 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loading the core action and immediately stating the scope of the copy. There is no redundant or extraneous information, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has moderate complexity with 4 parameters and no output schema, but the description does not explain return values, behavior on conflicts, or prerequisites. It lacks details about what happens after the copy (e.g., whether a new workout ID is returned) and how existing workouts on the target date are handled. More context is needed for an agent to use it safely and effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage of parameters, so the description adds little beyond the schema. The phrase 'structure, description, planned fields' helps clarify the meaning of the source workout_id and target_date context, but no additional parameter-specific syntax or format details are provided. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Copy a workout to a new date.' It specifies the resource (workout) and the action (copy), and distinguishes it from create/update/delete by framing it as a duplication operation. The phrase 'Copies structure, description, planned fields' adds specificity about what is copied, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for duplicating a workout to a different date, but it does not explicitly state when to use it versus alternatives like creating a new workout or scheduling a library workout. No exclusions or alternative tool names are given, so usage context is only implied rather than clearly articulated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., overwriting existing availability), permission requirements (coach accounts for athlete), or return values. The phrase 'Mark dates as unavailable or limited' only states the immediate action without revealing operational consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tightly worded sentence with no redundancy. It is front-loaded with the verb 'Mark' and conveys the essential purpose without wasting words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

As a mutation tool with 5 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It omits critical details like how 'limited' differs from 'unavailable', the purpose of sport_types, and any constraints or side effects. The description is not complete enough for an agent to fully understand the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80% (4/5 parameters documented), and the description adds minimal extra meaning beyond hinting at the 'limited' boolean. It does not clarify how sport_types relates to limited, nor does it compensate for the missing description of the 'limited' parameter. The baseline is 3 due to high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Mark dates as unavailable or limited' clearly conveys the core action of creating availability entries and distinguishes it from retrieval (get_availability) and deletion (delete_availability). However, it could be more explicit about creating a new availability record, so it doesn't earn a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool, no mention of alternatives like tp_get_availability or tp_delete_availability, and no context for how it fits into the workflow. It is a single sentence with no directional pointers.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Add new equipment' implies a write operation but does not mention whether the operation is irreversible, requires specific permissions, or what the response contains. This is minimal disclosure with no extra context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence with no redundancy or unnecessary words. It is front-loaded and easy to scan, though slightly too terse for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 parameters, no output schema, and no annotations, the description provides almost no context. It omits key aspects like the optional athlete parameter for coach accounts, bike/shoe-specific fields, and any expected return value, making it inadequate for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, and the description adds no parameter details beyond 'bike or shoe,' which is already captured in the type enum. It fails to compensate for the 67% of parameters (e.g., max_distance_km, starting_distance_km) that lack descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Add new equipment (bike or shoe)' clearly states the action (add) and the resource (equipment), specifying the two allowed types. This distinguishes 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The verb 'Add' implies this tool is for creating new equipment, but no explicit when-to-use guidance or alternative references are provided. It does not mention using tp_update_equipment for existing items, leaving usage as implied rather than explicit.

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

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

No annotations are provided, so the description carries the full responsibility for disclosing side effects. It only mentions the basic creation action, without addressing auth requirements (e.g., coach-only athlete targeting), idempotency, or behavior for duplicate events. The description also lists priority and CTL target without noting they are optional in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no wasted words. It efficiently conveys the core action and key attributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, no output schema, and no annotations, the description is sparse. It establishes the purpose but does not mention how to choose event_type or what the response will be. Required fields (name, date) are self-explanatory, so this is minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25%, so the description should compensate. It adds meaning to priority and ctl_target by naming them, but leaves event_type, description, and distance_km without further clarification. Partially helpful but incomplete for a tool with 8 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and the resource ('race/event'), while highlighting key attributes (priority A/B/C and CTL target). This distinguishes it from sibling tools like tp_create_workout or tp_create_equipment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternatives such as tp_create_workout or tp_create_availability. There is no mention of prerequisites, exclusions, or preferred contexts.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'Create' but does not mention side effects, permissions, idempotency, error behavior, or what happens if the library already exists. This is insufficient 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no fluff or redundancy. It efficiently communicates the core action and resource, earning a high score for concise structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks essential context for a create operation without annotations or output schema. It does not explain what a library folder is, how it relates to library items, what the return value is, or any operational context. This makes it incomplete for an agent to use confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the 'athlete' parameter with a description, but the 'name' parameter has no description and the tool description does not compensate. With only 50% schema coverage, the description adds no parameter-level meaning, leaving the 'name' parameter ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and the resource ('workout library folder'), which is distinct from siblings like tp_create_library_item. However, it does not explicitly differentiate from related tools or mention the folder concept's role, so it falls short of a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like tp_get_libraries or tp_create_library_item. There are no conditions, prerequisites, or exclusions mentioned, leaving usage implied only by the tool name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'save' implying a write operation, but gives no information about auth requirements, idempotency, side effects, return values, or prerequisites. This is a significant transparency 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no wasted words. It is concise and immediately communicates the core purpose, though it is so short that it sacrifices substance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters, 4 required fields, a nested structure object, and no output schema, a one-line description is grossly insufficient. It omits important context such as how sport IDs are resolved, whether the library must already exist, what the response contains, and how this relates to sibling library tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 44%, and the tool description adds no parameter-level meaning. It does not explain required fields like library_id, name, sport_family_id, sport_type_id, or the optional structure object. The description fails to compensate for the schema's incomplete coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Save a workout template to a library') with a specific verb and resource, and it distinguishes the tool from related siblings like tp_create_workout and tp_create_library. However, it does not explicitly name alternatives or edge cases, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives, prerequisites, or typical scenarios. The description merely states what it does, leaving the agent to infer appropriate usage from the tool name and siblings.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. However, it only states the action without mentioning side effects, permission requirements (e.g., coach account for athlete parameter), or any implications of creating a note. No additional behavior is disclosed beyond the fundamental action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the action. There is no wasted wording or redundant structure. However, it is arguably too brief to fully serve its purpose, which slightly reduces the score from a perfect conciseness rating.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema or annotations, the description is expected to provide more context. It does not explain what constitutes a calendar note, how it differs from events, or what the response will look like. Given the tool's moderate complexity (4 parameters, special athlete field), the description is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50%, and the description adds no parameter details. It does not explain the `title` and `description` fields, nor does it clarify the `date` format beyond what the schema provides. Since the description does not compensate for the missing schema descriptions, it offers minimal parameter-level value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Create') and resource ('calendar note'), clearly distinguishing it from sibling note tools like tp_get_note/tp_update_note and other create tools such as tp_create_workout/tp_create_event. The resource is specific enough to convey 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.

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 state when to use this tool versus creating an event, availability, or updating an existing note. There are no 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.

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

No annotations are provided, so the description carries full burden. It does disclose one behavioral trait: 'Duration is auto-computed only from simplified structure when not provided,' which clarifies the effect of omitting duration_minutes. However, it does not mention permissions, idempotency, error behavior, or what the tool returns on success. The lack of an output schema means the agent cannot infer return semantics, leaving a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exactly two sentences. The first sentence front-loads the core purpose and key options, the second provides a critical behavioral caveat. There is no redundancy, fluff, or repetition of schema details. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex creation tool with 15 parameters, nested objects, no annotations, and no output schema. The description is minimal and does not explain what the tool returns, how to verify success, or common failure modes. It also does not mention that tp_validate_structure exists as a companion for validating interval structures. Given the complexity, the description is under-equipped for a safe autonomous invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 93%, so the schema itself documents most parameters. The description adds value by clarifying the relationship between duration_minutes and structure: 'Duration is auto-computed only from simplified structure when not provided.' It also clarifies the two competing structure formats (simplified vs native structured_workout), which is not fully clear from schema alone. This extra context pushes it above the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: "Create a planned workout" – a specific verb with a specific resource. It also distinguishes this from sibling tools like tp_update_workout or tp_copy_workout by explicitly limiting it to creation, and mentions the two input modes (simplified structure or native TP payload). This is unambiguous and well-scoped.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating workouts but does not explicitly compare against alternatives like tp_update_workout for modifications or tp_validate_structure for pre-checking. There is no 'when not to use' guidance. The note about auto-computed duration gives some conditional guidance, but overall the when-to-use context is implicit rather than explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remove an availability entry.' only states the action but does not disclose consequences like irreversibility, side effects on related data, or authentication requirements. This is insufficient for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler words, front-loading the core action. It is appropriately concise for a simple delete tool, though the lack of supplementary information means it is under-specified rather than efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters, no output schema, and no annotations, the description is inadequate. It fails to explain the purpose of the required availability_id, the optional athlete parameter, whether deletion is permanent, or any related side effects. The context of sibling tools (create/get availability) also suggests that more detail is needed to avoid misuse.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, with only the 'athlete' parameter described. The 'availability_id' parameter has no schema description and the tool description does not mention it at all. The description adds zero semantic value to either parameter, leaving the agent to guess how to identify the entry to delete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Remove an availability entry.' clearly states a specific verb (remove) and resource (availability entry), which distinguishes it from sibling tools like tp_create_availability and tp_get_availability. It is unambiguous and directly reflects the tool's purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, prerequisites, or exclusions. The description does not mention whether deletion is permanent, if special permissions are required, or any context for appropriate use. This leaves the agent without clear decision support.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that deletion is likely permanent, whether it removes associated records, or any dependency on permissions. This is a significant gap for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (two words) and front-loaded, but it is under-specified. While brevity is an asset, it sacrifices essential detail, making it barely acceptable as a minimum viable description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (2 parameters, no output schema) and the availability of sibling CRUD tools, the description is incomplete. It lacks any mention of return behavior, side effects, or usage conditions, making it insufficient for an agent to safely invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, with the required equipment_id having no description. The description adds no parameter semantics, leaving the agent to infer that equipment_id is the identifier of the equipment to delete. The optional athlete parameter is briefly described in the schema but not clarified in the tool description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete equipment' clearly states the verb (delete) and resource (equipment), distinguishing it from sibling tools like tp_create_equipment and tp_get_equipment. It is specific and unambiguous, though it lacks any additional context about scope or effects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description simply states the action without contextualizing it against similar tools.

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

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

No annotations are provided, and the description fails to disclose any behavioral traits beyond the basic action, such as whether deletion is permanent, any cascading effects, or access requirements. This is a significant gap for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise, consisting of a single short sentence. While it avoids unnecessary words, it is under-specified and does not earn its place by adding critical information; however, it is more specific than a pure tautology.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description is incomplete. It lacks information about return values, error conditions, or the context in which the event exists, making it insufficient for an agent to fully understand the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50% (event_id lacks a description), and the tool description mentions no parameters at all. It does not clarify the meaning of event_id or the optional athlete parameter beyond what appears in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'delete' and resource 'event', clearly conveying the operation. It distinguishes from sibling tools like tp_create_event and tp_update_event, as no other tool in the sibling list is named 'delete_event'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool relative to alternatives, such as conditions for deletion (e.g., ownership, coach permissions). It simply states the action without context or exclusions.

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

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

The description explicitly states the destructive cascade ('all templates'), which is valuable behavioral context. However, with no annotations, it does not disclose irreversibility, required permissions, or effects on scheduled workouts using those templates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the action and key side effect without any filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with no annotations or output schema, the description leaves important context missing, including how to obtain library_id, behavior for coach/athlete contexts, and what happens to scheduled workouts. It is minimally viable but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% (library_id has no description). The description does not explain the format or meaning of library_id, and entirely omits the athlete parameter, which is critical for coach accounts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the verb ('Delete'), the target resource ('library folder'), and the scope ('and all templates'). This distinguishes it from sibling delete tools such as tp_delete_workout_file 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.

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_delete_library_item for deleting a single item. The description does not mention prerequisites, exclusions, or how to find the library_id.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('delete') without revealing consequences such as permanence, side effects on comments, or required permissions. The description adds no context beyond what the tool name already implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no unnecessary words. It is front-loaded and easy to parse. However, it is slightly under-specified, as it could have added a hint about parameters without significant bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a delete operation with two parameters and no output schema, the description is too sparse to be considered complete. It does not mention irreversibility, related data (e.g., comments), or any constraints. Even simple tools benefit from clarifying that deletion is permanent. The description offers no additional context beyond the tool name.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% — the required 'note_id' parameter lacks any description in the schema. The tool description does not mention this parameter at all, leaving its format or purpose implicit. The optional 'athlete' is described in the schema, but the description does not compensate for the undocumented 'note_id'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Delete') and resource ('a calendar note'), clearly distinguishing it from siblings like tp_delete_workout or tp_delete_event. The term 'calendar note' disambiguates from workout notes, 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.

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 want to remove a calendar note) but provides no explicit guidance on alternatives or exclusions. There is no mention of related tools like tp_update_note or tp_delete_event, so usage context is only inferred from the action itself.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It says only 'Delete a workout' with no mention of irreversibility, cascading effects, permission requirements, or impact on associated data. For a destructive operation, this is critically insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with zero wasted words, making it easy to parse. However, it borders on under-specification, sacrificing necessary context for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a delete operation, the description is severely incomplete. It does not state whether deletion is permanent, what data is removed, or any special considerations for coach accounts (mentioned in the schema). With no output schema and no behavioral context, an agent cannot safely predict the tool's effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides a description for 'athlete' but not for 'workout_id'. The description adds no information about either parameter, failing to compensate for the 50% schema coverage. An agent has no help understanding what workout_id refers to or how the athlete parameter affects deletion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Delete' and the resource 'a workout', making the primary purpose obvious. However, it does not differentiate from sibling tools like tp_delete_workout_file or tp_delete_equipment, and lacks details about the scope of deletion (e.g., permanent, cascading).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions, and no context about intended use cases. An agent is left without any decision framework.

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

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

No annotations are provided, so the description carries full burden. It only says 'Delete' without disclosing whether deletion is permanent, requires permissions, or affects associated workout data. This is a minimal disclosure for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, concise and direct. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so description should cover side effects and prerequisites. It only covers file_id source, leaving questions about reversibility, authorization, and success/failure responses. Incomplete for a delete operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage, so parameters are described. The description adds specific guidance for file_id, telling where to obtain it, which supplements the schema. No additional meaning for workout_id or athlete beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a workout file by file_id' with a specific verb and resource, distinguishing it from sibling upload/download/delete-workout tools. It also tells the user where to find the file_id, reinforcing the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides context by instructing to get file_id from tp_get_workout device_files/attachment_files, which helps when to use. However, it does not explicitly mention alternatives or exclusions, e.g., when to use tp_download_workout_file or tp_delete_workout instead.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Download a workout file' but does not mention side effects (e.g., whether the file is saved to output_path or returned as binary), any authentication requirements, or error behavior. This leaves significant ambiguity for the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action, and contains no fluff. Every word earns its place, making it an excellent model of conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core action and provides a source for file_id, but given the tool has 4 parameters and no annotations or output schema, it lacks important contextual details such as what happens if output_path is omitted or what the tool returns. The schema covers parameter descriptions, but the description does not fully explain the tool's overall behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the relationship between file_id and tp_get_workout, which is not fully captured in the schema's parameter descriptions. This extra context helps the agent understand how to fill the parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: 'Download a workout file by file_id.' This clearly identifies the tool's function and differentiates it from sibling tools like tp_upload_workout_file and tp_delete_workout_file. It also provides a helpful pointer on obtaining the file_id, which enhances clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by stating 'Get file_id from tp_get_workout device_files/attachment_files,' which tells the agent how to obtain a required parameter. It does not explicitly mention when not to use the tool, but the purpose is clear and no alternative download tool exists among siblings.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It lists the data returned (FTP, thresholds, zones, profile), which is useful, but it does not explicitly state that the operation is read-only, mention permissions beyond the schema's coach note, or explain potential errors or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-front-loaded sentence that efficiently communicates the tool's purpose and scope. No unnecessary words or repetition, making it an ideal concise description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with one optional parameter and no output schema, the description is adequately complete: it names the resource and the primary data categories returned. It could mention whether the response reflects current or saved settings, but overall it provides enough context for correct tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage for the single optional parameter, clearly describing it as a target athlete name/ID for coach accounts. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets 'athlete settings' and enumerates specific contents (FTP, thresholds, zones, profile), which distinguishes it from sibling tools like tp_get_profile. It uses a specific verb 'get' and a clear resource, though it could more explicitly differentiate itself from closely related getters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool's usage is implied by its name and description as a getter for athlete settings, and the input schema notes the optional athlete parameter is for coach accounts only. However, there is no explicit guidance on when to use this tool versus alternatives like tp_get_profile or tp_get_fitness, and no exclusions are stated.

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

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

The description discloses the key behavior of returning weekly TSS targets, training periods, and races, and includes a hard limit of 90 days on the date range. However, it does not mention authentication requirements, error behavior, or whether the operation is safe (read-only). Since no annotations are provided, the description carries the burden but provides only moderate detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the verb and resource, followed by specific content and a constraint. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool, the description covers the essential return contents and a key limitation. It does not describe the output schema (there is none) or potential errors, but given the simplicity and the schema's completeness, it is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Though schema descriptions cover all three parameters at 100%, the description adds the critical constraint 'Max 90 days' that applies to the date range parameters. This is not present in the schema, so the description enriches parameter understanding beyond the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets an Annual Training Plan and specifies its contents (weekly TSS targets, training periods, races). This distinguishes it from sibling tools like tp_get_peaks or tp_get_weekly_summary, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use vs. alternatives. The 'Max 90 days' constraint provides some context, but there is no mention of alternatives or exclusions. The description implies usage for annual planning but does not clarify scenarios where other planning tools might be more appropriate.

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

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

With no annotations provided, the description carries the full burden. It does not disclose whether the operation is read-only, the response format, auth requirements, or behavior for the optional 'athlete' parameter. This is a minimal description that adds no behavioral context beyond the verb 'Get'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It communicates the core function efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description should have explained return values or additional context. It does not address what the availability entries contain, how the date range is interpreted (inclusive/exclusive), or the coach/athlete distinction implied by the 'athlete' parameter. This leaves the agent under-informed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 3 parameters are fully described in the input schema (100% coverage), so the description does not need to explain them. The description adds no extra parameter semantics beyond what the schema already provides, earning the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Get), the resource (availability entries), and the scope (date range). It distinguishes from sibling tools by the verb 'Get' versus 'Create'/'Delete' in tp_create_availability and tp_delete_availability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or comparisons to other tools like tp_get_events or availability-related mutations.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'List equipment', omitting any details about access restrictions (e.g., coach-only via the athlete parameter), read-only nature, or return format. The bare statement provides minimal transparency beyond the literal function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no filler. It is front-loaded with the action and resource, making it immediately understandable and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple list tool with two optional parameters and no output schema. The description is minimally adequate but lacks context about filtering by type, the coach-only athlete scope, and what fields are returned. Given low complexity, the gaps are notable but not severe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only the 'athlete' parameter has a description). The description doesn't explain the 'type' filter behavior or the 'athlete' targeting option, failing to compensate for the undocumented parameter. The parenthetical '(bikes, shoes)' hints at the type enum but does not explicitly connect it to the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List equipment (bikes, shoes)', providing a specific verb ('list') and resource ('equipment') with scope. It effectively distinguishes this from sibling CRUD tools like tp_create_equipment, tp_update_equipment, and tp_delete_equipment by focusing on the read/list operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. It doesn't mention that tp_create_equipment, tp_update_equipment, or tp_delete_equipment handle mutations, nor does it specify any prerequisites or context for listing equipment.

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

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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It only says 'List events' without explaining return format, pagination, sorting, visibility scope, or authentication requirements. The read-only nature is implied but not elaborated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, and the schema covers parameters, but with no output schema the description could usefully mention what is returned or whether the date range is inclusive. It is adequate for a basic list operation but leaves some contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already explains both required date parameters and the optional athlete parameter (including the coach-account note). The description adds no additional parameter-level meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List'), the resource ('events'), and the scope ('date range'), making it distinct from sibling tools like tp_get_next_event and tp_get_focus_event. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The date-range constraint implies a use case, but there is no explicit guidance on when to choose this tool over alternatives such as tp_get_next_event or tp_get_availability. No exclusions or alternative references are provided.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The verb 'Get' signals a read-only operation, and 'Supports historical date ranges' adds useful context. However, it does not explicitly disclose auth requirements, default behavior, or return format details beyond the metric acronyms, leaving some transparency gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise: two sentences that front-load the core purpose and add a key functional capability. Every word earns its place, with no redundant or extraneous phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with a fully described schema, the description is nearly complete. It names the return metrics (CTL/ATL/TSB) and explicitly supports historical ranges. While it omits details like default range or parameter interactions, the schema covers those, making the description sufficient 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides comprehensive descriptions for all four parameters (days, athlete, end_date, start_date), achieving 100% schema description coverage. The tool description adds no additional parameter semantics, but the baseline of 3 applies because the schema adequately covers parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's function with a specific verb ('Get') and a well-defined resource ('fitness/fatigue trend (CTL/ATL/TSB)'). The mention of CTL/ATL/TSB distinguishes it from sibling tools like tp_get_weekly_summary or tp_get_workout_prs, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for historical fitness/fatigue trends through 'Supports historical date ranges,' but it does not explicitly state when to use this tool instead of alternatives or provide exclusions. There is no direct comparison with sibling tools, so guidance is only implied.

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

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

No annotations are provided, so the description carries the burden. It implies a read-only operation via 'Get' but doesn't explicitly state safety, possible absence of the event, or authorization requirements beyond what the schema hints. This leaves behavioral uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that front-loads the action and resource without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with no output schema, the description gives the core purpose but omits return structure, edge-case behavior (e.g., no focus event found), and any context about 'A-priority' semantics. This is adequate but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'athlete' has a full schema description, covering 100% of parameters. The tool description adds no extra semantic value beyond the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' with the resource 'A-priority focus event', clearly distinguishing it from sibling tools like tp_get_next_event and tp_get_events. The qualifier 'with goals and results' adds specificity about content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as tp_get_next_event or tp_get_events. The description lacks any contextual cues or exclusions, leaving the agent to infer usage.

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

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

With no annotations, the description carries the full burden. It only states 'List workout library folders' without disclosing return format, pagination, or permission requirements beyond the athlete param note about coach accounts. The read-only nature is implied by 'list' but not explicitly stated, and no other behavioral traits are revealed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that immediately conveys the tool's action and resource. There is zero wasted text, and it is appropriately minimal for a simple list operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains the core function but lacks context about what the returned data looks like or how it fits with related tools like tp_get_library_items. Given no output schema, the agent might need to infer the response structure. However, for a straightforward list operation, it is minimally sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single optional 'athlete' parameter, and the schema already explains that it targets another athlete for coach accounts. The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List workout library folders.' uses a specific verb ('List') and a precise resource ('workout library folders'), which clearly distinguishes it from sibling tools like tp_get_library_items (which lists items within a folder) and tp_get_library_item (singular). The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives like tp_get_library_items. The athlete parameter hints at coach-account usage, but the description does not mention typical use cases or prerequisites. The purpose implies listing top-level folders, but no exclusions or alternative references are provided.

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

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

Annotations are absent, so the description carries the full burden. It does not disclose any behavioral traits beyond the obvious read-only nature implied by 'Get'. No mention of authentication, response format, side effects, or limitations. The phrase 'including structure' adds some detail but not enough for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no redundancy or filler. It is front-loaded with the key action and resource. However, it is somewhat under-specified, but that is a content issue, not a structure issue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is insufficient for the tool's complexity. There is no output schema, so the description should clarify what 'full details' and 'structure' mean, but it does not. It also omits the optional 'athlete' context and the relationship between the parameters. The tool is simple, but the schema is sparse, so the description needs to do more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only 'athlete' is described). The description does not compensate for the undocumented 'library_id' and 'item_id' parameters. It adds no meaning beyond what the schema already provides, so the agent has to guess the role of these parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a retrieval operation ('Get') for 'full template details', which corresponds to a library item. It distinguishes from list operations like tp_get_library_items by emphasizing 'full details' and 'structure', though it does not explicitly name any sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of conditions, prerequisites, or cases where another tool (e.g., tp_get_library_items) would be more appropriate. Usage is only implied by the tool name.

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

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

No annotations are present, so the description carries the burden. The verb 'List' implies a read-only operation, which is helpful, but there is no mention of authentication requirements, pagination, or response format. This is adequate for a simple read-only list but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the primary action. Every word earns its place, and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and a sparse description. It doesn't mention return values, ordering, filtering, or clarify the distinction between 'templates' and 'library items' from the tool name. This is incomplete for a tool with a required parameter and potential ambiguous sibling relationships.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal meaning beyond the schema. It implies 'workout library' relates to library_id, but doesn't explain the athlete parameter or any constraints. With 50% schema coverage, the description should compensate but doesn't.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('templates in a workout library'), making the primary action clear. It distinguishes from siblings like tp_get_library_item (singular) by implying plural results, but doesn't explicitly name the alternative or contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus similar siblings like tp_get_library_item or tp_get_libraries. The description only states what it does, not when it should be preferred.

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

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

There are no annotations, so the description carries the full burden. It only states 'Get health metrics' without disclosing whether it is read-only (implied but not stated), any authentication requirements, rate limits, or what happens when no data exists. The athlete parameter for coach accounts is only in the schema, not the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that directly states the action and scope. There is no filler or redundancy, making it appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description should provide more context about expected returns or behavioral nuances. It does not mention what 'health metrics' include, how they are returned, or any caveats. Given the presence of many sibling tools, this description is insufficiently complete for an agent to select it correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no additional meaning beyond the date-range scope. It does not explain the relationship between start_date, end_date, and the optional athlete parameter, but the schema already covers this.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description says 'Get health metrics for a date range', which uses a specific verb ('Get') and resource ('health metrics') with a date-range scope. However, it doesn't differentiate from sibling tools like tp_get_fitness or tp_get_weekly_summary, as 'health metrics' is vague and could overlap with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. No exclusions or alternative references are provided. The only hint is the date-range scope, but it doesn't clarify why one would choose this over tp_get_fitness or tp_get_weekly_summary.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get the nearest future planned event' and does not describe edge cases (e.g., no future events), return format, sorting behavior, or whether it is a read-only operation beyond the verb 'Get'. Significant behavioral details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no waste. It clearly conveys the tool's core purpose, though it could benefit from additional context without becoming overly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is too sparse. It does not explain what is returned, how it behaves when no event exists, how it differs from related tools like tp_get_events or tp_get_focus_event, or any special handling for coaches. The schema covers the parameter, but the overall tool context is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents the single optional 'athlete' parameter with a clear description, so the schema handles parameter semantics. The tool description adds no additional parameter information, but the baseline of 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets the nearest future planned event, using a specific verb and resource. It distinguishes from siblings like tp_get_events (which likely lists all events) and tp_get_focus_event, though it does not explicitly mention those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as tp_get_events or tp_get_focus_event. The description implies usage for retrieving the next upcoming event, but does not state exclusions, prerequisites, or contextual recommendations.

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

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

With no annotations, the description carries the behavioral disclosure burden. It states a read operation by ID, which is clear, but it does not disclose behaviors for missing IDs, permission requirements, or the exact return format. It is not misleading, but it is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero wasted words. It conveys the essential information efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get-by-ID tool, the description combined with the schema is largely sufficient. However, the absence of an output schema and lack of mention of the optional athlete scoping or error behavior leaves minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema thoroughly documents both parameters. The description only reinforces that note_id is the lookup key, adding no additional meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') with a clear resource ('calendar note') and lookup mechanism ('by ID'). It clearly distinguishes this from sibling tools like tp_get_workout_note and tp_list_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given about when to use this tool versus alternatives such as tp_list_notes or tp_get_workout_note. The intended use case is implied but no alternatives or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It simply states the action without mentioning ordering, filtering, auth requirements, or whether the athlete parameter affects results. As a read tool, it lacks context about what the agent should expect in terms of access or data shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and front-loaded: 'Get all comments on a calendar note.' It includes the verb, resource, and scope with no wasted words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with only two well-described parameters and no output schema. However, the description does not specify the return format, ordering, or potential pagination limits. It adequately conveys the basic function but leaves the agent without important details about the response structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100% for both parameters (note_id and athlete), including a clear explanation for athlete. The description itself adds no additional semantic value beyond what the schema already provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' and identifies the exact resource: 'all comments on a calendar note.' This cleanly distinguishes it from sibling tools like tp_get_workout_comments (comments on workouts) and tp_add_note_comment (adding comments).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving comments on calendar notes, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or conditions, such as coach-only access for the athlete parameter (though that is in the schema). It provides clear context but no comparative guidance.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure, but it only states the action. It does not mention return format, authentication needs, how the optional athlete parameter behaves for coaches, or any limitations. This is a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no filler. It efficiently communicates the core action and scope, earning a top score for conciseness and structure even though it lacks detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, this description is too minimal. It does not clarify what 'nutrition data' includes, how results are returned, or special considerations like athlete access for coach accounts. An AI agent would have difficulty predicting the tool's full behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: all three parameters have descriptions in the schema, including date formats and the athlete parameter's coach-only note. The tool description adds no extra semantic value beyond the schema, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' with the resource 'nutrition data' and a scope ('date range'), making the primary function clear. It is distinguishable from the sibling tp_update_nutrition by verb, though it does not explicitly name alternatives or describe the nature of the nutrition data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided on when to use this tool versus alternatives such as tp_update_nutrition. The name implies a read operation, but there are no stated prerequisites, exclusions, or use-case instructions, leaving usage to be inferred.

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

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

No annotations are provided, so the description carries the burden. 'Get' implies a read-only operation, and the description adds no hidden side effects, but it does not disclose return format, auth requirements, or scope behavior beyond what the schema suggests. This is adequate for a simple read tool but not richly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and resource, with no wasted words. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema or annotations, and the description does not specify the return structure or the interaction between days, sport, pr_type, and athlete. It is sufficient for basic invocation because required params are in the schema, but it leaves ambiguity about the exact output and filtering behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, with no descriptions for 'sport' or 'days'. The description's 'by type' loosely maps to pr_type but adds no value beyond the existing schema description for pr_type and does not compensate for the undocumented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets top performances by type, and the phrase 'For comparing PRs over time' adds a specific use case. It is distinct from siblings like tp_get_workout_prs by focusing on type-based peak values, though it does not explicitly name an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'For comparing PRs over time' offers a clear context for when to use this tool. It does not list exclusions or explicitly mention alternatives, but the intended use case is evident enough for an agent to decide.

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

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

With no annotations, the description carries the burden of disclosing behavior, but it only says 'Get pool length settings.' It does not mention authentication requirements, read-only guarantees, response structure, or any side effects. The read-only nature is only implied by the verb 'get.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words. It is front-loaded and appropriately sized for a simple getter, though under-specified in content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool lacks an output schema, so the description should explain what is returned. It does not describe the returned settings, any prerequisites, or behavioral context. While the parameter is well-documented, the overall information is insufficient for an agent to fully understand the tool's output and usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the single optional parameter (100% coverage) with a clear description of the 'athlete' field. The tool description adds no parameter-specific meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a 'get' operation on 'pool length settings,' with a specific verb and resource. This distinguishes it from sibling tools like tp_get_athlete_settings, though the nature of the settings is not elaborated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The parameter description mentions coach accounts, but the overall description lacks any context about appropriate usage or exclusions.

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

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

With no annotations, the description must disclose behavioral traits, but it only says 'Get athlete profile'. It does not mention that the operation is read-only, whether authentication is required, what data the profile includes, or any potential side effects. The usage note is not a behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two short sentences that convey the purpose and usage. Every word earns its place, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain what 'profile' contains or what the return value looks like. It does not. The usage note is helpful but does not compensate for the lack of details about the profile content or operation behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for the 'athlete' parameter, including that it is for coach accounts and defaults to the user's own profile. The description adds no further 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get athlete profile' with a specific verb and resource. It further distinguishes itself from sibling tools by noting it is 'Rarely needed' and that other tools work without it, providing helpful differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Rarely needed - other tools work without it' offers explicit context on when to use this tool, implying that alternatives should be preferred unless the profile is specifically required. It lacks named alternatives but gives a clear 'when not to use' indication.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output metrics and end-of-week calculation, but does not mention side effects, permissions, or edge cases (e.g., weeks without data). The name 'get' implies read-only, but this is not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences front-load the purpose and key outputs. There is no redundant or wasted text; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only summary tool, the description covers the core output and the scope (a week). It does not explicitly state the aggregation semantics (e.g., all workouts in the week), but the context is largely complete given the simple schema. A perfect score would require more explicit behavior statements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with both parameters clearly described. The description does not add any additional meaning beyond the schema, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: a combined view of workouts and fitness for a week, including specific metrics (TSS, duration, CTL/ATL/TSB). This distinguishes it from sibling tools like tp_get_workouts or tp_get_fitness by emphasizing the combined summary nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a weekly aggregate of both workouts and fitness is needed, but it does not explicitly state when to use this tool versus alternatives. No exclusion criteria or alternative tool names are given.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states 'Get workout details by ID' and adds no information about permissions, error behavior, return contents, or side effects. For a read operation, this is sparse but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exactly two sentences, front-loaded with the core purpose and a useful sequence clue. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and an output schema, the description leaves 'details' unspecified and does not explain what the response contains. However, for a simple get-by-ID tool with clear parameters, it is minimally viable but lacks richness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage for both parameters, with descriptions for 'athlete' and 'workout_id.' The tool description adds no extra parameter semantics beyond saying to use it after listing workouts, which weakly implies where workout_id comes from.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Get workout details by ID.' It clearly distinguishes from the sibling list tool 'tp_get_workouts' by emphasizing the ID parameter and even suggests a sequence, reinforcing the detail-vs-list distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use after tp_get_workouts' gives explicit contextual guidance on when this tool is appropriate. However, it does not mention when not to use it or explicitly name alternative tools for related purposes.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. The description only says 'Get comments on a workout' and does not mention authentication needs, response format, pagination, or the distinction between athlete and coach access, leaving important operational details undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no redundancy or filler. It is concise and front-loaded, with every word earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, no output schema, and moderate parameter coverage, this description is minimal and incomplete. It does not mention the optional 'athlete' parameter for coach accounts, when to use it, or any behavioral constraints, making it inadequate for reliable tool selection in a broader operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover only 50% of parameters, and the tool description adds no parameter information. It does not explain the purpose of 'workout_id' or clarify the optional 'athlete' parameter beyond what the schema already provides, failing to compensate for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves comments for a workout, using a specific verb ('Get') and resource ('comments on a workout'). It distinguishes from siblings like 'tp_add_workout_comment' and 'tp_get_workout_note', though it could be more explicit about the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as 'tp_get_workout_note' or 'tp_get_note_comments'. The description lacks any context about selection criteria, exclusions, or prerequisites like coach/athlete considerations.

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

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

With no annotations, the description carries the full burden. It indicates a read operation ('Get') and the 'private' nature of the note, but does not disclose authentication requirements, behavior when no note exists, or any limitations beyond what the schema hints at.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is brief and front-loaded, but it is under-specified for a tool with two parameters and no output schema. Conciseness is present, but it sacrifices necessary context, making it minimally acceptable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations, no output schema, and the existence of similar siblings (tp_get_note, tp_get_workout), the description is incomplete. It does not explain what a 'workout note' is, how it differs from comments or general notes, or what the response looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (athlete is well described, workout_id is not). The description adds no parameter-specific meaning, failing to clarify the required workout_id or note format. It does not compensate for the half of the schema lacking descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' with a specific resource 'private workout note' and scope 'for a workout.' This distinguishes it from sibling tools like tp_set_workout_note and tp_get_workout_comments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives such as tp_get_workout or tp_get_note. It does not mention exclusions or the optional athlete parameter for coach accounts, leaving usage context entirely implied.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It fails to mention read-only nature, auth requirements, what constitutes a PR, or the response format, leaving key behaviors undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words. It is concise and easy to read, though its brevity sacrifices important context that would be beneficial.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and an undocumented required parameter, the description is insufficient for an agent to fully understand the tool's capabilities and invocation requirements. The concept of 'PRs' is left open to interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes the athlete parameter but not workout_id. The tool description says 'during a specific workout,' which weakly hints at workout_id's role, but it doesn't clarify how to supply or interpret either parameter. With only 50% schema coverage, the description should compensate but does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and names the resource 'PRs' scoped to 'a specific workout,' which clearly states the core function. However, it does not differentiate this tool from sibling tp_get_peaks, which could be similar in nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states what it does without context on the appropriate use case.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It adds the key constraint of a 90-day maximum and encourages minimal date ranges, but it does not mention what happens when the range exceeds the limit, pagination, or ordering. More detail could be added for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences deliver the purpose and key usage constraint without any waste. The description is front-loaded and every statement earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with a fully documented schema, the description is adequate: it specifies the date-range scope and the 90-day limit. It does not describe return format, but the meaning of 'list workouts' is clear, and the schema covers parameter specifics. Slightly more detail on error handling or response structure could push it to 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description aligns with the start_date and end_date parameters by mentioning date range, and 'Query only days needed' reinforces their intended use, but it does not add significant new meaning beyond the schema's own parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists workouts within a date range, which is a specific verb+resource+scope. It distinguishes itself from sibling tools like tp_get_workout (single workout) and other workout analytics tools by focusing on listing within a range.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance on when to use the tool: list workouts in a date range, and explicitly advises to query only needed days and warns about the 90-day limit. It does not name alternatives but the context is sufficient.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It implies a read-only list operation, but it does not provide additional behavioral context (e.g., whether the list is exhaustive, if there are any quirks like inactive types). For a simple lookup tool, this is 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the primary action. Every word earns its place, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is low complexity: no parameters, no output schema, and clear intent. The description fully covers what the tool does and why to use it, making it complete 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline of 4 applies. The description adds no parameter-level details, but none are needed since the schema is empty and the operation is a simple list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all sport types and subtypes with IDs. It uses a specific verb ('List') and resource, and distinguishes itself from sibling tools by being the lookup tool for type/subtype IDs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states a key use case: 'Use to find subtype_id for create/update.' This gives clear context for when to use the tool, though it does not mention alternatives or when not to use it, so it stops 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.

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

With no annotations, the description must disclose behavioral traits. It mentions account scope and coach accounts, but does not explicitly state this is a read-only operation, describe the return format, or mention any permissions needed. It is not misleading but is sparse for a tool with zero annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys the essential information without any filler. It is perfectly sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool with no parameters, no output schema, and no annotations, the description is nearly complete. It could be improved by hinting at the return structure (e.g., athlete objects), but it adequately covers the core functionality and intended audience.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so the schema coverage is trivially 100%. The description adds no parameter details because none exist, but this is acceptable. The baseline score for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'athletes', and specifies the scope 'available to this account (coach accounts)'. This distinguishes it from sibling tools like tp_get_athlete_settings, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'coach accounts' provides context on the intended user, and since no sibling tool lists athletes, the usage context is clear. It lacks explicit exclusions or alternative tool references, but given the unique functionality, it is adequate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and date range, without mentioning that it is a read-only operation (though 'list' implies it), that results may be paginated, or that the athlete parameter is available for coach accounts. The description adds minimal behavioral context beyond the tool's basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence: 'List calendar notes for a date range.' It is front-loaded with the verb and resource, contains zero fluff, and conveys the essential information in six words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters and no output schema or annotations, yet the description provides only the basic action and date range. It does not explain return format, pagination, authorization requirements, or the optional athlete filter. The description is too sparse to be considered complete for a tool with these complexity signals.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents start_date, end_date, and athlete. The description mentions the date range but does not add any new parameter semantics beyond that. Baseline 3 is appropriate because the schema does the heavy lifting and the description adds marginal value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists calendar notes for a date range, with a specific verb ('list') and resource ('calendar notes'). It distinguishes itself from sibling tools like tp_get_note (which fetches a single note) and tp_get_events (which lists events, not notes). The date range scope is explicit and additional to the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention that this is for retrieving notes over a range as opposed to a specific note, nor any exclusions or prerequisites. The schema mentions the optional athlete parameter for coach accounts, but the description itself offers no usage context.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only implies a write operation but doesn't state whether logging overwrites existing entries for a date, whether it's idempotent, or what authentication requirements exist. This is a significant 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that avoids redundancy. It earns its space by naming the resource and examples, but its brevity contributes to the lack of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters and no annotations or output schema, the description is under-specified. It doesn't explain return values, duplicate-date behavior, or required conditions (e.g., coach accounts for athlete). The minimal description is insufficient for safe invocation in all contexts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low (30%): only date, injury, and athlete have descriptions. The description adds a high-level list of metric types but doesn't clarify units (e.g., hrv, spo2), range for injury (though schema says 1-10), or whether metrics are additive/overwriting. The athlete parameter's coach-only behavior is only in the schema, not the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (log) and the resource (health metrics for a date), with examples. It distinguishes from sibling tools like tp_get_metrics, which retrieves metrics. The verb 'log' is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool vs alternatives, such as tp_get_metrics for reading or tp_update_nutrition for nutrition. There are no exclusions, prerequisites, or context signals about the intended workflow.

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

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

No annotations are provided, so the description carries the full burden. It indicates the operation merges completed data into the planned workout, implying a mutation, but does not state whether the operation is reversible, requires special permissions, or what happens to the completed workout record. This is a significant 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no unnecessary words or repetition. It is front-loaded and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple pairing operation with two required IDs, the description conveys the core purpose. However, it lacks details about side effects, reversibility, and return format, and with no output schema or annotations, the agent may not know what to expect after invocation. It is minimally complete but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for all three parameters, so the schema already explains the parameters thoroughly. The description adds no per-parameter detail beyond the overall purpose, which is acceptable given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: pairing a completed workout with a planned workout and attaching the completed data. It uses a specific verb and resource, and the phrase 'merging them into one' distinguishes it from related tools like tp_unpair_workout.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case (when you have a completed and planned workout to link) but provides no explicit guidance on when to use this tool vs. alternatives or any prerequisites. Sibling tools like tp_unpair_workout exist, but no comparative direction is given.

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

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

No annotations are provided, so the description carries full burden. It implies a mutating operation ('refresh') but does not disclose side effects such as overwriting existing auth, whether the browser must be open, or what happens on failure. Accessing the user's browser cookies is a sensitive operation, and the description lacks essential safety details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action, and no unnecessary words. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one param, no output schema). The description covers purpose and when to use it, but lacks details on success/failure behavior, prerequisites (e.g., browser must be logged in), and what the refreshed auth enables. Some gaps remain for a security-sensitive action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: the single 'browser' parameter is fully described with an enum and default value. The description adds no extra parameter-level information beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it refreshes auth by extracting a cookie from the user's browser, giving a specific verb and resource. This distinguishes it from sibling tools like tp_auth_status, which likely checks auth status rather than modifying it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use when other tools return auth errors,' providing a clear trigger condition. However, it does not name alternatives or exclusion cases, 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.

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

With no annotations, the description must disclose behavioral traits. It only says 'reorder', indicating a mutation, but doesn't mention reversibility, required permissions, or behavior with invalid IDs. Minimal disclosure for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool, the description is incomplete: it doesn't explain how the 'day' is determined, prerequisites, or how this tool relates to sibling workout tools. The ambiguity around 'given day' leaves a gap in understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing descriptions for both athlete and workout_ids. The description adds no significant parameter nuance beyond the ambiguous 'given day', which isn't a parameter. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (reorder) and resource (workouts) with a scope ('on a given day'). It distinguishes itself from sibling tools like tp_create_workout or tp_delete_workout by specifying a reorder operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for reordering workouts, but gives no explicit guidance on when to use it versus alternatives, nor prerequisites (e.g., all workouts must belong to the same day). The 'given day' context is vague and not represented in the schema.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'schedule' without clarifying that this is a write operation, what side effects it has (e.g., overwriting existing calendar entries), or any permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words, but it is under-specified for a four-parameter operation. It serves as a minimal purpose statement but lacks the structure needed for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and output schema, this terse description does not inform the agent about expected return values, error conditions, or the effect on existing data. The tool is incompletely specified for reliable autonomous use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no information about the parameters. With schema coverage at only 50% (date and athlete described, item_id and library_id not), the phrase 'library template' only weakly hints that item_id is the template, leaving library_id undefined. This does not compensate for the gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Schedule' and identifies both the resource ('library template') and destination ('calendar date'), making the core action unambiguous. It also differentiates this tool from siblings like tp_get_library_items or tp_create_workout, none of which offer scheduling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites such as having a library and item already created. The description simply states what it does without context on appropriate invocation.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states 'Set or update' without explaining overwrite behavior, permission requirements, or failure modes. The 'private' qualifier adds some context, but not enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no redundant information. It is front-loaded and immediately conveys the tool's essence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple write tool with no output schema, the description provides a minimal but sufficient scope. However, given no annotations and a lack of behavioral details (e.g., clearing via empty string is only in the schema), the description feels incomplete for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%, with 'note' and 'athlete' documented in the schema. The description itself does not add parameter detail beyond the schema, but the schema already explains the note contents and the athlete context. Workout_id remains unexplained in both, but the description implies its role.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set or update') and the resource ('private workout note for a workout'). It distinguishes from siblings like tp_get_workout_note (read) and other note-related tools by specifying 'workout note'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for setting/updating a workout's private note, but it does not provide explicit exclusions or alternatives. No guidance on when to use this vs. tp_update_workout or other note tools.

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

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

With no annotations, the description carries the full safety burden and does disclose an important trait: 'No data is lost' and it creates two separate workouts. It does not mention whether the operation is reversible, required permissions, or failure behavior, but it provides a reasonable safety signal for a mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the action ('Unpair a workout'), and every clause adds relevant information. There is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two well-described params and no output schema, the description covers the purpose and a key behavioral guarantee. It could be more complete by stating the prerequisite that the workout must already be paired, but overall it is adequate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides descriptions for both parameters (athlete and workout_id) at 100% coverage, so the schema does the heavy lifting. The description adds only the context that the workout must be 'the paired workout,' which is helpful but not a substantive expansion of parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Unpair') and resource ('workout'), then clarifies the exact effect: detaching the completed workout file from the planned workout to create two separate workouts. This clearly distinguishes it from sibling tools like tp_pair_workout and other workout mutation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is used to reverse a pairing, and the existence of tp_pair_workout as a sibling gives context. However, there is no explicit statement about when to use it versus alternatives, prerequisites (e.g., the workout must be paired), 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.

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

No annotations are provided, and the description does not disclose any behavioral traits beyond the generic 'update'. It does not mention authorization requirements, mutability of fields, idempotency, or what happens to omitted fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loaded, but it is under-specified. It does not provide enough information to be useful; this is closer to a tautological placeholder than a genuinely concise, informative description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain return values, side effects, field constraints, or any operational context needed to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 9% (only 'athlete' has a description), and the description adds no parameter-level meaning. The tool has 11 parameters, and the description does not explain any of them, so it 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update equipment details' uses a clear verb and resource, and distinguishes from sibling tools like tp_create_equipment and tp_delete_equipment. However, it lacks specifics about which details can be updated, making it clear but not fully specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., existing equipment), and no exclusions. The description simply states the action without context.

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