Server Quality Checklist

Tool Scores

• hevy_get_routine_foldersD
  1.1/5.0
  Behavior1/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, but the description itself adds no behavioral detail. It does not explain what routine folders are, what data is returned, or how pagination works. The description is purely a label and provides zero additional 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.

  Conciseness2/5

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

  The description is extremely short, but it is under-specified rather than concise. A single noun phrase is not a functional description and does not 'earn its place' as a useful sentence. Similar to the 'Process' example, brevity here is a deficiency, not a virtue.

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

  Completeness1/5

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

  Given the two pagination parameters and no output schema, the description should explain what a routine folder is and what the response contains. It fails to provide any meaningful context, making the tool nearly impossible to use correctly without external knowledge.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not mention the 'page' or 'pageSize' parameters. The agent must rely solely on parameter names and schema constraints, with no explanation of their meaning or default behavior in the context of fetching routine folders.

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

  Purpose1/5

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

  The description 'Your routine folders.' is a possessive noun phrase with no verb. It does not state what the tool does, such as retrieving or listing folders. The title partially indicates the purpose, but the description adds no operational clarity and does not distinguish this tool from siblings like hevy_get_routines or hevy_get_routine.

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

  Usage Guidelines1/5

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

  There is no guidance on when to use this tool versus alternatives. The description lacks context about folder organization or how it relates to routines, leaving the agent without any basis for deciding between this and sibling tools.

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

• hevy_search_capabilitiesC
  2.3/5.0
  Behavior2/5

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

  The description adds no behavioral detail beyond the annotations, which already declare read-only, idempotent, and non-destructive. It does not disclose what the tool outputs, how it behaves, or any side effects. With no output schema, the agent has no understanding of the response.

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

  Conciseness2/5

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

  The description is extremely short and front-loaded, but its brevity is not concise—it is under-specified. It fails to provide essential information, making it less helpful than a slightly longer, complete description.

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

  Completeness2/5

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

  Given that this tool is meant to be used first, the description should explain what 'capabilities' are searched, what inputs do, and what output format to expect. It lacks all of this, and the absence of an output schema further reduces completeness.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not mention the 'limit' or 'query' parameters at all. The agent cannot infer what these parameters mean or how they affect the search, leaving a critical gap.

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

  Purpose2/5

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

  The description 'Find the right Hevy tool' vaguely suggests a discovery/search function, but it does not clearly state what the tool does or what it returns. It relies on the tool name 'search_capabilities' for any real meaning, making it close to a tautology.

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

  Usage Guidelines4/5

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

  'Use first.' is an explicit usage instruction indicating this tool should be invoked before others. However, it does not explain when not to use it or alternatives, 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.

• hevy_get_exercise_templateC
  2.7/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no additional behavioral context beyond 'by id'—it doesn't explain return behavior, error cases, or any side effects. This is thin even for a simple get-by-id tool.

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

  Conciseness3/5

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

  The description is a single fragment, making it concise and front-loaded. However, it is under-specified and the phrase 'one exercise template by id' largely restates the title, so it doesn't maximize the value of its brevity.

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

  Completeness3/5

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

  Given the tool's simplicity (one parameter, no output schema) and strong annotations, a minimal description may suffice. Still, it omits what the returned template looks like or any mention of the search sibling, leaving some gaps even for a basic get-by-id operation.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description only says 'by id,' which adds minimal meaning beyond the parameter name 'exerciseTemplateId.' It doesn't clarify the format, source, or expected value of the ID. The parameter name is self-explanatory, but the description does not compensate for the absence of schema-level documentation.

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

  Purpose4/5

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

  The description clearly identifies the resource ('One exercise template') and the retrieval scope ('by id'), which distinguishes it from sibling search tools like hevy_search_exercise_templates. It is specific but relies on the title for the verb, making it slightly less explicit than an ideal purpose statement.

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

  Usage Guidelines2/5

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

  The phrase 'by id' implies use when you have a specific exercise template ID, but it provides no explicit guidance about when to prefer this over alternatives such as hevy_search_exercise_templates. No exclusions or conditions are stated, and the tool is not clearly differentiated from sibling read tools.

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

• hevy_get_workoutC
  2.7/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. However, the description adds no behavioral context beyond that, failing to mention return format, error behavior when not found, or pagination (if any). Without an output schema, the description should carry more weight, 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.

  Conciseness4/5

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

  The description is a single, compact sentence with no fluff. It is efficient and front-loaded, though the brevity borders on under-specification. Still, for a simple get-by-id operation, the structure is appropriately minimal.

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

  Completeness2/5

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

  Given the tool complexity, having only one parameter and no output schema, the description is still too thin. It does not clarify the return value, how to obtain a valid workoutId, or how this differs from other workout-related tools. Annotations help with safety but do not compensate for missing functional context.

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

  Parameters2/5

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

  With 0% schema description coverage, the description should explain the parameter. 'by id' merely restates the parameter name workoutId and adds no detail about format, source, or restrictions. It provides no extra meaning 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.

  Purpose4/5

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

  The description 'One workout by id.' clearly states it fetches a single workout by its identifier, using a specific verb and resource. It implicitly distinguishes from the sibling 'hevy_get_workouts' by emphasizing singular 'one' but does not explicitly name the alternative.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like hevy_get_workouts or hevy_get_workout_events. There is no mention of prerequisites, such as obtaining a workoutId from a list call, or any exclusions.

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

• hevy_get_routinesB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint(false). The description adds the pagination cap 'Max 10 per page' and clarifies that routines are training templates, but does not describe response format, ordering, or other runtime behavior. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is extremely concise, using two short, front-loaded clauses. Every word adds value, with no redundancy or filler.

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

  Completeness4/5

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

  Given the low complexity (2 optional params, no output schema), the description is adequate: it states the resource type and pagination constraint. It lacks details like return format or ordering, but annotations and schema cover most safety and parameter needs.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain the 'page' or 'pageSize' parameters beyond the generic 'Max 10 per page.' Parameter names are self-explanatory, but the description adds minimal value over the schema defaults and constraints.

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

  Purpose4/5

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

  The description identifies the resource as 'saved routines (training templates)', which clarifies the tool's purpose and distinguishes it from related tools like hevy_get_routine (singular). However, it lacks an explicit verb and does not fully differentiate from sibling tools.

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

  Usage Guidelines3/5

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

  The usage is implied: fetch saved routines. But there is no explicit statement of when to use this tool vs alternatives, such as using hevy_get_routine for a single routine or hevy_get_routine_folders for folder structure.

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

• hevy_get_user_infoA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the return fields (id, name, profile URL), which is helpful since there is no output schema. However, it does not elaborate on authentication requirements or any behavior beyond the raw output.

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

  Conciseness5/5

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

  The description is a single short sentence that is immediately informative. It contains no filler and presents the core information upfront.

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

  Completeness4/5

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

  For a simple parameterless getter with rich annotations, the description adequately states the resource and expected output fields. It could explicitly say 'authenticated user' but 'Your' implies that context. The lack of an output schema makes the field list valuable, but no further behavioral details are needed.

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

  Parameters4/5

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

  With zero parameters, the schema is fully complete (100% coverage). The description correctly avoids inventing parameter details. The baseline for parameterless tools is 4, and nothing reduces that.

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

  Purpose4/5

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

  The description states the resource ('Your Hevy profile') and the specific fields ('id, name, profile URL'), making it clear this tool retrieves the current user's profile. It distinguishes from siblings like hevy_get_workouts and hevy_get_routines, which target different resources. The absence of an explicit verb is acceptable given 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.

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or the context of being connected. The intended usage is only implied by the tool name and the broad set of sibling tools.

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

• hevy_get_exercise_historyA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context beyond those hints: 'every recorded set' specifies set-level granularity, 'for one exercise template' clarifies the required scoping, and 'over time' implies chronological data. It does not cover pagination or ordering, but given the annotations this is adequate.

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

  Conciseness5/5

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

  A single, dense sentence that front-loads the core purpose and adds a use-case rationale. Every word earns its place with no repetition or filler.

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

  Completeness3/5

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

  The description conveys the output granularity (sets) and the scoping (one exercise template) well, which is a solid foundation. However, with no output schema and no mention of date-range behavior, response format, or required parameter identification, the description is not fully complete for a tool that has 3 parameters and no structured response definition.

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

  Parameters2/5

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

  Only 33% of parameters have schema descriptions, so the description must compensate—but it provides almost no parameter-level guidance. It hints at the template scoping (which maps loosely to exerciseTemplateId) and time period ('over time'), but never explicitly maps endDate, startDate, or exerciseTemplateId to their roles. The agent is left to infer too much.

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

  Purpose4/5

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

  The description clearly identifies the resource (every recorded set for one exercise template) and the time-based scope, and it contrasts with sibling tools by framing this as the tool for judging progression. However, it lacks an explicit verb like 'list' or 'returns', relying on the tool name for the action.

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

  Usage Guidelines4/5

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

  The phrase 'the right tool for judging progression on a specific lift' gives a clear when-to-use context and implicitly distinguishes it from one-time template lookups or general workout listings. It does not explicitly name alternatives or exclusion cases, 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.

• hevy_get_body_measurementsA
  3.8/5.0
  Behavior4/5

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

  The description goes beyond the readOnlyHint annotation by explaining the design rationale: the server deliberately avoids writing measurements to prevent competing records with Withings. This adds meaningful behavioral context about the tool's integration with an external system, which is not conveyed by the annotations alone.

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

  Conciseness5/5

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

  The description is exceptionally concise, consisting of two sentences that each add value. The first sentence identifies the resource, and the second explains the read-only design rationale. There is no fluff or redundant repetition of the schema or annotations.

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

  Completeness4/5

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

  For a tool with two simple pagination parameters and no output schema, the description provides sufficient context about the resource and its read-only nature, including the Withings relationship. It does not describe the response structure or explicitly mention pagination, but given the simplicity of the tool and the presence of clear annotations, this is a minor gap.

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

  Parameters2/5

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

  The input schema has no descriptions for the parameters (0% schema description coverage), and the description does not mention pagination or the meaning of 'page' and 'pageSize'. The parameter names are somewhat self-explanatory, but the description fails to compensate for the lack of schema-level documentation, leaving semantics ambiguous.

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

  Purpose4/5

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

  The description clearly identifies the resource as body measurements stored in Hevy, which distinguishes it from the workout-related sibling tools. However, it lacks an explicit action verb like 'retrieve' or 'list' in the description itself, relying on the tool name for the action component.

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

  Usage Guidelines4/5

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

  The description provides clear context that this tool is read-only by design and that Withings is the source of truth, implying it should be used for reading measurements rather than writing. It does not explicitly name alternative tools or state when not to use this tool, but the source-of-truth rationale gives strong usage guidance.

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

• hevy_search_exercise_templatesA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond this by disclosing that Hevy has no server-side search and that the tool pages through templates and filters locally, which explains potential performance and pagination behavior.

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

  Conciseness5/5

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

  The description is concise and front-loaded with the purpose, followed by a relevant caveat. Every sentence adds value, and there is no wasted text.

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

  Completeness3/5

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

  For a simple search tool with no output schema, the description covers the purpose and a key behavioral quirk (local filtering). However, it does not mention what the response contains (e.g., a list of templates with IDs), and it doesn't explain pagination parameters in enough detail. This makes it complete for a rough understanding but not fully self-sufficient.

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

  Parameters2/5

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

  Schema description coverage is only 33% (only 'query' has a description). The description mentions 'pages through templates' which implicitly relates to maxPages and pageSize, but it does not explicitly explain their behavior or how pagination works. Given the low coverage, the description should compensate more, but it leaves these parameters under-specified.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: to find exercise templates by name and retrieve the exercise_template_id needed for creating workouts/routines. It uses a specific verb ('Find') and indicates the resource and outcome, making it easy to understand what the tool does.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool (when you need to search templates by name) and provides context about Hevy's lack of server-side search. However, it does not explicitly contrast with sibling tools like get_exercise_template, which fetches by ID, so guidance is present but not fully complete.

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

• hevy_get_workout_countA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe read. The description adds the 'you have logged' context, but does not elaborate on return format or behavior when the count is zero.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no filler. Every word earns its place.

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

  Completeness4/5

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

  For a trivial zero-parameter tool, the description is adequate. It could note that the count is unfiltered (all workouts), but the simplicity of the tool reduces the need for additional context.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema is empty with 100% coverage. The baseline is 4, and the description does not need to add parameter details.

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

  Purpose5/5

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

  The description 'Total number of workouts you have logged' clearly identifies the tool as returning a count of workouts, distinguishing it from siblings like hevy_get_workouts (which lists) and hevy_get_workout (which retrieves a single workout).

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

  Usage Guidelines3/5

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

  The description implies the tool is for obtaining a total count rather than detailed workout data, but it does not explicitly state when to prefer it over hevy_get_workouts or other alternatives. No exclusions or conditions are mentioned.

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

• hevy_statusA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat those. It adds minimal context beyond the annotations—simply stating what the tool reports. No additional behavioral details are provided, but nothing contradicts the annotations.

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

  Conciseness5/5

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

  The description is a single, concise sentence that fully conveys the tool's purpose without any unnecessary words. It is perfectly sized for a simple status endpoint.

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

  Completeness5/5

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

  For a zero-parameter status tool with extensive annotations (readOnly, idempotent, non-destructive), this description is complete. It tells the agent exactly what the tool does, and the annotations cover the behavioral context. No output schema exists, but the description need not explain return values.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema shows an empty properties object. The description adds no parameter information, but with no parameters, the baseline of 4 is appropriate. There is nothing to clarify.

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

  Purpose4/5

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

  The description 'Whether your Hevy account is linked' clearly communicates the tool's function: reporting the connection status. It distinguishes itself from sibling tools like hevy_connect and hevy_disconnect, but lacks an explicit verb such as 'checks' or 'returns', so it falls just 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.

  Usage Guidelines4/5

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

  The purpose itself implies when to use this tool: when you need to know if the Hevy account is linked. It does not explicitly mention alternatives or exclusions, but the context is clear given the sibling tools are all actions or data retrievals, and this is the only status check.

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

• hevy_disconnectA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, and the description confirms the destructive removal action. It adds context by specifying exactly what is removed ('stored Hevy API key') and the scope ('from this server'), but does not disclose additional behavioral details like reversibility or impact on other data.

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

  Conciseness5/5

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

  A single, clear sentence that is front-loaded and free of unnecessary words. It earns its place entirely.

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

  Completeness5/5

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

  The tool is simple: no parameters, no output schema, and annotations cover the safety profile. The description fully explains the action and its scope for a 0-parameter tool.

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

  Parameters4/5

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

  With zero parameters and 100% schema description coverage, there is nothing to add. Baseline for 0 params is 4, and the description appropriately contains no parameter information.

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

  Purpose5/5

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

  The description uses a specific verb ('Remove') and resource ('your stored Hevy API key from this server'), clearly distinguishing it from siblings like hevy_connect (which likely adds a key) and hevy_status. The scope is explicit.

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

  Usage Guidelines3/5

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

  Usage is implied by the name and description: use when you want to disconnect Hevy by removing the stored API key. However, there is no explicit guidance about when to use this versus alternatives, nor any mention of prerequisites or consequences.

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

• hevy_get_workout_eventsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond this: the tool returns a delta set of workouts updated or deleted since a timestamp, which is a key behavioral trait for an incremental sync flow.

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

  Conciseness5/5

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

  The description is a single sentence that is front-loaded with the core purpose, followed by the usage recommendation. No unnecessary words or repetition, achieving high information density.

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

  Completeness3/5

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

  The description covers the primary use case and is aided by strong annotations, but it omits details about the response format (e.g., event structure, whether it includes workout objects or just IDs) and pagination behavior. With no output schema, these gaps make the description only partially complete for an agent to reliably invoke and process results.

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

  Parameters2/5

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

  Schema description coverage is only 33% (only 'since' has a description). The description clarifies the purpose of 'since' (incremental sync filtering) but does not compensate for the undocumented 'page' and 'pageSize' parameters. Low coverage requires the description to step up, and it does so incompletely.

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

  Purpose5/5

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

  The description clearly states the tool returns workout events (updates/deletions) since a timestamp, with the explicit goal of incremental sync. It distinguishes itself from sibling tools like hevy_get_workouts (full list) and hevy_get_workout (single workout) by emphasizing the delta-based scope.

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

  Usage Guidelines5/5

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

  The description explicitly says 'use for incremental sync rather than re-reading everything,' providing a clear when-to-use directive and contrasting with the alternative of fetching the full workout set. Though no sibling is named, the guidance is unambiguous.

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

• hevy_get_workoutsA
  4.2/5.0
  Behavior5/5

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

  The description discloses ordering ('newest first'), response richness ('full exercise and set detail'), and pagination cap ('Max 10 per page'), going beyond annotations that only declare readOnly/idempotent. It does not contradict annotations and adds meaningful behavioral context.

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

  Conciseness5/5

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

  The description is a single concise sentence with 15 words, front-loading the key purpose. Every word contributes meaning, including ordering, detail level, and pagination limit, with no filler.

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

  Completeness5/5

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

  For a simple read-only list tool with good annotations, the description adequately covers what is returned, ordering, and page size, which is sufficient given the absence of an output schema. It is complete enough for an agent to invoke correctly.

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

  Parameters2/5

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

  The schema has two parameters (page, pageSize) with 0% description coverage. The description only mentions 'Max 10 per page', which redundantly mirrors pageSize's maximum constraint and does not explain the page parameter or default behavior. It fails to compensate for the lack of schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool returns 'your logged workouts' with 'full exercise and set detail', indicating a list operation. It distinguishes itself from siblings by specifying newest-first ordering and page size limitation, separating it from hevy_get_workout (single workout) and hevy_get_workout_count.

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

  Usage Guidelines3/5

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

  The description implies usage for browsing workout history with 'your logged workouts' and pagination info, but it does not explicitly mention alternatives or when not to use. There is no mention of hevy_get_workout for single-workout needs, leaving usage guidance to inference.

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

• hevy_get_routineA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context about the update workflow (that updates replace the entire routine), which is beyond the annotations and helps the agent understand the tool's role in a multi-step process.

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

  Conciseness5/5

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

  Two sentences, both information-dense. The first states the core function, the second adds a critical usage warning. No fluff or repetition.

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

  Completeness5/5

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

  For a simple get-by-id tool with one required parameter, rich annotations, and no output schema, the description covers the essential workflow context and safety profile. Nothing critical is missing for an agent to select and invoke this tool correctly.

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

  Parameters3/5

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

  The schema has one parameter, routineId (string, minLength 1), with no description coverage. The description only says 'by id', which adds minimal meaning beyond the parameter name itself. Since there is only one parameter and its purpose is self-evident, the description does not need extensive compensation, but it also provides no extra format or sourcing guidance.

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

  Purpose5/5

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

  The description states 'One routine by id' with a specific verb and resource, clearly distinguishing from the sibling hevy_get_routines (plural). It also immediately signals the tool's role in the update workflow, 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.

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance: 'Always fetch this before hevy_update_routine — updates replace the entire routine.' This directly addresses the usage context and differentiates it from the update tool, offering a clear workflow directive.

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

• hevy_connectA
  4.6/5.0
  Behavior5/5

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

  The description reveals key behavioral details beyond the annotations: the key is never sent through the conversation, the link is one-time, and the prerequisite of Hevy Pro is disclosed. This adds substantial context that is not present in the annotations, which are minimal.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action ('Start linking YOUR Hevy account') followed by essential details. Every clause adds value, including where to get the key, the browser requirement, and the subscription requirement. No waste.

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

  Completeness4/5

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

  The description fully explains the linking flow, including the return of a one-time link and the security aspect of not sending the key through the conversation. It covers prerequisites and steps, though it could additionally mention behavior if the account is already linked or error cases, but these are not critical for initial use.

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

  Parameters4/5

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

  The input schema has no parameters (schema coverage 100% by default), so the description does not need to explain parameters. With zero parameters, the baseline is 4, and the description appropriately avoids adding irrelevant parameter information.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Start linking YOUR Hevy account' and explains it returns a one-time link for pasting an API key. This specific verb+resource combination distinguishes it from sibling tools like hevy_disconnect, hevy_status, and the various getters.

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

  Usage Guidelines4/5

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

  The description provides clear guidance on how to use the tool: it tells the user where to find the API key (hevy.com/settings?developer), that it must be done in a browser, and that it requires a Hevy Pro subscription. It does not explicitly mention alternatives or when not to use it, but the context of linking an account is clearly implied in contrast to sibling tools.

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