Hevy MCP Pro

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct entity and action, with clear separation between list/get/create/update and analytical operations. Even similar tools like search_exercise_templates and list_exercise_templates have clearly differentiated purposes described in their summaries.
Naming Consistency4/5
The vast majority of tools follow a consistent verb_noun snake_case pattern (e.g., list_workouts, create_workout, get_exercise_history). The single exception is 'routine_from_workout', which deviates from the pattern but remains readable and clear.
Tool Count3/5
With 27 tools, the server is heavier than the ideal 3-15 range, but the breadth covers multiple entities (workouts, routines, templates, folders) plus analytics. The count feels justified for a feature-rich API, though it is borderline excessive.
Completeness2/5
The server lacks delete operations for all entities (workouts, routines, exercise templates, routine folders), preventing full lifecycle management. While CRUD for create/get/update exists, the inability to delete creates dead ends and forces workarounds.
Average 3.9/5 across 27 of 27 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It mentions that Hevy enforces a max pageSize of 10, but this is already encoded in the schema (pageSize maximum: 10) and adds no new information. The description does not state whether this is a read-only operation, what the return format looks like, whether pagination uses page numbers, or any authentication requirements. Thus, beyond the schema, it provides minimal transparent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with the primary purpose stated in the first sentence. The second sentence about Hevy enforcement is concise and adds a small piece of context, though it is redundant with schema. No filler or verbose phrasing is present, so the description is efficiently written.
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?
This is a list operation with two optional parameters and no output schema, so the description should at least indicate what the tool returns (e.g., a list of routine folders) and any pagination behavior. It does neither. Additionally, no usage context is provided, leaving the tool incomplete for an agent to confidently invoke without resorting to guessing or other tools.
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?
The input schema has two parameters (page, pageSize) with 0% description coverage, so the description must compensate by explaining their meaning. However, the description only repeats the pageSize max via 'Hevy enforces a max pageSize of 10' and does not explain what page or pageSize represent, how pagination works, or how to combine them. Since the description adds no semantic value beyond the schema, it fails to meet the compensation requirement.
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 'List routine folders' clearly states the action (list) and resource (routine folders), making the tool's purpose obvious. It is distinct from sibling tools like get_routine_folder or create_routine_folder, though it doesn't explicitly differentiate itself from other list tools such as list_routines. The name itself already provides strong clarity, earning a 4.
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 list_routines, get_routine_folder, or any other sibling, nor does it state any exclusions or preferred scenarios. The only extra sentence about max pageSize is a constraint, not usage context, so the description fails to help the agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It contributes useful behavioral context: reverse-chronological order and a hard API limit of pageSize 10. However, it omits details like return format, pagination semantics beyond pageSize, or any explicit read-only indication, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences with no filler. The first states the core purpose, and the second surfaces a concrete API constraint. Every word earns its place; it is appropriately front-loaded and economical.
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 is minimally sufficient for a basic list tool: it names the resource, order, and a pagination constraint. However, with no annotations and no output schema, the agent lacks information about the return structure, what fields a workout contains, or whether this lists all workouts for the user. Additional context would improve completeness.
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 0% description coverage, so the description must compensate. It only mentions the pageSize limit, which is already encoded in the schema's maximum constraint, and says nothing about the page parameter. Thus it adds minimal semantic value beyond the structured schema.
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 operation as listing workouts and adds the reverse-chronological ordering detail, making the verb+resource pairing specific. It does not explicitly distinguish itself from sibling tools like get_workout or list_routines, but the plural 'workouts' and the listing intent are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention use cases, exclusions, or how it relates to get_workout, get_workout_count, or list_routines, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It fails to mention persistence, side effects, permissions, or return values, which is minimal for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action, lists key parameters, and contains no filler or repetition. Every word adds value.
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 lack of output schema and annotations, the description is under-specified for a creation tool. It omits return values, error scenarios, and any post-creation behavior, leaving the agent without complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly names required fields (title, exercise_type, equipment_category, muscle_group) and highlights other_muscles as optional. This partially compensates for the 0% schema description coverage, though it does not elaborate on field meanings beyond the schema enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a custom exercise template'—a specific verb and resource. It distinguishes itself from sibling tools like list_exercise_templates and get_exercise_template by focusing on the creation action.
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 over alternatives such as create_workout or create_routine. It only lists required fields without contextual advice, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions one constraint (max pageSize of 10) but does not describe the return format, pagination behavior, authentication requirements, or the fact that this is a read-only operation. This is a significant gap for a tool with no safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose, followed by a relevant constraint. Every word adds value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description gives a basic understanding of the operation and a key constraint, but lacks details about the response structure or pagination behavior. This is adequate for a simple list operation, but not complete enough for an agent to predict the full output without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions pageSize's maximum, providing no additional meaning for the page parameter. Although the schema itself includes defaults and constraints, the description does not help an agent understand the semantics of pagination parameters beyond what the schema already declares.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'saved routines (workout templates)', distinguishing it from sibling tools like list_workouts (which likely lists workout sessions) and get_routine (single routine fetch). This is a specific and unambiguous 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but the name and resource type imply it is for browsing all routines, contrasting with get_routine for a single routine. The note about pageSize being capped at 10 gives a practical usage hint, but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does add a useful caveat about the Hevy app not rendering rep_range, and notes the optional folder behavior. However, it omits other behaviors like return value, idempotency, or permission requirements, leaving a partial picture.
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 with no fluff. The first sentence states the purpose; the second provides a critical compatibility note. Every word earns its place, and the most important information is front-loaded.
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?
This tool has a complex nested schema, no annotations, and no output schema. The description only touches on folder_id and rep_range, leaving the agent without details on expected return values, error cases, or how to structure a valid routine beyond schema constraints. It is incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains folder_id and the rep_range caveat, but does not clarify the routine object structure, required fields, or typical usage for other nested parameters. The schema provides types, but the agent still lacks guidance on parameter intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new routine,' a specific verb+resource statement that clearly distinguishes this from siblings like update_routine and list_routines. It also adds the optional folder context, reinforcing the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new routines, but does not explicitly contrast with alternatives (e.g., update_routine) or provide when-not-to-use guidance. The folder mention offers limited context, but no exclusions or alternative references are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses strict validation and required fields, which is helpful behavioral context. However, with no annotations, it does not mention side effects, authentication, return values, or error behavior, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose, and every sentence adds essential information without redundancy.
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 complex nested schema and lack of output schema, the description is incomplete. It fails to explain optional fields, return values, or validation failures, which are critical for a creation tool with a rich data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning for required fields (title, start_time/end_time ISO 8601, exercises with sets), but the schema has no descriptions for many optional nested properties (e.g., rpe, superset_id, custom_metric). With 0% schema coverage, the description only partially compensates, leaving many parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create a new workout') with a specific verb and resource. It distinguishes itself from sibling tools like update_workout and duplicate_workout by focusing on creation.
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 creating a workout, but it does not explicitly state when to use it versus alternatives (e.g., update_workout). No exclusions or alternative tool mentions are provided, leaving usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Fetch', which implies a read-only operation, but it does not disclose return format, error behavior, or any side effects. Since there is no output schema, the agent is left without information about what the tool actually returns or how it behaves on failure.
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 is front-loaded with the verb and resource. It contains no filler or redundant information, making it exceptionally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, the description covers the core action but lacks return value details and error handling. Since no output schema exists, the description should ideally clarify what the response looks like (e.g., returns a routine folder object) and possible failure modes. The absence of this information makes it minimally complete but not fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers folderId as a required integer with no description. The description adds 'by its numeric ID', confirming that folderId is the numeric identifier, but it does not explain where the ID comes from or any constraints (e.g., positive integer). This partially compensates for the 0% schema description coverage but is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('a single routine folder'), and the method ('by its numeric ID'). This distinguishes it from sibling tools like list_routine_folders (lists all) and create_routine_folder (creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a numeric folder ID and need a single folder, but it does not explicitly mention alternatives or exclusion cases. Sibling tool names provide context, but the description lacks explicit 'when to use this vs. that' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It usefully notes that id, index, and timestamps are server-assigned, but it does not mention side effects, required permissions, or behavior on duplicate titles. For a create operation, this is moderate transparency but leaves gaps.
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, action-first, with no waste. The additional clause about server-assigned fields is concise and valuable, making the sentence efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with one required parameter and no output schema. The description covers the essential behavior (creation and server-side field assignment) and is reasonably complete for this simplicity. It doesn't mention return values or errors, but those are not strictly required given the context signals.
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%, so the description must compensate. It only repeats 'given title' without adding semantics like uniqueness, formatting, or length constraints (beyond schema's minLength). Since there is only one parameter, the description should provide more meaningful guidance but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Create') and resource ('routine folder'), and distinguishes it from sibling tools like create_routine by specifying 'folder'. It also clarifies that only the title is user-provided, with all other fields server-assigned.
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 creating routine folders but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the sibling tools. The context of a create operation is clear, but there are no exclusions or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It adds value by stating that the full workout body must be supplied and that this is a full replacement, not a patch. However, it does not disclose other behavioral traits such as authentication requirements, rate limits, side effects on associated data, or error behavior, leaving some gaps.
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 and front-loaded. The first sentence states the core action, and the second clarifies the replacement semantics. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with nested objects, required fields, and no output schema or annotations. The description provides minimal context: it only explains the full replacement nature. It does not mention return values, validation behavior, or any operational context. Given the complexity, the description is incomplete and leaves the agent without sufficient guidance.
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%, so the description must compensate for the lack of parameter explanations. It only mentions 'full workout body' and 'ID' without detailing the structure or meaning of the parameters. The schema itself provides the details, but the description adds little value beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Replace an existing workout by ID.' This is a specific verb + resource and distinguishes it from create_workout, get_workout, and other sibling tools. It also clarifies the critical semantic of full replacement vs. patch, leaving no ambiguity about the intended operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for full replacement of an existing workout, not a patch. It implies when to use it (when you need to overwrite the entire workout). However, it does not explicitly name alternatives (e.g., create_workout for new workouts) or state when not to use it, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately indicates a read operation but does not disclose what happens if the ID doesn't exist (e.g., error vs. null), whether authentication is required, or the structure of the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-ID tool, the description covers the essential purpose. Although it lacks details on errors or return format, the tool's complexity is low and the parameter is minimal. It is sufficient for an agent to select it, though not exhaustive.
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, templateId, which is self-explanatory from its name and the description's mention of 'ID'. However, the description does not add detail about the expected format of the ID or how to obtain it, and schema description coverage is 0%, so the description provides limited added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and clearly identifies the resource ('a single exercise template') and the selection mechanism ('by its ID'). This distinguishes it from sibling tools like list_exercise_templates or search_exercise_templates, which are for multiple templates.
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 context is clear: use this when you have a specific template ID. However, it does not explicitly state when to avoid this tool or mention alternatives like list_exercise_templates or search_exercise_templates for broader queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the conditional endpoint usage, pagination behavior, return shape (per-exercise map), and the possible warning field for truncation. This is valuable behavioral context beyond a simple 'get records' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, and every clause earns its place. The structure is highly efficient, packing behavioral details into a compact space without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key behavioral branches (single call vs. pagination) and the output map, but the missing 'since' parameter explanation and explicit return-value documentation leave gaps. It is adequate but not fully complete for a tool with no annotations or output schema.
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%, so the description must compensate. It explains exerciseTemplateId's effect on the call path, but completely omits the 'since' parameter, leaving its purpose ambiguous. This is a significant gap for a parameter with only a generic 'string' type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Return' and clearly lists the exact outputs: heaviest-weight, best-set, and top estimated 1RM PRs. This strongly distinguishes it from siblings like get_workout or get_exercise_history.
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?
It provides partial usage context by explaining the conditional behavior (if exerciseTemplateId is provided vs. paginating otherwise), but it doesn't explicitly state when to choose this tool over alternatives or exclude scenarios. The guidance is implied by the nature of PRs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the return content (summaries, deltas, per-exercise diff) and the sorting order, which is useful behavioral context. However, it does not explicitly state that it is read-only or address error cases, but the description's clarity on output structure is a strong disclosure.
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, with two sentences front-loading the purpose followed by output details. Every clause adds value, with no fluff, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return values (summaries, deltas, diff) and ordering. It lacks guidance on edge cases or parameter validation, but for a comparison tool with clear inputs, it is reasonably complete.
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 compensate by explaining the parameters. Though the parameter names workoutIdA and workoutIdB are self-explanatory in the schema, the description adds no direct meaning about them, failing to meet the requirement for low coverage to compensate.
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 compares two workouts side-by-side, using the specific verb 'compare' and naming the resource. It distinguishes itself from sibling tools like get_workout or list_workouts, which handle single workouts rather than comparisons.
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 should be used when comparing two workouts, but it does not explicitly mention when not to use it or name any alternatives. No exclusions or direct references to sibling tools are provided, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explains the new workout's startTime default, that it preserves duration/title/exercises/sets, and implies a new record is created without modifying the original. It does not mention return values or edge cases, but covers the essential mutation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with no filler. It front-loads the purpose and uses a backtick for the parameter. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and lack of annotations, the description is largely complete: it explains what is duplicated, the default start behavior, and which fields are preserved. It lacks an explicit statement about the return value or that the original remains unchanged, but these are reasonably inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds semantics for startTime (defaults to now), but workoutId is only indirectly implied as the existing workout reference. The description does not fully explain all parameters, but the required one is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (duplicate), the resource (an existing workout), and the key result (a new workout preserving specified attributes). It is easily distinguished from sibling tools like create_workout and update_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to duplicate an existing workout) but does not explicitly mention alternatives or exclusions. It lacks guidance such as 'use create_workout for new workouts' or 'do not use for copying routines.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states that the tool returns a total count for the authenticated account, but it does not elaborate on the exact return format (e.g., plain integer vs. JSON object) or any potential error conditions. For such a simple endpoint, the minimal transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information without any filler. It is front-loaded with the action and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is quite complete: it states what is counted and for whom. It doesn't specify the return data type, which could be a minor gap, but given the simplicity of 'total count,' the description is sufficiently complete for an agent to understand the tool's purpose and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and baseline for 0 params is 4. The description adds no parameter details because none exist, and the schema already fully covers the empty parameter set. There is nothing more to explain, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the total number of workouts logged for the authenticated account.' It uses a specific verb ('get') and resource ('total number of workouts'), and this count-based function is distinct from sibling tools like list_workouts and get_workout_events, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining what it returns, but it does not explicitly state when to use this tool versus alternatives such as list_workouts. Usage is implied rather than explicitly contrasted with sibling tools, so it falls short of a 4 for clear exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it copies exercises and sets, drops RPE because routines don't support it, and places the routine in a folder if provided. This goes beyond a generic creation verb, although it omits potential side effects like whether the workout is modified, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two focused sentences. The first sentence states the purpose, the second adds key behavioral detail. No filler or repetition, earning a high score.
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 3-parameter creation tool with no output schema or annotations, the description covers the core behavior and important nuance (RPE drop). It doesn't mention return values or error cases, but those are less critical for selection and invocation. The main gap is the missing title parameter clarification, which is partially handled by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clarifies workoutId as an existing workout and folderId as the target folder, but does not explain the title parameter beyond the schema. This is partial compensation, leaving some ambiguity for the routine title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'a new routine from an existing workout', distinguishing it from create_routine (blank) and duplicate_workout (workout-to-workout). It also specifies that exercises and sets are copied, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when you want to convert an existing workout into a routine. However, it does not explicitly mention when not to use it or compare with alternatives like create_routine or duplicate_workout. The note about dropping RPE hints at a limitation but doesn't provide explicit selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses a key behavioral trait: folder_id is not accepted on update. 'Replace' also clarifies that it is a full replacement, not a partial update. However, it does not mention return values, error behavior, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loading the core purpose and then providing a critical constraint. No wasted words, perfectly concise.
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 action and the folder_id limitation. However, with no output schema and a complex nested input, it would benefit from stating what the API returns (e.g., updated routine) or any prerequisites (e.g., routine must exist). It is missing those but otherwise adequate for a straightforward update tool.
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%, so the description must compensate. It only clarifies routineId ('by ID') but provides no explanation of the complex 'routine' parameter or its nested structure. The schema is exhaustive but lacks descriptions, leaving the agent without semantic guidance for the payload.
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 'Replace an existing routine by ID', which is a specific verb+resource+method. It distinguishes from sibling tools like create_routine and get_routine by indicating the update/replace 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 description gives clear context for the tool and explicitly notes that folder moves cannot be done via API ('folder moves happen via the mobile app only'), providing a specific exclusion. It does not mention alternatives by name, but the tool name and context make the primary usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a read operation ('Fetch') and adds that the return includes nested exercises and sets, which is useful behavioral detail. It does not discuss error behavior or authentication, but for a simple fetch these are not critical. The description adds value beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the core purpose. Every word adds value; there is no fluff or redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, this description is largely complete. It states the action, resource, and what is included in the response. It does not mention error handling or edge cases, but these are not typically required for a straightforward fetch. Given the low complexity, the description is 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?
The input schema has 0% description coverage, and the description only mentions 'by its ID', which essentially restates the parameter name 'routineId'. It does not explain the ID format, any constraints beyond minLength, or provide additional context about the parameter. The description does not meaningfully 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 action ('Fetch'), the resource ('a single routine'), and the scope ('by its ID'). It also adds that the response includes 'all planned exercises and sets', which distinguishes it from listing or folder tools. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need a specific routine's details by ID. While it does not explicitly name alternatives or exclusions, the context is unambiguous given the verb 'Fetch' and the resource 'single routine'. Sibling tools like list_routines provide clear contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explicitly states that Hevy enforces a max pageSize of 10, adding operational nuance beyond the schema's maximum value, and describes events as created/updated/deleted. The read-only nature is implied by 'get' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver purpose, event types, usage context, and a critical constraint without any filler. The structure front-loads the core action and efficiently adds supporting details.
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 purpose, primary parameter, and a key constraint. However, without an output schema, the response shape (e.g., bare array vs paginated envelope) and event field details are unspecified, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the meaning of 'since' (ISO 8601 timestamp) and pageSize (max 10 enforced by Hevy), but does not mention the 'page' parameter. Since schema description coverage is 0%, this partial compensation leaves one parameter undocumented in natural language.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a precise resource ('workout sync events') and enumerates event types (created/updated/deleted) and a time filter. This clearly distinguishes it from sibling tools like list_workouts and get_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for incremental sync' provides a clear context for when to use this tool. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It adds context by noting Hevy enforces a max pageSize of 10, which is useful, but it does not describe pagination behavior (e.g., how to fetch pages, whether total count is returned), error handling, or return format. The lack of output schema makes this a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, followed by a critical constraint and an alternative guidance. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers purpose, the page size cap, and an alternative. However, without annotations or an output schema, the agent is left without details on the response structure, pagination flow, or how to handle potential errors. This is incomplete for an agent to confidently invoke and process results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While the parameters (page and pageSize) are self-explanatory pagination fields, the description only elaborates on pageSize through the max cap constraint. It does not clarify the semantics of 'page' (e.g., 1-indexed, how pagination flows) beyond the schema's default. This partially compensates for the missing 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 lists exercise templates, including both built-in and custom types. It uses a specific verb 'List' with a clear resource and scope, and it distinguishes itself from the sibling search_exercise_templates tool which is for fuzzy name matching.
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 directs users to prefer search_exercise_templates for fuzzy name search, providing a clear alternative for a specific use case. This is strong guidance beyond just stating what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral context: per-set history, all workouts scope, optional date bounds, and a cost/performance hint. However, it does not disclose return format, ordering, or error behavior, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and optional parameters, followed by a usage rationale. No filler or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only fetch with no output schema, the description covers the essential context: scope (single template, all workouts), optional date bounding, and performance rationale. It could be more complete by hinting at response contents, but 'per-set history' is reasonably descriptive. Lacks annotations, but the description is still solid.
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?
Despite 0% schema coverage, the description meaningfully adds parameter context: templateId is tied to 'single exercise template', and startDate/endDate are described as optional and ISO 8601. This goes beyond the schema's raw patterns and helps the agent understand input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches per-set history for a single exercise template across all workouts, which is specific and distinguishes it from siblings like list_workouts or get_exercise_progression. It also notes it is cheaper than paginating /v1/workouts, reinforcing its focused purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this when you only care about one exercise and provides an alternative (paginating /v1/workouts). It does not explicitly list when not to use it, but the 'when' condition and alternative are clear enough for most contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the data source, the aggregation logic (best set per session), the Epley formula for 1RM, and the default `since` value. It does not explicitly state whether the operation is read-only, but 'Return' implies it. It also doesn't mention error handling or rate limits, but overall it provides strong 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 three sentences with no filler. It front-loads the core purpose and then adds technical details (API call, output fields, default). Every sentence provides useful information, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description does a good job of covering what is returned (weight, reps, volume, 1RM), the data source, and the time default. However, it does not define what 'best set' means (e.g., highest 1RM), nor does it describe behavior for empty results or whether the time series is sorted ascending, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It meaningfully explains `since` (format and default), but does not elaborate on `exerciseTemplateId` beyond the phrase 'one exercise template', which is largely a restatement of the parameter name. The description adds some value but leaves room for more explicit parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Return'), the resource ('a chronological time series of the best set per session for one exercise template'), and differentiates from the sibling 'get_exercise_history' by focusing on aggregation and derived 1RM. It is both specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it aggregates exercise history into a progression timeline and mentions it uses a single API call (efficiency). However, it does not explicitly name alternatives or state when NOT to use this tool, so it lacks a direct exclusionary guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the transparency burden. 'Fetch' signals a read-only operation, and 'including all exercises and logged sets' discloses the response scope. It omits edge-case details like not-found errors, but for a simple getter this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 14-word sentence that front-loads the action and resource. It includes no filler, redundant phrases, or unnecessary details, earning a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one parameter, no output schema, no annotations—the description provides the essential operation and return content. It does not address error handling or response format in full, but it is adequate for a straightforward get-by-ID tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines workoutId as a string with minLength 1, and schema description coverage is 0%. The description adds 'by its ID', which clarifies the parameter's role, but this is largely a restatement of the parameter name and does not add meaningful format or value guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with a concrete resource 'a single workout' and a clear key qualifier 'by its ID'. It also states the return contents (all exercises and logged sets), which distinguishes it from sibling tools like list_workouts or get_workout_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the usage scenario: retrieving one specific workout's full details rather than a list. It does not explicitly name alternatives or state when not to use it, so it has clear context but no exclusions, matching a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Fetch' implies a read-only operation and 'authenticated user' implies authentication is required, but it does not explicitly state the read-only nature, potential errors, or response format beyond the listed fields. It provides minimal but sufficient transparency for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the verb, resource, and return contents in a compact, readable format.
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, simple read operation, the description provides complete context: it names the resource, lists the returned fields, and implies authentication requirements. The absence of an output schema is compensated for by the description listing the 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 takes no parameters, and the schema is empty, making schema coverage trivially 100%. The baseline for 0 parameters is 4, and the description adds no parameter info because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and clearly identifies the resource as the authenticated user's profile, listing its key contents (id, name, public profile URL). This clearly distinguishes it from the sibling workout/routine tools, which all concern other resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for retrieving the current user's profile information. While no explicit alternatives or exclusion criteria are mentioned, there are no sibling tools for user profile data, so the intended usage is unambiguous and requires no further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the truncation behavior via 'May include a `warning` field if results were truncated' and explains the default for `since`. However, it does not explicitly state that the operation is read-only or describe any other side effects, though the name implies a safe read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary output, then parameter and warning details. Every word is informative, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main output (per-week counts, streak, longest-gap), the parameter, and the warning field, which is adequate for a tool with no output schema. It could additionally clarify what 'streak' means (e.g., consecutive weeks) but is otherwise complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, `since`, is fully explained: 'ISO 8601, default 90 days ago.' This adds meaning beyond the schema's regex pattern by clarifying the format and default value. With 0% schema coverage, the description effectively compensates.
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: 'Per-week workout counts with streak and longest-gap statistics.' This distinguishes it from siblings like get_workout_count (likely a total count) and list_workouts (raw data). The resource and output are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the specialization (per-week stats with streaks and gaps), but it does not explicitly say when to prefer this over alternatives. It mentions the `since` parameter and default, giving context for typical use, but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and performs excellently: it explains the detection logic, reveals defaults for weeksBack and minSessions, specifies the sorted list return, and mentions a warning field for truncation. This is comprehensive behavioral disclosure for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by defaults and return details. Every sentence adds necessary information without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter defaults, return format (list sorted by percent below peak, descending), and a potential warning field. Since there is no output schema, it could further detail the exact fields of each list item, but the provided information is sufficient for most calling scenarios and the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions defaults (weeksBack=8, minSessions=3) and ties weeksBack to the 'window' and minSessions to 'recent sessions', providing some contextual meaning. However, it does not explicitly define the parameters' roles or mention the schema's min/max bounds, leaving the compensation partial. The parameter names are self-explanatory, but the description adds limited value beyond repeating schema defaults.
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 that the tool flags exercises whose peak estimated 1RM occurred earlier in the window, indicating stagnation. It uses a specific verb ('flag') and resource ('exercises'), and the condition distinguishes it from sibling tools like get_personal_records or get_exercise_progression.
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 provides clear context for when to use the tool: when detecting stagnation in exercises where recent sessions fall below peak. It does not explicitly mention alternatives or exclusions, but the stated condition is a strong usage signal. Defaults are provided, aiding immediate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It reveals important traits: nulls are treated as 0 in calculations, pagination occurs over recent workouts, a default 90-day window exists, and a 'warning' field may indicate truncation. This goes beyond the schema and gives the agent actionable expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the primary function. It immediately states what the tool does, then adds necessary details (null handling, date range, pagination, warning) without extraneous text. Every sentence 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 tool with no annotations and no output schema, the description covers the core functionality, parameter semantics, pagination, and truncation behavior. However, it does not specify whether results are limited to the current user's workouts or how pagination works (e.g., page size or cursor), leaving some ambiguity. Still, it is fairly complete for an aggregation 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?
Schema coverage is 0%, but the description compensates by explaining both parameters: 'since' is ISO 8601 with a default of 90 days ago, and the grouping dimensions (exercise, muscle_group, week) map directly to the 'groupBy' enum. It also clarifies the volume formula, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes total training volume (weight_kg * reps) with a precise formula, and distinguishes it from sibling tools by emphasizing aggregation/grouping rather than listing workouts. It names valid grouping dimensions, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to get aggregated volume grouped by exercise, muscle_group, or week, within a date range. It doesn't explicitly exclude alternatives, but the purpose is sufficiently specific that an agent can infer it's for summary/analysis rather than raw workout lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing the cached local execution and sorted output ('Runs locally against a cached copy' and 'Returns top matches sorted by score'). It could mention staleness of the cache, but the disclosed traits are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, and every sentence adds value (e.g., performance advantage, ordering). No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description fully covers what this tool does, when to use it, and what it returns. It sufficiently differentiates from sibling search/list/get tools and provides a complete picture for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'query' (fuzzy search by name) and 'muscleGroup' (optional filter), but only implies the meaning of 'limit' via 'top matches.' The limit parameter's semantics remain incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fuzzy-search exercise templates by name with an optional muscle-group filter.' This is a specific verb+resource+options, distinguishing it from siblings like list_exercise_templates and get_exercise_template.
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?
Explicitly differentiates from the alternative of paginating /v1/exercise_templates by stating it 'runs locally against a cached copy of all templates — much faster and cheaper.' This gives a clear when-to-use recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mcp-hevy-pro MCP server](https://glama.ai/mcp/servers/cbotworks/mcp-hevy-pro/badges/card.svg)](https://glama.ai/mcp/servers/cbotworks/mcp-hevy-pro)

Score Badge

Copy to your README.md:

[![mcp-hevy-pro MCP server](https://glama.ai/mcp/servers/cbotworks/mcp-hevy-pro/badges/score.svg)](https://glama.ai/mcp/servers/cbotworks/mcp-hevy-pro)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cbotworks/mcp-hevy-pro'

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