hevy-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool clearly targets a distinct resource and action, such as workouts, routines, routine folders, and exercise templates. List/detail operations are separated with explicit singular naming (e.g., get_workouts vs get_single_workout), and no two tools appear to serve the same purpose.
Naming Consistency4/5
All tool names use snake_case and follow a verb_noun pattern (get_, create_, update_, delete_). Minor deviations exist with get_single_workout instead of get_workout and get_workout_count as a compound noun, but overall the naming is predictable and consistent.
Tool Count4/5
With 23 tools, the server feels slightly heavy, but the count is justified by covering four distinct resource types (workouts, routines, routine folders, exercise templates), each with appropriate CRUD operations. A few utilities like get_workout_count and get_workout_events add value without bloating the set excessively.
Completeness3/5
The server covers most core workflows: full CRUD for workouts, routines, and routine folders, plus listing, retrieving, creating, and deleting exercise templates. However, there is no update_exercise_template, which is a notable gap since creating and deleting without updating forces a delete/recreate pattern for adjustments.
Average 3.1/5 across 23 of 23 tools scored. Lowest: 2.1/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 status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing side effects and behavioral traits. It merely restates the tool name with no mention of what creation entails, whether it is reversible, or what side effects occur, providing zero transparency.
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 very brief, but this brevity is under-specification rather than effective conciseness. For a tool with a complex nested parameter structure, four words do not provide adequate information, making the brevity a deficiency.
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 complex input schema with nested objects and required fields, and the absence of an output schema, the description is severely incomplete. It provides no indication of return values, required fields, or expected behavior, making it inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description makes no reference to the 'routine' parameter or its nested structure. With schema description coverage at 0%, the agent gains no additional meaning from the description beyond the raw JSON schema, which is insufficient for proper invocation.
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 'Create a new routine' clearly states the action (create) and resource (routine), providing a specific verb and object. However, it does not differentiate from sibling tools like create_workout or update_routine, so it stops short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as create_workout or update_routine. It lacks any context about prerequisites, use cases, or exclusions, leaving the agent to infer applicability on its own.
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 carries the full burden. 'Create a new workout' implies persistence but discloses no details about side effects, validation requirements, or consequences of the operation.
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 concise sentence, but it is under-specified. It conveys only the bare action and omits useful information that would justify its brevity.
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?
This is a complex tool with a deeply nested parameter, no output schema, and no behavioral context. The one-line description is severely inadequate for an agent to correctly construct input or understand the operation.
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 gives no explanation of the 'workout' parameter's structure, required fields, or meaning. The nested object is left entirely to the schema, which itself lacks prose descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'workout', which is distinct from siblings like create_routine or update_workout. However, it lacks any extra detail about scope or differentiation, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., update_workout, create_routine). The description only states the action, with no context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description 'Get user info' does not disclose any behavioral traits such as authentication requirements, response format, or data scope. The phrase merely restates the tool's function without adding transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, but it is under-specified rather than efficiently informative. It could be expanded with one or two clarifying details without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a vague description, the tool is not fully specified. The agent is left uncertain about what 'user info' includes or what the response looks like, making the description incomplete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the description is not required to explain parameter syntax. The empty schema fully defines the parameter space, and the baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user info' uses a clear verb and resource, but is vague about what specific user info is included. It does distinguish from the workout/routine/exercise sibling tools by focusing on user data, but lacks detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites, typical scenarios, or exclusions, leaving the agent without direction on selecting it.
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, the description carries full responsibility for disclosing behavior. It only implies a write operation ('Create') but provides no details about validation, duplicate handling, required permissions, or return values. The word 'new' suggests an add, but nothing more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified to the point of being unhelpful. It omits all contextual and parameter information, so this is not genuine conciseness but rather vague brevity.
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 tool's complexity (a nested parameter, no annotations, no output schema) and the existence of sibling tools, the description is severely incomplete. It fails to explain what the 'exercise' object requires, what the tool returns, or any behavioral side effects, making it inadequate for an AI agent to correctly use the tool.
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%; the description does not mention the 'exercise' parameter or its nested object structure. The schema itself has rich enums and required fields, but the description adds no explanatory value, leaving the agent without guidance on constructing valid input.
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 'Create' and the resource 'custom exercise template', which distinguishes it from sibling tools like get_exercise_templates and delete_exercise_template. The phrasing 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states the purpose without mentioning exclusions, prerequisites, or relationships to other exercise template tools.
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 only says 'update' but doesn't disclose whether this is a full replacement, partial update, or what side effects occur. This is a meaningful gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified for a tool with a complex nested schema. This is not concise completeness; it is an absence of necessary detail.
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 high complexity, no annotations, no output schema, and a rich nested input schema, the one-sentence description is far from sufficient. It doesn't explain update semantics, required fields, or invocation context, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'workoutId' or the structure of the 'workout' object. It adds no meaning beyond the parameter names already present in the 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 states the action ('Update') and the target resource ('an existing workout'). The word 'existing' helps distinguish it from create_workout and get_single_workout, though it doesn't specify which fields can be updated.
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 phrase 'an existing workout' implies this tool is for modifying previously created workouts, but it does not explicitly contrast with create_workout or state when to prefer this over other tools. Usage guidance is only implied, not explicit.
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, the description carries the full burden of disclosing behavioral traits. It doesn't indicate whether the update is partial or full, what happens to omitted fields, authorization requirements, or any side effects. The nested schema implies a full replacement (title and exercises required), but that is not disclosed in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (six words) and front-loaded, which is efficient in terms of word count. However, it is under-specified: it doesn't include any info about the required routines object or the routineId, making it less useful than a slightly fuller but still concise 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 the complexity of the nested 'routine' parameter and the lack of output schema, the description is incomplete. It does not explain return values, full-vs-partial update semantics, or required field structure. The one-sentence description is not enough for an agent to correctly construct a valid update request.
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% because the description names no parameters. The two parameters (routineId and routine) are only defined in the schema, and the description adds no meaning beyond what the schema already provides. The schema itself is detailed, but the description fails to compensate for the lack of textual parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing routine' clearly states the action (update) and the resource (routine), and the context of sibling tools (create_routine, delete_routine, get_routines) makes the distinction apparent. However, it doesn't specify what aspects of the routine can be updated or whether it's a full replacement, which would make it even clearer.
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. It doesn't mention prerequisite conditions (e.g., needing an existing routine ID) or contrast with create_routine/delete_routine. The context of siblings is available but the description itself offers no usage direction.
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, the description must disclose behavioral traits. It merely says 'update', which implies mutation, but does not state whether the operation is destructive, whether the folder must exist, what happens if it does not, or any error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient in wording. However, it is under-specified and omits crucial context, so the brevity is not combined with useful content. It is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters, no output schema, and no annotations, the description carries the full burden of explaining the tool. It does not state how folderId is used, what title does, or what the agent can expect as a result. The description is too thin for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the parameters. The names 'folderId' and 'title' are somewhat self-explanatory (ID and new title), but the description does not confirm this mapping or provide any additional meaning beyond the schema's bare structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Update') and resource ('existing routine folder'), distinguishing it from sibling create/delete/get tools. However, it does not specify which fields can be updated, relying on the schema for that detail, so it is clear but not highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_routine_folder or delete_routine_folder. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent without decision support.
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 fully disclose behavior. It only states that it returns a paginated list, but does not explain the return structure, pagination details (e.g., defaults, max page size), or whether any side effects exist. For a read-only tool, this is thin but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's action and result. There is no redundant wording or filler, and every word contributes meaning. It is appropriately sized for a simple list operation.
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 simplicity of the tool (2 optional params, no output schema, no annotations), the description is minimal but leaves out important context such as the shape of the returned list, whether pagination is mandatory, and what fields each routine entry contains. It is not complete enough for an agent to use confidently without additional assumptions.
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 no descriptions, and the description does not explain their meaning beyond the word 'paginated'. With 0% schema coverage, the description fails to compensate by clarifying how these parameters control pagination, defaults, or 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 clearly states the verb 'Get' and the resource 'routines', and mentions 'paginated list', which distinguishes it from get_single_routine and get_routine_folders. However, it does not explicitly specify what scope of routines (e.g., all routines, user-specific), but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or explicit comparisons with sibling tools like get_single_routine or get_workouts. Users are left to infer usage from the tool name.
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, the description must carry the full burden of behavioral disclosure. It mentions pagination but does not describe response format, ordering, defaults, error behavior, or whether this is a read-only operation. The agent cannot anticipate what the tool returns or how pagination behaves.
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 is appropriately concise and easy to parse.
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?
Despite the tool's apparent simplicity, the lack of annotations, parameter descriptions, and output schema leaves significant gaps. The description does not specify what a routine folder is, what fields each item includes, or how pagination works. It feels incomplete for an agent to safely invoke and interpret results.
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 schema has 0% description coverage, and the description does not explain the parameters 'page' and 'pageSize' at all. The word 'paginated' only hints at their purpose, but there is no explicit mapping, type explanation, or format 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 clearly states the tool gets a paginated list of routine folders, using a specific verb and resource. It distinguishes from siblings like get_single_routine_folder (single item) and get_routines (routines, not folders).
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 get_routines or get_single_routine_folder. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action 'create' but does not disclose any side effects, permission requirements, or return behavior. The description adds no context beyond the obvious mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is direct and front-loaded. It is efficient and earns its place, though it is extremely brief and could be more informative without becoming verbose.
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), the description covers the core purpose. However, it lacks any context about the routine folder structure, prerequisites, or parameter semantics, leaving it merely adequate for a simple create operation.
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 one required 'title' string with 0% schema description coverage. The description does not mention 'title' at all, leaving the agent without any information about acceptable values, constraints, or how the title is used. The description fails to compensate for the lack of schema 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 uses a specific verb 'create' with a clear resource 'routine folder', distinguishing it from sibling tools like get_routine_folders, delete_routine_folder, and update_routine_folder. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for creating a routine folder but provides no explicit guidance on when to use it versus alternatives. No exclusions or alternative tools are mentioned, but the create operation is contextually clear.
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 of behavioral disclosure. It states that the routine is deleted but does not mention irreversibility, potential side effects (e.g., cascade deletion of associated exercises), or required permissions. For a destructive operation, this is a significant 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 a single concise sentence, front-loaded with the action and resource. There is no filler or redundant information, making it efficient and appropriately sized for the tool's simplicity.
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 delete operation with one parameter and no output schema, the description covers the core action. However, it lacks behavioral context such as permanence, error handling, or impacts on related data. Given the absence of annotations, more detail would be expected, but the current description is minimally adequate.
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 zero description coverage for 'routineId', and the description merely repeats the parameter name without adding meaning. It does not explain what the routineId represents, how to obtain it, or any format constraints. Thus, the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('routine'), and specifies the identifying parameter ('routineId'). This distinguishes it from sibling tools like delete_routine_folder or delete_workout, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or contexts. The description only states the action without explaining when it is appropriate or what other tools might be used instead (e.g., update_routine, get_routines).
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 must disclose destructive behavior. It only states 'Delete' without mentioning irreversibility, cascading deletes, or permission requirements. It adds no context beyond the tool name.
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 filler. Every word contributes to the core action, making it extremely concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description should explain consequences, success/failure behavior, or related effects. It provides only the bare action, leaving significant gaps for the agent.
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%. The description mentions 'by its folderId' but does not explain what folderId represents, how to obtain it, or its format. It essentially restates the schema field without adding meaningful detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and resource 'routine folder', with the identifier 'by its folderId'. This clearly distinguishes it from sibling tools like delete_routine and other folder operations.
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 used for deleting a routine folder, but provides no explicit when-to-use versus alternatives (e.g., delete_routine, archive) or prerequisites. No exclusions or context are given.
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 carry the full behavioral disclosure burden. It only states the basic action ('Get') and gives no information about read-only status, date range handling, pagination, or response format. The verb implies a read operation, but that 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to scan and front-loads the core action. There is no redundant information, and it earns its place despite being terse.
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 has three parameters and no output schema, the description is incomplete. It does not clarify what 'history' includes, how date filters affect results, or what data is returned, leaving substantial gaps for an agent invoking this 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 coverage is 0%, so the description must compensate for missing parameter details. It implicitly covers exerciseTemplateId but fails to mention start_date and end_date entirely, leaving their purpose and format unexplained. This is a significant gap for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves exercise history for a given template, using a specific verb ('Get') and resource ('exercise history'). It distinguishes from sibling tools like get_exercise_templates (list templates) and get_single_exercise_template (template details) by focusing on historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing past performance for a specific template, but offers no explicit guidance on when to prefer this over get_workouts or get_single_exercise_template. No alternatives or exclusions are mentioned, leaving context partially clear.
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 carries the full burden of disclosure. It only states the basic action and does not mention error handling (e.g., not found), return value format, or permissions. This is a simple get operation, but behavioral transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. It is front-loaded and immediately understandable, earning high marks for conciseness.
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 get-by-id tool, the description is minimally adequate. However, with no annotations, no output schema, and no mention of error cases or when to use it relative to sibling tools, it leaves notable gaps. It does not clarify what happens if the routine doesn't exist, which an agent may need to know.
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 'routineId' as a string with no description, so the description's 'by its Id' clarifies that this parameter is the identifier of the routine to fetch. However, it does not provide additional format details beyond what is already obvious, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a routine by its Id' uses a specific verb ('get'), a clear resource ('routine'), and a scope ('by its Id'), distinguishing it from the sibling 'get_routines' which presumably retrieves multiple routines. It is unambiguous and directly states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like 'get_routines' or other get_single_* tools. The implication of 'by its Id' is present, but there is no clear context, exclusion, or alternative naming.
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 must carry the behavioral disclosure burden. It does reveal that results are paged, filtered by a date, and contain updates/deletes. However, it does not explain pagination mechanics, date format, sorting, or the content of each event, leaving several behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the key action and resource. It is concise and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and zero schema description coverage, the description is insufficiently complete. It does not describe return values, pagination behavior, parameter formats, or the exact nature of workout events, making it inadequate for an agent to fully understand or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters (page, since, pageSize). The phrase 'since a given date' hints at the `since` parameter, but no format or semantics are provided, and page/pageSize are entirely undocumented. This leaves the agent without enough information to use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a paged list of workout events (updates or deletes) since a given date, using a specific verb and resource. This distinguishes it from siblings like get_workouts, which likely return workout records rather than change events.
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 retrieving change events rather than full workouts, but it does not explicitly compare with alternatives or state when to choose one over the other. There is clear context but no exclusions or explicit alternative guidance.
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 must disclose behavioral traits on its own. It only states 'Get a single exercise template by id' without mentioning error behavior (e.g., 404 if not found), return format, or authentication requirements. This is a minimal disclosure for a 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 sentence, front-loaded with the verb 'Get', and contains zero unnecessary words. It is appropriately sized for a tool with one simple parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description covers the core purpose and the identifier needed. However, it omits any mention of the return value or error scenarios, which would be helpful since there is no output schema. It is minimally viable but has gaps.
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 merely mirrors the parameter name exerciseTemplateId. It does not add any format, constraints, or examples 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 uses a specific verb 'Get' with a clear resource 'single exercise template' and the qualifier 'by id'. This distinguishes it from the sibling 'get_exercise_templates' (plural) and makes the tool's function immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'single' and 'by id' implies this tool is for fetching a specific template when you have its identifier, while the plural sibling is for listing. However, there is no explicit guidance on when to choose this over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Get' which implies read-only, but it does not disclose return format, error behavior (e.g., 404 vs null), or whether the full folder object is returned. This is minimal behavioral disclosure beyond the tool name.
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 six words, front-loaded with the verb and resource. There is no wasted wording or redundant information.
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 single-get tool, the description is acceptable but not complete. It lacks any indication of the return value or error conditions, which is important since there is no output schema or annotations to provide that 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%, so the description must compensate. It only says 'by id', which maps to folderId but provides no additional meaning (e.g., format, source, or uniqueness). This is very thin compensation for the lack of schema 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 action ('Get'), the resource ('routine folder'), and the scope ('single' and 'by id'). It distinguishes itself from sibling tools like get_routine_folders (plural) and get_single_routine (different resource).
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 folder ID and need a single folder, but it does not explicitly mention when not to use it or point to alternatives. The plural sibling get_routine_folders is an obvious alternative, but no direct guidance is provided.
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 of behavioral disclosure. It only says 'Delete', which implies destructive action, but it does not disclose whether the deletion is irreversible, whether it affects exercises referencing the template, or if any permissions are required. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It contains no unnecessary words and immediately communicates the core action and subject. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description provides the essential information needed to invoke the tool: what it deletes and how to identify the target. However, the lack of annotations and behavioral details (e.g., irreversibility, potential side effects) leaves the tool only minimally complete. It is adequate for basic usage but not robust.
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, exerciseTemplateId (string), with no description. The phrase 'by its id' clarifies that this parameter is the identifier of the exercise template, adding some meaning beyond the raw schema. However, it does not explain how to obtain the ID, whether it should be a UUID or any other format, or any validation rules. Given the schema coverage is 0%, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('custom exercise template'), and the identifier ('by its id'). This distinguishes it from sibling tools like get_exercise_templates and create_exercise_template, which are read and create operations.
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 a custom exercise template needs to be deleted, and that an ID is required. However, it does not explicitly state when to use it over alternatives, nor does it mention any prerequisites or exclusions. For example, it doesn't clarify whether this only works for user-created templates or if there are restrictions.
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, the description carries the full burden of disclosing behavioral traits. It fails to mention that deletion is permanent, any required permissions, or potential side effects (e.g., cascading deletes). The verb 'Delete' implies mutation, but the impact is left implicit.
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 redundant words. Every word earns its place, and the structure is 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?
Given the simple one-parameter schema and absence of output schema, the description provides a minimal viable baseline. However, it lacks important context such as irreversibility and any effect on related data, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and type (string) with 0% description coverage. The description adds meaning by specifying that 'workoutId' is the identifier used to delete the workout. For a single-parameter tool, this clarification is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('workout') plus the identifying parameter ('workoutId'). It clearly distinguishes from sibling tools like get_single_workout or update_workout, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, prerequisites, or consequences. The description simply asserts the action without any contextual usage notes.
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 burden. It discloses pagination behavior, which is useful, but does not mention whether the operation is read-only (inferred from 'Get'), any authentication requirements, side effects, or ordering. For a simple getter, the lack of explicit safety disclosure is a gap, though not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It front-loads the action and resource, and the pagination detail is relevant. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low in complexity (2 simple parameters, no output schema), and the description adequately conveys the basic function. However, since there is no output schema, the return format is not specified, and pagination details (e.g., default page size, response structure) are missing. This leaves some ambiguity for an agent selecting the 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 coverage is 0% and parameters have no descriptions. The names 'page' and 'pageSize' are somewhat self-explanatory, but the description only says 'paginated list' without explaining parameter meanings, defaults, or constraints. This 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 uses the specific verb 'Get' and resource 'exercise templates', clearly indicating this tool retrieves a collection. The word 'paginated' distinguishes it from get_single_exercise_template, and the tool name itself confirms the intent. This leaves no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a list of exercise templates is needed, and pagination hints at handling large collections. However, there is no explicit guidance on when to use this versus get_single_exercise_template, nor any mention of alternatives or exclusions. The context is clear but not explicitly differentiated.
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 burden of disclosing safety. The verb 'Get' implies a read-only operation, and 'complete details' indicates the return scope. However, it does not mention error behavior (e.g., invalid ID) or that the operation has no side effects, leaving some ambiguity.
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-formed sentence that immediately conveys the action and resource. It is front-loaded and has no superfluous words, making it highly efficient for an agent to parse.
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 get operation, the description is minimally adequate: it identifies the resource and parameter. However, it lacks context about the return structure, error cases, or relationship to sibling listing tools, and the absence of annotations and output schema increases the need for richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with 0% description coverage. The description merely names 'workoutId' without adding contextual meaning, such as its origin (e.g., from get_workouts) or format expectations. It offers minimal compensation, only implying it is the lookup key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'single workout's complete details' with a unique identifier. It distinguishes itself from sibling tools like get_workouts (which lists) and get_single_routine (different resource).
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 by the word 'single' versus the sibling get_workouts, but the description does not explicitly state when to choose this tool over alternatives or mention any exclusions. There is no guidance on prerequisites like where to obtain the workoutId.
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 of behavioral disclosure. It mentions pagination but does not cover authentication requirements, sorting, default page size, or response structure. This is a significant gap for a 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 conveys the core purpose efficiently and is appropriately sized for a simple list tool.
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 basic purpose but omits details about response format, default pagination behavior, and whether workouts are scoped to the current user. Given the lack of output schema and annotations, more contextual detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. The word 'paginated' hints that page and pageSize control pagination, but it does not specify their exact meaning, defaults, or boundaries. The minimal compensation keeps it at a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (Get) and resource (workouts), and adds the pagination detail, which distinguishes it from sibling tools like get_single_workout and get_workout_count. The verb-resource pair 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 use when a paginated list of workouts is needed, providing clear context. However, it does not explicitly mention alternatives or when not to use this tool, so it misses the highest level of 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 provided, so the description must carry the burden of behavioral disclosure. The verb 'get' and the phrase 'total number' imply a read-only operation, but the description does not explicitly state whether the tool has side effects, requires authentication, or has any performance implications. It is adequate but not rich in 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 that is front-loaded with the action and resource. It contains no unnecessary words 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 zero-parameter, simple count tool with no output schema, this description is complete. It clearly states what is returned (the total number of workouts) and the scope (on the account). Sibling tools provide alternative context, and no further details are necessary.
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 coverage is trivially 100%. The description adds some context by specifying the scope ('on the account'), which is meaningful beyond the empty schema. Per the baseline for zero-parameter tools, a score of 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 uses a specific verb and resource: 'Get the total number of workouts on the account.' It clearly distinguishes this from sibling tools like get_workouts (which likely lists workouts) by focusing on the count rather than the list itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_workouts or get_single_workout. The description simply states what the tool does without any context or exclusions.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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