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

The description discloses that null values are treated as omitted (not clearing individual fields) and that a 409 is returned on duplicate date. These are important behavioral traits beyond the annotations (all false). No contradictions with annotations.

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

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

The description is three sentences, front-loading the main action. Every sentence provides necessary information without waste: creation, null handling, and conflict guidance.

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 18 parameters and no output schema, the description covers the essential aspects: unique constraint, optional fields, null handling, and alternative tool for updates. Minor gap: no mention of the success response (e.g., what is returned).

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?

With 100% schema description coverage, the baseline is 3. The description adds the context that all measurement fields are optional and that nulls are omitted, which is not explicitly stated in the schema descriptions for individual parameters. This adds value 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 ('Create'), the resource ('body measurement entry'), and the key constraint ('for a given date'). It also distinguishes from the sibling tool 'update-body-measurement' by mentioning the 409 conflict and suggesting its use instead.

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 tells the agent to use 'update-body-measurement' if an entry already exists (returns 409), which provides clear guidance on when not to use this tool. However, it does not elaborate on other usage scenarios or prerequisites.

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 indicate the tool is not read-only and not destructive, which is consistent with a create operation. However, the description adds no additional behavioral context beyond what annotations already convey. No hidden behaviors are disclosed.

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 efficient sentence with no waste. It could be slightly expanded to add value, but it is well-structured and 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?

Given the tool has 5 parameters (4 required) with enumerations and no output schema, the description is insufficient. It does not explain return value, error handling, or any constraints like uniqueness or required permissions. The completeness is inadequate for the 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?

Schema description coverage is 0%, so the description must compensate. It names four of the five parameters (title, type, equipment, muscle groups) but omits the optional 'otherMuscles' and provides no additional meaning or constraints beyond the parameter names. This is minimal 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 verb 'create' and resource 'exercise template', and lists the key fields (title, type, equipment, muscle groups). This distinguishes it from sibling tools like search-exercise-templates or other create 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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The context of creating an exercise template is implied by the name, but no explicit when-to-use or when-not-to-use information 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?

Annotations already indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that it 'Returns the full routine details including the new routine ID,' which is useful but doesn't disclose other behavioral traits like authentication needs 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 two sentences, front-loaded with the main action, and contains no wasted words. Every sentence adds value.

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 4 parameters, one required, and nested objects, the description covers the essential requirements and return value. However, it omits the notes parameter and could elaborate on folder behavior. Still, sufficient for an agent to understand the tool's role.

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 0%, so the description must compensate. It mentions the title is required, exercises need sets, and folder is optional, but doesn't detail the structure of exercises or other parameters like notes. This provides basic understanding but not thorough explanation.

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 'Create a new workout routine in your Hevy account.' It uses a specific verb ('Create') and resource ('workout routine'), and distinguishes from sibling tools like create-exercise-template or create-workout by specifying 'workout routine'.

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 requirements: 'Requires a title and at least one exercise with sets. Optionally assign to a folder.' This gives clear context for when to use the tool, but doesn't mention when not to use or list alternative 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?

The description confirms the tool creates a new resource and returns the full folder details, including the new ID. Annotations indicate it is not read-only and not destructive, which is consistent. The description adds value by stating the return expectation, though it does not cover potential side effects like duplicate handling or rate limits.

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, consisting of two sentences (25 words) that are front-loaded with the purpose. Every sentence adds essential information: what it does, the required input, and the output. There is no redundancy or extraneous 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?

Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description covers the core aspects: action, input, and expected return. It lacks details about error conditions or uniqueness constraints, but these are not essential for basic usage. The description is adequate for an agent to use 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 input schema has a single required parameter 'name' with 0% description coverage. The description explains that the name is for the folder and is required, thus adding meaning beyond the schema. While it does not elaborate on constraints (e.g., uniqueness), it provides sufficient context for the agent to understand the parameter's 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 tool's purpose: creating a new routine folder in the Hevy account. It specifies the action ('create'), the resource ('routine folder'), and the scope ('your Hevy account'). This distinguishes it from sibling tools like 'create-routine' or 'create-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 explains that the tool is used when you need to create a routine folder, but it does not provide guidance on when not to use it or alternatives. It lacks explicit context about prerequisites or scenarios where other tools (e.g., 'update-routine' or 'get-routine-folders') would 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?

Description adds value beyond annotations by specifying that creation requires valid data and returns the newly assigned ID. Annotations already indicate readOnlyHint=false and destructiveHint=false, so no contradiction. However, it does not mention auth needs or rate limits, which would elevate transparency further.

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 purpose, then requirements, then output. No redundant words. Efficient and clear.

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 output schema, description appropriately states return value. Input complexity is high (nested arrays), but description covers core requirements. Missing details on description and isPrivate parameters, but overall adequate for a creation 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 0%, so description must compensate. It mentions title, start/end times, and that exercises must have sets, covering 4 of 6 parameters (title, startTime, endTime, exercises). Missing description and isPrivate. This adds some meaning but is incomplete.

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?

Description clearly states the action 'Create a new workout', specifies the resource ('workout in your Hevy account'), and outlines requirements (title, times, exercises) and return value (workout details with ID). This distinguishes it from siblings like get-workout or update-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?

Description implies when to use (to create a workout) but does not explicitly state when not to use it or provide comparisons to siblings like create-routine or update-workout. No exclusions or alternatives mentioned, so guidance is limited.

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 already provide readOnlyHint=true, and the description adds that it returns all measurement fields for the specified date. This adds useful context beyond the annotations.

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

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

Two sentences that are front-loaded and concise. Every sentence serves a purpose with no waste.

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's simplicity, one parameter, and presence of an output schema, the description covers the core behavior. No additional information 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 coverage is 100%, with the date parameter fully described. The description confirms 'by date' but does not add significant new meaning beyond the schema.

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

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

The description states the tool gets a single body measurement by date, using a specific verb and resource. It distinguishes from the sibling 'get-body-measurements' by explicitly saying 'single'.

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 (when you need a measurement for a specific date) but does not explicitly mention alternatives or when not to use. The context is clear enough for a simple tool.

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 already declare readOnlyHint=true, so the description's mention of pagination adds useful context beyond the safety profile. However, it does not disclose other behavioral details like default ordering or response limits.

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-load the action and resource, with no wasted words. It effectively communicates the core functionality.

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?

While an output schema exists, the description does not cover parameter semantics, which are essential for correct tool usage. The lack of parameter information makes the tool underspecified for an agent.

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 mentions pagination qualitatively but fails to explain the two parameters ('page' and 'pageSize') or their constraints (e.g., max pageSize=10). With 0% schema description coverage, this is a critical gap.

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 a paginated list of body measurements for the authenticated user, specifying included metrics (weight, body fat, circumference). This distinguishes it from siblings like 'get-body-measurement' (singular) and mutation tools like 'create-body-measurement'.

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 use for listing measurements but provides no explicit guidance on when to use this versus alternative listing tools (e.g., no comparison to search tools). No when-not-to conditions or prerequisites 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?

The description does not reveal behavioral details beyond what annotations provide. The readOnlyHint=true annotation already indicates a safe read operation, so the description adds no extra context about pagination, ordering, authentication, or potential limits.

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 of 13 words, front-loading the core purpose. Every word is necessary, with 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?

Given the presence of an output schema (not shown), the description need not detail return values. For a simple query tool with a required parameter and two optional filters, the description is sufficiently complete. Minor improvement would be mentioning ordering or default range.

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% (startDate and endDate have descriptions, exerciseTemplateId has none). The description's phrase 'specific exercise template' implies exerciseTemplateId's role, but does not detail its format or source. Overall, marginal added value over 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 verb 'Get' and the resource 'past sets for a specific exercise template', with optional date filtering. It distinguishes from sibling tools like 'get-exercise-template' which retrieves template metadata, and 'get-workout' which retrieves workout details, not set history.

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 on when to use this tool versus alternatives, such as when to fetch sets from a workout versus historical data. No exclusions or prerequisites mentioned, leaving the agent to infer usage from sibling tool names.

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 already declare readOnlyHint=true. Description adds that it returns 'complete details' with specific fields. No contradictions. Additional behavioral context like error handling or ID format not provided, but acceptable given 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?

Single sentence, front-loaded with purpose, lists included fields concisely. 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?

For a simple get-by-ID tool with output schema present, description covers purpose and returned fields. Lacks details like error behavior or ID format, but these are secondary.

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 0% description coverage for the single parameter exerciseTemplateId. Description does not explain its meaning beyond the name and the fact it's an ID. No format, example, or additional context.

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?

Description states verb 'get', resource 'exercise template', scope 'by its ID', and lists specific fields returned (name, category, equipment, muscle groups, notes). Clearly distinguishes from siblings like get-exercise-templates (list) and search-exercise-templates.

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?

Implicitly clear: use when you have an ID and need full details. No explicit when-not-to-use or alternatives, but context from siblings and name makes it obvious.

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 readOnlyHint annotation is already present, and the description adds context about pagination but does not elaborate on behavioral details like authorization or rate limits. Given annotations cover the safety profile, the description provides adequate but not exceptional 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?

The description is concise with two sentences, front-loading the main action. It efficiently conveys the tool's purpose without unnecessary verbiage.

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 basic purpose and result, but lacks details on pagination behavior or error handling. Since an output schema exists, return values are documented elsewhere, yet some operational context is missing.

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?

With 0% schema description coverage, the description must compensate but only mentions 'paginated list' without explaining page and pageSize parameters. It does not add meaning beyond the schema, leaving agents to infer parameter semantics from names alone.

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

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

The description clearly states the tool retrieves a paginated list of exercise templates, specifying types (default/custom) and example details. It distinguishes itself from sibling tools like get-exercise-template (singular) and search-exercise-templates by focusing on browsing a list.

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 indicates it's useful for browsing or searching, providing clear usage context. However, it does not explicitly mention when not to use it or compare with search-exercise-templates, lacking full guidance on alternatives.

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 already declare readOnlyHint=true, so the description's mention of 'Returns all details' adds some context. However, it does not disclose any additional behavioral traits such as authentication requirements or response structure beyond the output 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?

Two concise sentences with no wasted words. The purpose is front-loaded, making it easy to scan.

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 with one parameter and an output schema, the description is largely complete. It could mention that the output schema documents the returned details, but this is not necessary given the 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 0%, and the description only refers to 'by its ID' without elaborating on the routineId parameter's format, example values, or source. This provides minimal value beyond the schema's type and minLength.

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' and the resource 'routine by its ID', and specifies that it returns all details. This accurately distinguishes it from sibling tools like 'get-routines' (plural) and 'get-routine-folder'.

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 specific routine ID is known, but does not explicitly mention when not to use it or suggest alternatives like 'get-routines' for listing. The context is clear but lacks 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?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the returned data (name, creation date, associated routines), going beyond annotations. No behavioral contradictions.

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

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

The description is a single, well-structured sentence that immediately states the tool's purpose. It is concise with no redundant words or unnecessary details.

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's simplicity (one parameter, no nested objects) and the presence of an output schema, the description is fairly complete. It mentions key return fields, though it could elaborate on the structure of 'associated routines'.

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 has one parameter (folderId) with 0% documentation. The description only says 'by its ID', adding minimal meaning. It fails to explain parameter constraints (e.g., expected format, example values) or how it relates to folder ID 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 clearly states it retrieves complete details of a specific routine folder by ID, listing included fields (name, creation date, associated routines). This distinguishes it from sibling tools like 'get-routine-folders' (which lists all folders) and 'get-routine' (which retrieves a routine).

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 you have a folder ID and need details, but it does not explicitly state when to use this tool versus alternatives, nor does it provide conditions or exclusions. No mention of prerequisites or when not to use.

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 already declare readOnlyHint=true, so the read-only behavior is covered. The description adds pagination context but does not disclose other traits like rate limits or response format beyond what the output schema provides.

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 consists of two concise sentences, front-loading the primary function and adding a brief usage note with no redundant or 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?

With an output schema present, the description adequately covers the tool's purpose. It mentions default and custom folders and pagination, but lacks details on parameter usage and edge cases like empty results, which would improve completeness.

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 0%, yet the description does not explain the 'page' and 'pageSize' parameters, leaving their purpose and behavior undocumented. Common pagination parameters may be inferred, but the description should add value here.

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 a paginated list') and resource ('your routine folders'), and distinguishes from siblings like 'get-routine-folder' (singular) and 'create-routine-folder' by specifying it returns both default and custom folders.

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 organizing and browsing routines but does not explicitly state when to use this tool versus alternatives like 'get-routine-folder' or provide exclusions. No when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that the list is paginated and includes custom and default routines, which is useful context. However, it does not disclose pagination details (e.g., page numbering, sorting) or authentication requirements. Given the annotations, the description adds moderate value but could say more about 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 sentences: the first states the function, the second adds a use case. Every word is necessary; no repetition or fluff. It is appropriately sized and front-loaded with 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?

Given the tool's simplicity (two optional parameters, output schema exists, annotations present), the description covers the main purpose and usage context. It mentions that custom and default routines are included. While it could mention sorting or folder context, the output schema likely provides return value details, so completeness is high but not maximal.

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 0%, but the description does not explain the parameters 'page' and 'pageSize' at all. It only mentions 'paginated list' without linking to the parameters. The description fails to compensate for the lack of schema descriptions, leaving the agent to infer parameter usage from the schema defaults and constraints alone.

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

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

The description clearly states 'Get a paginated list of your workout routines, including custom and default routines.' It uses a specific verb ('Get'), resource ('routines'), and scope ('paginated list, including custom and default'). It distinguishes itself from siblings like 'get-routine' (singular) and 'get-routine-folders' by focusing on listing all routines.

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 says 'Useful for browsing or searching your available routines,' which provides a clear use case. While it does not explicitly state when not to use it (e.g., for a specific routine, use get-routine), the context is clear and the sibling tools imply alternatives. No exclusions are given, but the guidance 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?

Annotations already set readOnlyHint=true. The description reinforces this by describing a read operation and adds context about returned fields and purpose. No additional behavioral traits needed; no contradictions.

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

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

Two sentences with no wasted words. The first sentence states the core action and outputs; the second provides a concrete use case. Well-structured and 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?

Given the simplicity of the tool (zero parameters, output schema exists), the description covers everything needed: purpose, output fields, and use case. It is complete and leaves no 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?

No parameters exist, and schema coverage is 100%. The description does not need to add parameter details; it correctly focuses on the output. Baseline score of 4 for zero-parameter tools 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 the authenticated user's account info' and lists specific fields (user ID, display name, public profile URL). It is unambiguous and distinct from sibling tools, which are all about body measurements, exercises, routines, and workouts.

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 a clear use case: 'Useful for verifying which account the API key belongs to.' While it does not explicitly mention when not to use or alternatives, the context makes it obvious as there are no sibling tools for user info.

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 already provide readOnlyHint=true, so description adds limited behavioral context beyond stating what data is returned. No mention of error handling, auth, or other constraints, but with annotations this is acceptable.

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 core action, no fluff. Efficiently states purpose and return contents.

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 single-parameter tool with an output schema, the description covers the main return fields. Could mention error behavior (e.g., 404 if ID not found) but overall adequate given low 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?

Schema coverage is 0%, yet description only says 'by ID' without explaining format, source, or constraints for workoutId. The parameter name is somewhat self-explanatory but description should compensate more.

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 resource 'workout', specifying retrieval by ID. It clearly distinguishes from siblings like 'get-workouts' (plural) which lists workouts, not a single one.

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?

Implies usage when needing full details of a specific workout, but lacks explicit when-not-to-use or mention of alternatives like 'get-workouts' or 'get-workout-count'.

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 already declare readOnlyHint=true, making the safe read nature clear. The description adds that it returns a count, but no further behavioral context (e.g., response format, pagination details) beyond what annotations provide.

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

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

A single sentence that perfectly conveys the purpose and use cases with zero waste. Front-loaded 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?

Given no parameters, an output schema existing, and annotations covering safety, the description is fully complete for an agent. It adds the needed context for pagination/statistics use cases.

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?

No parameters exist, so baseline is 4. The description doesn't add parameter info (unnecessary) and remains clear about the tool's function.

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 it returns the total number of workouts on the account, distinguishing from sibling tools like get-workouts (list) and get-workout (single). The verb 'get' and noun 'total number of workouts' specify exactly what the tool does.

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

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

Explicitly mentions usefulness for pagination or statistics, providing clear context for when to use. Does not explicitly exclude other scenarios or compare to siblings, but the guidance is helpful enough.

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 provide readOnlyHint=true, and the description confirms it is a read operation. The description adds ordering (newest to oldest) and paging behavior, which is valuable beyond the annotation.

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

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

The description is concise with three sentences. The first sentence states the core function, the second adds ordering, and the third explains the intent. No 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?

Given the existence of an output schema and the context of sibling tools, the description adequately explains the tool's purpose and behavior for cache synchronization. It could include more parameter details but is complete for the intended 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?

Schema description coverage is 0%, and the description does not detail individual parameters. It implicitly references 'since' and paging but lacks specifics on defaults, formats, or constraints that would help the agent.

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 a paged list of workout events (updates or deletes) since a given date, ordered newest to oldest. It differentiates from siblings like get-workout and get-workouts by focusing on incremental cache updates.

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 the intended use case: allow clients to keep their local cache up to date without fetching entire list. It does not explicitly exclude other uses, but the guidance is clear and contextually 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?

Annotations already indicate readOnlyHint=true (safe read). The description adds context about pagination behavior and ordering (newest first), which goes beyond annotations and helps the agent understand the tool's behavior. However, it does not mention potential edge cases like empty lists or error handling.

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 main purpose. No wasted words, but could be slightly more concise by merging the second and third parts. Overall well-structured.

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 presence of an output schema (which describes return values), the description provides sufficient context about what the workout details include (title, description, times, exercises). It does not mention pagination metadata, but the output schema likely covers that. Missing any mention of scope (e.g., all user's workouts) is a minor gap.

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 0% (no parameter descriptions in schema). The description only says 'paginated list', implying page and pageSize parameters, but does not explain their constraints (e.g., page is a positive integer, pageSize max 10). The agent must infer from schema defaults and constraints, which is insufficient for a 0% 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 it returns a paginated list of workouts with ordering from newest to oldest. This distinguishes it from sibling tools like 'get-workout' (single workout) and 'get-workout-count' (count only). The verb 'Get' and resource 'list of workouts' are specific and clear.

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 this tool vs alternatives (e.g., get-workout for a single workout, get-workout-count for counts). The context is implied by tool names, but the description does not explicitly state usage boundaries.

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 caching behavior: first call fetches all templates, caches with bounded TTL, and reuse. It also explains the refresh parameter. This adds value beyond annotations (readOnlyHint). However, it does not specify TTL duration or cache limits.

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 three sentences, front-loaded with the core purpose, and every sentence adds value. No wasted words 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?

Given the schema covers all parameters, annotations provide readOnlyHint, and an output schema exists, the description provides sufficient context about caching behavior and refresh mechanism. No obvious gaps for a search 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 coverage is 100%, so baseline is 3. The description adds minimal value: it mentions the muscle group filter and refresh behavior, but these are also described in the schema. No new parameter semantics are introduced.

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 purpose: 'Search exercise templates by name with optional muscle group filter.' It uses a specific verb (search) and resource (exercise templates), and distinguishes from sibling tools that fetch by ID or list all.

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 through context (search by name, optional filter) but does not explicitly advise when to use this tool over siblings like get-exercise-templates. No when-not or alternative guidance is 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 indicate destructive and idempotent. Description adds critical details: partial update semantics, null handling, minimum field requirement, and 404 response. No contradictions.

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

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

Four short, direct sentences. Front-loaded with purpose, then key constraints. 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?

For a mutation tool with 18 parameters, the description covers essential behavior, prerequisites, and error case. Could mention successful return value, but not mandatory given no output schema.

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 with descriptions. The description adds value beyond schema: clarifies null meaning, imposes 'at least one measurement field' constraint, and explains partial update behavior.

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 updates an existing body measurement entry for a given date. The phrase 'existing' distinguishes it from create-body-measurement. It explains partial update behavior and prerequisites.

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: only updates existing entries, requires at least one measurement field, nulls omitted, returns 404 if missing. Lacks explicit comparison to alternatives, but the sibling list suggests create-body-measurement for new entries.

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 provide destructiveHint=true and idempotentHint=true. Description confirms mutation ('Update', 'changes applied'). No contradictions, but no additional behavioral context beyond 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?

Two concise sentences, front-loaded with purpose. Every word adds value; 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?

Adequate for a mutation tool with annotations. Lacks details on exercises parameter constraints (e.g., required fields) and validation rules. Output schema would help but is absent.

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 0%, making description critical. Description only lists 'title, notes, and exercise configurations' but does not explain routineId or elaborate on exercise structure. Missing detail for complex nested params.

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?

Description clearly states action 'Update', resource 'routine by ID', and what can be modified (title, notes, exercise configurations). Returns updated routine. Distinguishes from siblings like create-routine or get-routine.

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?

Implies use for existing routines needing modification ('existing routine by ID'). Does not explicitly contrast with create or read tools, but context is clear.

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 already declare destructiveHint=true and idempotentHint=true. The description adds that the tool 'Returns the updated workout with all changes applied', which is useful but does not elaborate on additional side effects, authorization needs, or constraints beyond what annotations and schema imply.

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 (24 words), front-loaded with the core action, and contains no redundant or superfluous information. Every phrase adds necessary context.

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 7 parameters, a complex nested exercises schema, no output schema, and no parameter descriptions, the description is too minimal. It fails to explain update behavior (partial vs full replacement), optionality of fields, or exercise/set structure, leaving significant gaps for an AI agent.

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 0%, so the description carries the burden. It lists modifiable fields but does not explain parameter formats (e.g., ISO8601 for dates) or the structure of 'exercises' and nested objects. This adds marginal value over property names, earning a baseline score.

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 'Update an existing workout by ID' with a specific verb and resource, and enumerates modifiable fields (title, description, times, privacy, exercises). This distinguishes it from sibling tools like create-workout or get-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 usage by stating 'Update an existing workout' but does not explicitly guide when to use this tool versus alternatives like create-workout. No exclusions or prerequisites are mentioned, relying on the tool name for differentiation.

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