hevy-mcp

Server Quality Checklist

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

Latest release: v1.23.3
Disambiguation5/5
Every tool targets a distinct resource and action, with clear list-vs-single patterns (e.g., get-workouts vs get-workout, get-routine-folders vs get-routine-folder). No two tools have overlapping purposes, and the descriptions make each tool's role unambiguous.
Naming Consistency5/5
All tool names follow a consistent verb-noun pattern using lowercase with hyphens (e.g., get-workout, create-routine, update-body-measurement). The naming is uniform across all resources (workouts, routines, exercises, body measurements, webhooks), making it predictable and easy to navigate.
Tool Count4/5
With 25 tools, the count is at the high boundary but justified by the breadth of the domain: workouts, routines, exercise templates, body measurements, and webhooks each need their own CRUD or query operations. Every tool serves a distinct purpose, so the count feels appropriate rather than bloated.
Completeness2/5
The toolset covers create, read, and update for most resources, but notably lacks delete operations for workouts, routines, routine folders, exercise templates, and body measurements. This creates dead ends (e.g., an agent cannot remove a workout or a routine), and some resources like exercise templates have no update capability. The gaps are significant enough to hinder common workflows.
Average 3.9/5 across 25 of 25 tools scored. Lowest: 3.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
- Last stable release on May 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the creation action without mentioning side effects, permission requirements, duplicate handling, or what the response contains, adding no meaningful behavior 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 or redundant information. It is appropriately concise for a simple create 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?
With no annotations, no output schema, and 0% schema description coverage, the description is too minimal. It does not explain optional parameters, enum semantics, return behavior, or how this create operation relates to sibling tools, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 should compensate, but it merely lists four of five parameter names (title, type, equipment, muscle groups) and omits the optional otherMuscles parameter. It does not explain the meaning of the exerciseType enum values or clarify required versus optional fields 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 ('Create') and resource ('custom exercise template') and lists the primary fields (title, type, equipment, muscle groups). This clearly identifies what the tool does and distinguishes it from sibling tools like get-exercise-templates or search-exercise-templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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-exercise-templates or create-workout. The agent must infer from the name alone that this is for creating templates, with no explicit context or exclusions.
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 of behavioral disclosure. It does mention that the tool returns full routine details including the new routine ID, and gives prerequisites. But it omits error conditions, permissions, or side effects beyond the obvious creation action. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of four short, information-dense sentences: the action, the core requirements, an optional parameter, and the return value. There is zero repetition or fluff, and the main purpose 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?
The tool has a complex nested schema for exercises with many fields and variants (warmup, dropset, repRange, weightKg, etc.). The description gives only high-level guidance and does not address these sub-parameters, nor does it describe the output schema in any detail. Given the complexity, the description is insufficient for an agent to correctly construct a valid request without additional inference.
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 needs to compensate. It does reference title, exercises, and folderId, indicating that title is required, exercises need sets, and folder is optional. However, it does not explain the notes parameter or the nested structure of exercises (e.g., exerciseTemplateId, sets fields, restSeconds, supersetId), leaving key parameter semantics 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 uses the specific verb 'create' with the resource 'workout routine' and clearly distinguishes from sibling tools like update-routine or get-routines. It also specifies the action scope ('in your Hevy account') and states the main outcome.
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 by stating requirements (title and at least one exercise with sets) and an optional folder assignment. However, it does not explicitly mention alternative tools for related operations (e.g., update-routine for modifications) or provide clear exclusions, so usage guidance remains 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 present, so the description carries the full burden of behavioral disclosure. It mentions the output fields (name, category, equipment, muscle groups, notes) but does not address error handling (e.g., not-found behavior), authentication requirements, or the read-only nature of the operation. For a tool with no structured safety hints, this leaves significant 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?
The description is a single, focused sentence (18 words) that front-loads the action and resource. It includes the key information—purpose, identifier, and return fields—without any unnecessary words or repetition.
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 covers the primary purpose and the key parameter, but it lacks usage alternatives and behavioral details such as not-found responses or output structure. Given the absence of annotations and an output schema, the description is minimally viable but not fully complete.
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 exerciseTemplateId as a non-empty string, and the description adds that the tool operates 'by its ID', which clarifies the parameter's role. However, no additional details such as ID format, example values, or any extra context are given, so the description only minimally compensates for the 0% schema description coverage.
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 complete details'), the resource ('specific exercise template'), and the mode ('by its ID'), while also listing the returned fields. This distinguishes it from sibling tools like get-exercise-templates (list) and search-exercise-templates, 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 description implies that the tool is used when a specific exercise template ID is known, but it does not explicitly mention when to prefer it over alternatives like get-exercise-templates or search-exercise-templates. No exclusions or alternative references are provided, so the usage guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the tool returns the updated routine and can modify title, notes, and exercise configurations, but does not clarify whether it performs partial or full updates, whether routineId must exist, or any side effects. This leaves important behavioral aspects ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds value. It is efficiently structured and free of unnecessary detail.
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's complexity (4 params, a nested exercises array) and lack of output schema or annotations, the description is incomplete. It does not explain the exercise configuration structure, whether updates are partial or full, or any required prerequisites. The return behavior is mentioned, but other critical context for invoking the tool correctly is missing.
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 by explaining parameter meanings. It mentions 'title, notes, and exercise configurations' which maps to the title, notes, and exercises parameters, but does not explain their structure, constraints, or optionality. The routineId is implied by 'by ID' but not explicitly described. This is insufficient given the complex exercises array.
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 updates an existing routine by ID, which is a specific verb+resource combination. It distinguishes from sibling tools like create-routine and get-routine by focusing on modifying existing routines and listing the modifiable aspects (title, notes, exercise configurations).
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 an existing routine ID and want to modify it, but does not explicitly state when to use this tool versus alternatives like create-routine or update-workout. It lacks exclusions or specific context cues that would fully guide the agent.
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 discloses that the updated workout is returned, but does not clarify whether the update is partial or a full replacement, what happens to omitted exercise data, or any side effects. The phrasing 'You can modify...' implies optionality that conflicts with required schema fields.
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 action and resource, with no redundant content. It efficiently communicates the key aspects without unnecessary verbosity.
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?
The tool is complex (7 parameters, nested exercise array, no annotations, no output schema), but the description is only two sentences. It does not mention required parameters, the structure of exercises, or behavior for omitted fields, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameter names in natural language (title, description, times, privacy, exercise data) but provides no context about required status, formats, or the structure of exercise data. This is insufficient for correct parameter construction.
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 ('Update an existing workout by ID') and specifies the modifiable fields (title, description, start/end times, privacy, exercise data). It distinguishes from sibling tools like create-workout and get-workout by emphasizing 'existing' and 'by ID.'
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 makes it clear the tool is for modifying existing workouts, not creating or retrieving. However, it does not explicitly state exclusions or alternatives, relying on the obvious contrast with create-workout and get-workout.
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 burden. It discloses that the operation is a read ('Get'), scoped to the authenticated user, and paginated. However, it does not mention potential side effects (likely none), ordering, 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 a single, clear sentence that front-loads the purpose and includes the key return fields. No redundant or extraneous information is present.
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 with no output schema, the description covers the main content (weight, body fat, circumference) and pagination, but it is missing details about parameter usage and response structure. It is adequate but not fully 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?
The schema has 0% description coverage, and the description only says 'paginated' without explaining page or pageSize. It does not elaborate on defaults, maximums, or the meaning of each parameter, so the agent must infer from the schema alone.
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 identifies the action ('Get') and resource ('body measurements'), and specifies scope as 'paginated list' and 'for the authenticated user'. This distinguishes it from the singular sibling 'get-body-measurement'.
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 'paginated list' implies use when multiple measurements are needed, but the description does not explicitly mention alternatives or when to use this tool versus get-body-measurement. No exclusions or prerequisites are stated.
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 burden of behavioral disclosure. It adds meaningful context: returns a paginated list, includes both default and custom templates, and lists the fields (name, category, equipment, muscle groups). It does not detail response format or edge cases, but for a simple read-only list tool, it covers the key behavioral aspects adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function in the first sentence and a brief use case in the second. Every sentence earns its place with no redundant filler or 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 simple paginated list tool with two self-explanatory parameters and no output schema, the description provides sufficient context: what is returned, the pagination feature, and the included fields. It does not mention authentication or error possibilities, but given the tool's simplicity and the richness of the schema, the description is largely complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not directly explain the page or pageSize parameters. It only hints at pagination via the word 'paginated,' which is insufficient to compensate for the lack of parameter info. The schema itself defines them clearly, but the description adds almost no semantic value for the parameters.
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 tool 'Get a paginated list of exercise templates' with specifics like default/custom and included details (name, category, equipment, muscle groups). It distinguishes from get-exercise-template (singular) by emphasizing the list/pagination aspect, though it also mentions 'searching' which overlaps with the sibling search-exercise-templates tool, slightly blurring differentiation.
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 a general use case ('browsing or searching available exercises') but does not explicitly state when to prefer this over alternatives like search-exercise-templates or how pagination should be used. It implies usage context but lacks concrete guidance on trade-offs or alternatives.
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 burden. It does disclose that the response is paginated and includes both default and custom folders, which is useful behavioral context. However, it omits other behavioral traits such as authentication needs, error handling, or pagination metadata format. It adds some value beyond the tool name but is 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 two sentences with no filler. It front-loads the core action ('Get a paginated list...') and adds a brief use case. Every sentence earns its place, making it appropriately concise and well-structured.
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 the basic return type ('list of your routine folders') and mentions pagination. However, with no output schema and no annotation, it should ideally describe the response structure or parameter effects. The absence of parameter explanations and any mention of response shape (e.g., whether it includes total count) leaves notable 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?
The input schema has two parameters (page, pageSize) with defaults and bounds, but schema description coverage is 0% and the description never mentions them. The word 'paginated' hints at the presence of pagination controls but does not explain which parameter controls what. The description clearly fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a 'paginated list of your routine folders' and specifies scope by 'including both default and custom folders.' This specific verb+resource combination distinguishes it from sibling tools like get-routine-folder (singular) and get-routines (list of 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a general use case ('useful for organizing and browsing your workout routines') but does not explicitly state when to use this tool versus alternatives like get-routine-folder or get-routines. There are no exclusions or alternative tool names, so the usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 adds useful details like the webhook receiving POST requests and the 5-second response requirement, but omits information about what happens on duplicate subscriptions, whether the subscription is immediately active, or the response format/return value. This is a partial 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 three sentences, each earning its place: the core action, the event trigger, and a critical endpoint requirement. It is front-loaded with the purpose and free of 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 has no output schema and no annotations, so the description needs to explain return values and side effects. It covers the endpoint behavior but does not mention what the response contains (e.g., subscription ID), permissions needed, or how to manage existing subscriptions. For a create operation with 2 parameters and straightforward behavior, this is a middle ground.
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 100% parameter description coverage for both 'url' and 'authToken', so the baseline is 3. The description does not add meaning beyond the schema, but it reinforces the URL's behavior via the 200 OK requirement. No additional parameter semantics are provided.
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 ('webhook subscription'), and adds specific context about the webhook receiving POST requests for workout creation events. This distinguishes it from sibling tools like get-webhook-subscription and delete-webhook-subscription.
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 use case (to receive notifications when workouts are created) but does not explicitly state when to use it versus alternatives or any exclusions. It provides context but no explicit selection 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, the description bears the full burden of behavioral disclosure. It reveals the return content (including exercise data) and implies read-only via the verb 'Get', but it does not mention error behavior, authorization requirements, or the absence of side effects. This is adequate for a simple get but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and resource, and every word contributes. It avoids redundancy and is highly scannable.
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 a single parameter, no output schema, and standard get semantics, the description covers the key return fields. It lacks only minor details like not-found handling or how to obtain an ID, but overall it provides enough context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'by ID', adding no format, example, or context for the workoutId parameter. It merely restates the property name without helping the agent understand what value to pass or where to obtain it.
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 complete details of a specific workout by ID, distinguishing it from siblings like get-workouts (list) and get-workout-count. It enumerates the response fields (title, description, times, exercise data), making the purpose 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 phrase 'by ID' implies use when you have a workout ID, but no explicit guidance is given on when to choose this tool over alternatives. It does not mention that get-workouts should be used for listing, nor does it state any exclusions or prerequisites.
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 burden of behavioral disclosure. It states the required input and return value including the new folder ID, but does not mention error conditions, permissions, or side effects beyond creation. For a simple create tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with three short sentences that front-load the main action and then provide necessary details. There is no wasted wording 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?
For a simple create tool with no output schema, the description covers the purpose, required parameter, and return value. It lacks edge-case or error behavior, but that is less critical for such a straightforward operation.
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 for the 'name' parameter. The description mentions 'Requires a name for the folder,' which clarifies the parameter's role, but it does not add depth such as uniqueness, length constraints, or examples. It only partially compensates for the low coverage.
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 creates a new routine folder, using a specific verb and resource. It distinguishes itself from sibling tools like get-routine-folders by indicating a create operation, and there is no alternative creation tool for folders.
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 new routine folder is needed but does not explicitly state when to use it over alternatives or provide exclusions. No comparison with get-routine-folder or get-routine-folders is given, so 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly mentions pagination and includes custom/default routines, but omits response shape, ordering, or authentication needs. Adequate but not comprehensive.
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 action and resource, with no filler. Every phrase ('paginated list', 'custom and default routines', 'browsing or searching') adds useful context.
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 covers purpose and pagination but does not explain what fields each routine includes or the behavior of the pagination parameters, leaving some gaps for an 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%, so the description must compensate by explaining parameters. It only says 'paginated list' and never mentions page or pageSize, their defaults, or constraints, adding no value beyond the raw schema properties.
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 it gets a paginated list of workout routines, including custom and default routines. This specific verb+resource combination distinguishes it from siblings like get-routine (singular) and get-routine-folders.
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 browsing or searching your available routines' gives clear usage context. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for a list endpoint.
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 burden of behavioral disclosure. It does disclose the return behavior (complete workout details with new ID) and hints at validation requirements, but it doesn't mention potential failure modes, side effects, or authentication needs. For a mutation tool, this is acceptable but not fully transparent.
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 concise sentences with the purpose front-loaded. Each sentence adds critical information: what the tool does, required inputs, and return value. There is no redundant or filler content.
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 complexity (6 parameters, nested exercise structure) and lack of output schema/annotations, the description provides a solid foundation by stating the required inputs and return behavior. It doesn't fully describe nested structure, but the schema supplies the detailed types, so the description is sufficient for an agent to correctly invoke the 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 has 0% description coverage, so the description must compensate. It adds meaning by specifying that start/end times are required and that exercises must include sets, which clarifies the nested exercises structure. However, it doesn't explain optional parameters like isPrivate or description, nor the detailed exercise fields, so it only partially compensates for the schema's lack of 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 ('Create a new workout') and the resource ('in your Hevy account'), making the purpose unambiguous. It also differentiates from sibling tools like update-workout by explicitly saying 'new workout' and mentioning the return of a newly assigned workout ID.
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 the tool by listing required parameters (title, start/end times, at least one exercise with sets), which implies the tool is for creating workouts with those constraints. It doesn't explicitly mention alternatives, but the purpose is distinct enough from sibling tools that an agent can infer usage.
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 transparency burden. It discloses that the tool returns all measurement fields for the date, which is useful. However, it does not mention error handling, permissions, or explicitly state that it is read-only (though the verb 'get' implies this). For a simple read operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the action and then explains the return value, making it efficient 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 single-parameter tool with no output schema, the description adequately states the purpose and return type ('all measurement fields'). It could benefit from mentioning the sibling tool for multiple measurements, but that is not essential for the tool's use. Overall, it is sufficiently complete.
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 already fully documents the single 'date' parameter with its format and description, so the baseline is 3. The description's phrase 'by date' aligns with the parameter but adds no additional semantic detail 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 'Get a single body measurement by date', which specifies the verb (get), resource (body measurement), and scope (single, by date). This distinguishes it from the sibling tool 'get-body-measurements' (plural) which presumably returns multiple measurements.
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: use this tool when you need a single body measurement for a specific date. It does not explicitly name alternatives or exclusions, but the word 'single' implies it is not for listing measurements, which is covered by the plural sibling.
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 must communicate behavioral traits. It conveys a read-only operation through 'get' and discloses optional date filtering, but it omits details such as authentication needs, rate limits, pagination, or the exact format of the returned sets. This is a moderate level of transparency for a simple getter.
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 14 words, front-loading the primary action and resource while introducing the optional filters without unnecessary elaboration. Every part contributes to understanding the tool's function.
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 3-parameter read tool with no output schema, the description gives adequate context: it states what is returned (past sets) and the optional filter dimensions. It could mention date inclusivity or ordering, but these are not critical given the tool's straightforward nature.
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 description coverage is 67%, with startDate and endDate having descriptions but exerciseTemplateId lacking one. The description compensates by clarifying that the operation targets a specific exercise template (exerciseTemplateId) and that date filters are optional, adding meaning beyond the schema fields.
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 'Get past sets for a specific exercise template' with a specific verb, resource, and qualifier. It distinguishes itself from sibling tools like get-workout, get-exercise-template, and search-exercise-templates by focusing on historical sets for a known template.
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 when retrieving an exercise template's past sets and mentions optional date filters, but it does not explicitly state when to choose this tool over alternatives or provide any exclusions. Contextual insight from sibling tools is available, but the description itself offers no direct comparison.
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 must carry the full burden of behavioral transparency. It states that it returns complete details and lists relevant fields, which implies a read-only operation. However, it does not disclose any error behavior (e.g., 404 for not found), pagination, or other consequences. This is adequate but with clear gaps, so a 3.
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 immediately states the action ('Get complete details of a specific routine folder by its ID') followed by the included data. Every word earns its place, and there is no redundancy or filler. Excellent conciseness and structure.
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 nested objects, no output schema), the description is reasonably complete. It tells the agent what to pass (folderId) and what to expect (name, creation date, associated routines). It lacks detail on error responses or exact response structure, but the absence of an output schema makes the return-value disclosure more important. Minor gaps exist, but overall it is adequate for a simple getter.
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 no per-parameter descriptions (0% coverage), so the description must compensate. It mentions 'by its ID' which clarifies that folderId is the identifier, but this adds minimal meaning beyond the parameter name itself. The parameter is simple and self-explanatory, but the description does not provide examples, format constraints, or additional semantics beyond what the schema already conveys. Thus a baseline 3 is fair.
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') and resource ('routine folder') with clear scope ('by its ID'), and distinguishes itself from the sibling tool 'get-routine-folders' (plural) by focusing on a single folder. It also lists the key data returned (name, creation date, associated routines), fully clarifying the 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 clearly implies when to use this tool: when you need details of one specific routine folder given its ID. It does not explicitly name alternatives or exclusions, but the context supplied by sibling tools (e.g., get-routine-folders for listing) makes the intended usage obvious. Clear context, no exclusions, so a 4 is appropriate.
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 discloses return fields, pagination, and ordering, but does not mention potential errors, rate limits, authentication requirements, or edge cases such as empty results.
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 deliver the core purpose, return fields, and ordering with no redundant information. The action is front-loaded.
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 list operation, the description covers the key aspects: pagination, return fields, and ordering. However, it lacks guidance on alternative usage scenarios and error conditions, though these are less critical given 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 pagination and ordering, but does not explicitly explain the meaning of 'page' or 'pageSize' beyond their names; the schema provides defaults and constraints, but the description adds little detail about how these parameters affect results.
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 targets 'a paginated list of workouts,' clearly distinguishing it from singular get-workout and get-workout-count siblings. It also lists the returned fields and ordering, making it 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?
Provides clear context as a paginated list operation, implying it is for bulk retrieval versus single-item alternatives. However, it does not explicitly state when not to use it or name alternative tools, lacking explicit exclusions.
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 discloses the key consequence ('This will stop all webhook notifications'), which adds useful behavioral transparency. However, it does not mention irreversibility, authentication requirements, or behavior when no subscription exists. 'Delete' already implies destruction, so this is minimally 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 two short sentences that front-load the action ('Delete the current webhook subscription') and then immediately state the consequence. Every word earns its place; no fluff or 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?
For a simple 0-parameter delete tool with no output schema, the description covers the purpose and the primary behavioral effect. It lacks details about error cases, irreversibility, or return values, but these are not strictly necessary for such a straightforward tool. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description need not explain parameter semantics. The baseline for 0 params is 4, and there is nothing to add.
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: 'Delete the current webhook subscription for this account.' This uses a specific verb and resource, and the scope ('for this account') is explicit. It distinguishes itself from sibling tools like get-webhook-subscription and create-webhook-subscription.
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 the tool: to remove an existing subscription and stop notifications. While it does not explicitly mention alternatives or exclusions, the context is sufficient for an agent to understand this is for deletion rather than retrieval or creation.
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 burden of behavioral disclosure. It does state 'Returns all details,' which gives some information about the response. However, it does not mention potential errors, authorization requirements, or side effects, leaving gaps for a tool with no annotation coverage.
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 that front-load the purpose and resource. It is efficient with no redundant phrasing, earning a high score for brevity.
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 one-parameter retrieval tool, the description covers the core purpose and return value. It does not delve into error handling or edge cases, but given the simplicity and lack of an output schema, the description is reasonably 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 input schema only lists 'routineId' without any description. The description compensates by explaining that the ID identifies the specific routine to fetch ('by its ID'), providing the necessary semantic meaning for the single parameter.
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 a specific verb and resource: 'Get a routine by its ID' and specifies the return value ('Returns all details'). This distinguishes it from siblings like get-routines (likely a list operation) and get-routine-folders.
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 indicates when to use the tool: when you have a specific routine ID and need its full details. It provides clear context, though it does not explicitly mention alternatives or exclusions, such as using get-routines for listing.
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 burden of behavioral disclosure. It discloses the conditional behavior ('if a subscription exists') and the return contents (URL and auth token). However, it does not specify what happens when no subscription exists (e.g., returns null, empty object, or 404) or any potential side effects, error conditions, or sensitivity of the auth token. This is adequate but has clear gaps for a no-annotation scenario.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action ('Get the current webhook subscription'), followed by a concise explanation of the return value and condition. Every sentence earns its place with no redundant information or fluff.
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 has no parameters, no annotations, and no output schema, the description provides necessary context: what it does, the account scope, and what it returns conditionally. It mentions 'if a subscription exists', which implies handling of the absence case, though it could be more explicit about the no-subscription outcome. Overall, it is sufficiently complete for a simple getter 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 input schema is empty (0 parameters), and the description correctly does not attempt to describe parameters. According to the rubric, 0 parameters has a baseline of 4, and there is no additional semantic burden. The description focuses on the operation and return values, which 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 action: 'Get the current webhook subscription for this account.' It specifies the resource (webhook subscription) and its scope (this account), and differentiates from sibling tools like create-webhook-subscription and delete-webhook-subscription by focusing on retrieval. Additionally, it mentions what is returned (URL and auth token), further clarifying the 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 provides clear context: it is for retrieving the current webhook subscription and explicitly notes the conditional return ('if a subscription exists'). While it does not name alternatives or state when not to use it, the sibling tool list makes the distinction obvious (create/delete vs. get). This is clear context without explicit exclusions, aligning with a score of 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 burden. It clearly implies a read-only operation (get) and a simple aggregate result, but does not detail the return format (e.g., integer vs. object), potential performance implications, or scope limitations beyond 'on the account'. Minimal 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?
Two short sentences with no fluff. First sentence states the action; second provides rationale for use. 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 simple no-parameter count tool, the description is largely complete: it tells what it does and why. The only gap is not explicitly stating the return type (a number), but 'total number' reasonably implies that. Given no output schema or annotations, a modest addition like 'Returns an integer' would make it fully 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 tool has zero parameters, and the schema fully documents that. The description adds meaning by clarifying the scope is the entire account ('on the account'), which is useful context that the empty schema cannot convey. Baseline for 0 params is 4, and this description does not diminish it.
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?
States the exact function: getting a total count of workouts for the account. The verb 'Get' and resource 'total number of workouts' are specific, and it clearly distinguishes from sibling tools like get-workouts (which returns a list) and get-workout (which returns a single item).
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?
Provides clear use cases ('Useful for pagination or statistics') indicating when to invoke this tool. It does not explicitly name alternatives, but the context of counting vs. fetching implies the appropriate selection among siblings.
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 important behavioral details: the first call fetches all templates from the API, results are cached in memory, and refresh:true busts the cache. This gives the agent a clear picture of side effects and performance implications. It could mention rate limits or response format, but the caching behavior is a significant 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?
Two sentences, front-loaded with the purpose, followed by caching behavior and usage note. Every sentence earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with caching and refresh. The description covers core usage and behavior well. However, it omits details about the return value format or pagination, which would be useful given there is no output schema. Still, the description is mostly complete for a search 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?
Schema coverage is 100%, with each parameter already described in the schema. The description adds minimal extra meaning beyond the schema, primarily reinforcing the refresh behavior and the optional filter. It does not add syntax or format details beyond the schema, so baseline 3 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 ('Search') with a clear resource ('exercise templates') and scope ('by name with optional muscle group filter'). This distinguishes it from sibling tools like get-exercise-templates, which likely lists all templates rather than searching with a filter.
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?
It clearly states the tool is for searching by name with an optional filter, and gives explicit guidance on using refresh:true to force a re-fetch. However, it does not explicitly compare to alternatives like get-exercise-templates or state when not to use this tool.
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 burden. It discloses that events are ordered newest-to-oldest, are limited to updates/deletes since a given date, and are paged. It also states the intended caching use case, providing useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loads the action and then adds purpose. 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 relatively simple, and the description covers purpose, ordering, event type, and use case. However, since there is no output schema, the description should also explain the structure of the returned events (e.g., fields per event) to fully enable the agent to use the data. This gap prevents a higher score.
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 descriptions are absent (0% coverage), so the description must explain parameters. 'since a given date' directly maps to the 'since' parameter, and 'paged list' implies page/pageSize usage. However, it doesn't detail parameter formats or default behavior beyond what's in 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 tool retrieves a paged list of workout events (updates or deletes) since a date, distinguishing it from get-workouts which would return the full workout list. The intentional mention of cache synchronization adds purpose specificity.
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 explains the use case: keeping a local cache up to date without fetching the entire list of workouts. This implies when to use this tool over get-workouts, though it doesn't explicitly name alternative tools or exclusion criteria.
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 burden of explaining behavior. It discloses the key 409 conflict behavior and optional field semantics. It stops short of mentioning authentication, success response shape, or idempotency, but the core mutation behavior and conflict handling are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes the most important behavioral caveat. Every sentence earns its place; there is no extraneous detail.
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 18 parameters, no output schema, and no annotations, the description covers the essential creation semantics, optionality, and conflict behavior. The only meaningful gap is the lack of success response details, but the rich parameter schema offsets much of the complexity.
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 provides 100% coverage, with every parameter having a clear description and unit. The description adds little beyond the schema: it repeats that fields are optional and emphasizes the date uniqueness constraint, which is already in the date parameter description. Baseline 3 is appropriate given the schema's strong coverage.
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: 'Create a body measurement entry for a given date.' The verb 'Create' and resource are specific, and it distinguishes itself from the sibling tool 'update-body-measurement' by explicitly noting the 409 conflict and suggesting the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Returns 409 if an entry already exists for that date — use update-body-measurement instead.' This tells the agent when not to use this tool and names the correct alternative. It also clarifies that all measurement fields are optional, informing how to construct calls.
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 critical behavioral traits: all fields are overwritten, omitted fields are set to null, and returns 404 for missing dates. This goes beyond simple 'update' semantics and helps the agent understand the destructive nature of omitting parameters. However, it does not mention permissions, rate limits, or the success response shape, so slightly less than perfect.
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 that front-load the purpose ('Update an existing body measurement entry for a given date') followed by the two essential behavioral caveats. Every word earns its place, with no redundancy or fluff.
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 18 parameters, no annotations, and no output schema, the description covers the most critical operational details: overwrite semantics, null-filling, and 404 behavior. It does not describe the success return value or any prerequisites, but the schema handles parameter meanings and the description clarifies the update semantics, making it largely 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 full coverage with descriptions for all 18 parameters (units in cm, kg, etc.), so the baseline is 3. The description adds important parameter behavior: omitted fields are set to null, which is not visible in the schema. This clarifies that updating with a subset of fields will erase unmentioned ones, adding 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 'Update an existing body measurement entry for a given date', specifying the action (update), the resource (body measurement entry), and the key parameter (date). It also distinguishes itself from sibling tools like create-body-measurement and get-body-measurement by emphasizing 'existing' and the 404 behavior for missing entries.
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: this tool updates an existing entry, and if no entry exists for the date, it returns 404. This implies it is not for creating new entries, but it does not explicitly name alternatives like creating a new measurement. The conditionality is clear enough for an agent to decide when to use it.
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/rwestergren/hevy-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rwestergren/hevy-mcp)

Score Badge

Copy to your README.md:

[![hevy-mcp MCP server](https://glama.ai/mcp/servers/rwestergren/hevy-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rwestergren/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/rwestergren/hevy-mcp'

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