TrainHeroic

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resource+action pairs. A few exercise performance tools (get_exercise_stats, get_personal_records, get_working_max) overlap in information returned, but descriptions clarify their specific scopes. Overall, agents can reliably select the right tool.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern with get_ prefix for reads and action verbs for mutations. A minor inconsistency exists between 'session' and 'workout' terminology (create_personal_session vs log_workout), and some nouns are singular vs plural, but the pattern is predictable and consistent in style.
Tool Count4/5
20 tools is on the heavier side but each covers a distinct aspect of the training domain: user/team info, session management, workout logging, surveys, messaging, leaderboards, and exercise data. No tool feels redundant, though the count could be trimmed by merging some exercise stat tools.
Completeness3/5
Core session lifecycle (create, add exercises, log, delete) is covered, along with history, details, surveys, and leaderboards. Notable gaps include no update/remove exercises from a session, no upcoming workout schedule, and circuits cannot be added to sessions despite having a library. These are working gaps agents may need to work around.
Average 3.8/5 across 20 of 20 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses useful behavioral details: optional case-insensitive substring filtering via 'query' and the returned exercise fields. However, it does not clarify how team_id is used, whether team_id is required, or any pagination/ordering behavior, leaving gaps in behavioral understanding.
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 main purpose, the optional filter behavior, and the return structure. It is front-loaded with the action and resource, and contains no redundant or verbose phrasing.
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 and two optional parameters, the description provides the essential return fields and filter semantics. However, it lacks explanation of team_id's role, which is a key parameter, and provides no usage guidance relative to sibling tools, leaving some contextual 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 0% description coverage, so the description must compensate. It explicitly explains the 'query' parameter as a case-insensitive substring match on name, which is valuable. However, 'team_id' is not described: its meaning is only hinted by 'for a team', and its optionality and default behavior are unclear.
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 'full exercise library' with scope 'for a team', making the purpose specific. It implicitly differentiates from siblings like get_exercise_detail and get_circuit_library through the term 'exercise library' and 'full', but does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like get_exercise_detail or get_recent_exercises. It implies usage when the full library is needed, but there is no mention of exclusions, prerequisites, or when to choose a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implicitly indicates a read operation through 'Get', and it does reveal the return structure ({workoutId, workoutTitle, date, tests, results, testStats, userResult}), which is useful. However, it does not explicitly state read-only safety, authentication needs, error behavior, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the first stating the purpose and the second listing the return fields. Every word earns its place, and the most important information is front-loaded. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema) the description covers the basic purpose and return format. However, it omits any behavioral context such as whether filtering or ordering is available, whether the original workout ID is required, or any error conditions. It is minimally complete but leaves gaps that could be filled with a bit more 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 (program_workout_id) with zero description coverage, and the tool description adds little beyond 'a specific program workout'. The parameter name is self-explanatory, but the description does not explain how to obtain the ID, any constraints (e.g., integer range), or the meaning of the ID in context, so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the leaderboard for a specific program workout.' It clearly identifies the tool's function and distinguishes it from sibling tools like get_user_profile or get_team_info, though it does not explicitly discuss alternatives or differentiators within the description 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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about how the leaderboard might be accessed in a workflow. There is no mention of exclusions or when-not conditions, leaving the agent without direction on appropriate usage.
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 full burden. It only states 'Delete', which is already implied by the name. It does not disclose whether deletion is permanent or soft, any side effects on related data, or required permissions. For a mutation tool, this is insufficient.
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 unnecessary words, achieving maximum conciseness while covering the essential purpose.
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 simple delete tool, the description is minimal. It omits behavioral details like reversibility, side effects, and return values. The ambiguity between 'program workout' and 'personal session' is not addressed, despite the parameter name only referencing 'program_workout_id'. Overall, an agent would struggle to know if this is a hard delete or if there are any conditions.
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 only parameter 'program_workout_id' has no description in the schema, so the description must compensate. It says 'by its ID', which indicates the parameter is the identifier, but it does not clarify the distinction between 'program workout' and 'personal session', nor does it specify the ID format 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 verb 'Delete' and the resource 'program workout / personal session', with the method 'by its ID'. It distinguishes from sibling tools like create_personal_session and log_workout by indicating a destructive operation.
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 does not provide any guidance on when to use this tool vs alternatives, when not to use it, or prerequisites such as ownership or permissions. There is no mention of conditions for deletion or any caution about irreversibility.
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 itself. It only lists return fields but does not state read-only nature, auth requirements, or behavior when team_id is null. This leaves significant gaps in expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and includes a concise list of return fields. Every sentence earns its place with no superfluous detail.
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 read tool with one optional parameter and no output schema, the description is adequate but incomplete. It covers the resource shape but omits parameter behavior and usage context, leaving some ambiguity.
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 explain the team_id parameter. It only says 'for a team' but does not clarify that team_id is optional, what null means, or how it filters results. The parameter semantics remain ambiguous.
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 identifies the resource as 'circuit library for a team', which clearly distinguishes it from sibling tools like get_exercise_library or get_recent_circuits. The additional field list clarifies the scope further.
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 provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios or exclusions, unlike more helpful descriptions that reference sibling tools.
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?
Despite the absence of annotations, the description discloses behavioral details by specifying the response fields (isLift, lastPerformance, personalRecord, workingMax) and the default behavior of stat_date (defaults to today, format YYYY-MM-DD). However, it does not explicitly state that this is a read-only operation or explain edge cases, but it adds meaningful 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?
The description is concise and well-structured: two sentences, front-loaded with the purpose and followed by essential parameter and response details. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key aspects: purpose, parameter format, and response structure. However, it lacks definitions of what personalRecord and workingMax represent (e.g., all-time vs. current), and it remains ambiguous how this tool relates to specialized siblings. With no annotations and no output schema, these gaps leave moderate ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful context for stat_date, specifying format and default behavior, which the schema omits (schema default is null). However, it provides no additional meaning for exercise_id beyond its schema type and requirement, and with 0% schema coverage, more compensation would be expected.
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's main function: obtaining stats for an exercise, specifically last performance, personal record, and working max. This is a specific verb and resource, but it does not explicitly differentiate from sibling tools like get_personal_records or get_working_max, leaving some ambiguity about selection.
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 provides no guidance on when to use this tool versus related tools such as get_personal_records or get_working_max. It offers no alternatives or exclusions, leaving the agent to infer usage context.
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 provides some transparency by listing the fields returned (reps, weight, scaledWeight, units, setNumber), which tells the agent what to expect. However, it doesn't discuss ordering, pagination, or what qualifies as a 'personal record,' nor any potential failure modes.
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, no irrelevant detail, and the key information is front-loaded. Perfectly concise.
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 retrieval tool with one parameter and no output schema, the description covers the main return fields and the purpose. It doesn't describe response structure (array vs object) or error handling, but for this low-complexity tool, it is relatively 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 single parameter exercise_id is only named in the schema without description, and the tool description does not explicitly define it beyond 'for an exercise.' The name is self-explanatory, but at 0% schema coverage, the description should have explicitly stated it takes the exercise ID to retrieve records for, which it does only implicitly.
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 retrieves all personal records for an exercise, specifically broken down by rep count. This is more specific than merely saying 'get records' and distinguishes it from generic stats tools. However, it doesn't explicitly contrast with siblings like get_exercise_stats or get_working_max.
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 given on when to use this tool versus alternatives. The description only states what it does, not when it should be selected over sibling tools like get_exercise_stats or get_working_max. There are no usage caveats 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?
The description discloses the return structure ({value, hasReferenceMaxExercise, referenceMaxExercise}), which adds behavioral insight beyond the empty annotations. However, it does not explain the meaning of these fields, nor does it mention whether the operation is read-only, has any side effects, or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first states the purpose, and the second gives the response shape. There is no fluff or redundant wording.
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 getter, the description provides the core purpose and return format, which is helpful. However, it lacks usage context, parameter explanation, and any caveats about behavior. Given no annotations and no output schema, it 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining the exercise_id parameter. It only says 'for a specific exercise,' which essentially restates the parameter name. It does not clarify what a working max is, how to find the exercise_id, or any constraints.
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 ('current working max') with a clear scope ('for a specific exercise'). It clearly distinguishes this from sibling tools like get_personal_records or get_exercise_stats, which cover different concepts.
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 does not mention any exclusions, prerequisites, or when a different tool would be more appropriate. The sibling tools are not referenced or contrasted.
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 exist, so the description must disclose behavioral traits. It only states the basic action and says nothing about side effects, persistence, idempotency, or side effects of logging. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the purpose, and then efficiently lists parameters in a structured way. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description only partially completes the picture. It lacks usage context, return behavior, and potential side effects. Missing parameter explanations and no guidance on response format make it incomplete for an agent to fully trust.
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 has zero descriptions, so the description compensates by explaining 6 of 8 parameters with clear meanings. However it omits notes and is_personal_calendar, leaving a gap. Still, the provided explanations add real value.
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?
Description clearly states 'Save/log a completed workout with results' – a specific verb and resource, distinguishing it from planning/session-creation tools. It directly conveys the tool's core function without ambiguity.
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 on when to use this vs alternatives. The only hint is that saved_workout_id comes from create_personal_session or get_workout_details, implying a dependency, but no when/when-not or alternative comparisons are 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?
With no annotations to rely on, the description carries the full burden. It only says 'get' with no details about side effects (though read-only is implied), what 'recently used' means (time window, count), or whether results are sorted. The description adds minimal 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 sentence, front-loaded with the verb and resource. Every word is necessary and there is no redundancy or fluff.
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 very simple with no parameters, but it lacks an output schema and the description does not mention what the return value looks like (e.g., a list of IDs, full exercise objects). For a retrieval tool, this leaves room for ambiguity, but the minimal scope makes it borderline adequate.
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, so the schema is trivially empty and the baseline is 4. The description does not need to explain parameter meanings, and it adequately sets expectations that the tool takes no 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 tool retrieves the user's recently used exercises, with a specific verb ('get') and resource ('recently used exercises'). It distinguishes itself from sibling tools like get_recent_circuits (which gets circuits) and get_exercise_library (which lists all exercises).
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_exercise_library or get_exercise_detail. The description gives no context for selection criteria, prerequisites, 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?
No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. It only rephrases the tool name without explaining what 'recently used' means (e.g., time window, ordering), whether the operation is read-only, or any other side effects or restrictions. For a zero-parameter getter, some context about the returned data or default behavior is expected.
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, complete sentence with no filler or redundant information. It is efficiently front-loaded and 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?
With no output schema and no annotations, the description should explain what the tool returns or how the results are presented. It only states 'recently used circuits' without defining the return format, limit of results, or ordering criteria. This is adequate for a simple zero-param tool but leaves gaps for correct interpretation.
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, so the schema is trivially 100% covered. According to the rubric, a baseline of 4 applies for 0 params. The description adds no parameter-level detail because there are none to describe.
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 the user's recently used circuits, using a specific verb (Get) and resource (circuits). It is easily distinguishable from siblings like get_circuit_library (which would return all circuits) and get_recent_exercises (which focuses on exercises).
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 recently used circuits but does not explicitly state when to use it over alternatives or mention any exclusions. It relies on the name and context to convey its purpose, which is adequate but not explicit.
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 the return structure in detail: '{stream: {id, title, lastActivity, ...}, comments: [...]} where each comment has content, authorName, replies, and reactions.' This goes beyond the schema and sets clear expectations for the output, though it does not explicitly state read-only behavior or mention errors or edge cases.
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 purpose, and includes a useful output schema sketch. Every sentence earns its place with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a simple get tool, but it misses important context: no explanation of the optional team_id parameter, no mention of ordering or pagination for comments, and no usage guidance. Given the tool has two parameters and no output schema, the description could do more to fully prepare 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, but it does not mention parameters at all. The schema alone provides property names and types, but the description adds no semantic value about how to use team_id or program_workout_id. This leaves the agent to infer from the tool name and schema titles.
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 the messaging stream and all comments for a workout' with a specific verb and resource. It distinguishes itself from sibling tools like get_workout_details, get_workout_history, and get_workout_leaderboard by focusing specifically on messages and comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when messaging stream and comments are needed) but provides no explicit guidance on when-not-to-use or alternatives. There is no comparison to siblings or mention of prerequisites, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'Submit...' without detailing permissions, idempotency, side effects (e.g., whether an existing answer is overwritten), or the relationship between saved_workout_id and the survey. The provided ID mappings are helpful but do not address behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the primary action in the first sentence. The subsequent lines list ID mappings, which are essential and clearly structured. No filler 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?
The description covers the core purpose and parameter meanings but lacks important context: no mention of return values (no output schema), no preconditions (e.g., workout must exist), and no usage guidance. For a simple submission tool, it is functional but leaves gaps that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It maps question_id to specific survey questions (8=Sleep, etc.) and answer_id to rating labels (1=Awful...5=Excellent), which directly adds meaning. However, it doesn't explain saved_workout_id beyond implying it's a workout identifier, leaving that parameter underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Submit a readiness/recovery survey answer for a workout.' It specifies the verb (submit), resource (survey answer), and context (for a workout). This distinguishes it from sibling tools like get_workout_surveys (which retrieves surveys) and log_workout (which logs workouts).
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 implies when to use the tool: when submitting a survey answer for a workout. It provides clear context but does not explicitly mention alternatives or exclusions. For instance, it doesn't say to use get_workout_surveys to read existing answers. This is valid but slightly lacking in explicit 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 carries the full burden. It indicates a read-only 'Get' operation, but does not disclose other behavioral traits such as whether the data may be empty, if authentication is required, or any potential side effects. The behavior is simple, but more transparency could be added.
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 concise and front-loaded with the main action. The parenthetical adds useful detail about the output without unnecessary words.
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 (no parameters, no output schema), the description adequately covers the returned content. However, it does not explicitly mention what happens if the athlete has no team memberships or whether the response is an array, but this is not critical for a tool with such a narrow purpose.
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 there are no parameter semantics to document. The description adds context about what data is returned, which is sufficient given the absence of parameters.
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 an athlete's team memberships and license information, specifically including team IDs, program IDs, and coaches. This is a specific verb+resource combination that distinguishes it from siblings like get_user_profile or get_recent_exercises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving team-related data for an athlete, but it does not explicitly state when to use it over alternatives or mention any exclusions. The context from sibling names suggests a clear use case, but explicit guidance is missing.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It usefully reveals that the tool returns only the current user's profile (not another user's), which is a scoping constraint. The verb 'Get' also implies a read-only operation, and with no parameters, there is minimal behavior to disclose. However, it does not explicitly state authentication requirements or error conditions, so it falls short of a 5.
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 immediately states the tool's purpose, followed by a brief parenthetical of examples. Every word is informative, and there is no redundancy or fluff. It is perfectly sized for the tool's simplicity.
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 that this is a zero-parameter getter with no output schema and no annotations, the description is reasonably complete. It explains what data is returned (name, ID, coach status, etc.) and scopes it to the current user. It could have described the return format in more detail, but for such a simple tool, the description is sufficient to guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description does not need to explain parameter meaning since there are none, and the schema coverage is 100% trivially. The parenthetical examples of profile fields add some semantic context to what the tool will return, which is helpful.
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'), identifies the resource ('current user's profile'), and gives concrete examples of the profile fields (name, ID, coach status). This clearly distinguishes it from sibling tools like get_team_info or get_recent_exercises, 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?
The description provides no guidance on when to use this tool versus alternatives. It simply states what the tool does without context on appropriate use cases, exclusions, or prerequisites. There is no mention of scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveal that the return is a map of ID to survey data containing specific question types, which is useful. However, it does not mention any side effects, permissions, error behavior, or whether it is read-only, leaving some uncertainty.
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 compact sentences, front-loaded with the main action and return structure. Every word adds value, no redundancy or irrelevant 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 retrieval tool with one parameter and no output schema, the description covers the input, the output structure, and the data fields. It doesn't specify behavior for invalid IDs or limits, but this is a minor gap given the simplicity.
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 defines a field name and type with no description, giving 0% schema coverage. The description compensates by explaining the parameter is for saved workout IDs and how they map to the returned survey data. It adds clear semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves pre/post workout surveys for specific saved workout IDs. It uses a specific verb 'Get' and a specific resource 'workout surveys', distinguishing it from sibling tools that handle messages, leaderboards, or history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when survey data is needed for known workout IDs, but does not explicitly mention alternatives or exclusion criteria. For example, it doesn't distinguish itself from get_workout_details or get_workout_messages, though the resource is different. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states the operation is an add operation, that ordering matters, and that the tool returns created workout sets with full exercise details. It doesn't discuss error conditions or ipotential side effects, but the disclosed behavior is substantive and goes 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?
The description is three concise sentences. It front-loads the core purpose, then gives a parameter-specific instruction, then describes the return value. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter mutation tool with no annotations or output schema, the description covers the operation, parameter guidance for exercise_ids, and return behavior. It omits explicit mention that the session must already exist, but this is a minor gap given the sibling context and the meaning of 'Add exercises to a personal workout session'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for exercise_ids ('ordered list' and 'use get_exercise_library to look up IDs'). However, workout_id is left unexplained; its meaning is mostly inferred from the tool name and description, so the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Add exercises') on a specific resource ('personal workout session'), and explicitly notes the 'in order' behavior. This distinguishes it from sibling tools like create_personal_session (creating sessions) and get_exercise_library (looking up exercises).
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 (adding exercises to an existing personal workout session) and explicitly directs users to get_exercise_library for ID lookup. However, it does not explicitly state when not to use it or mention the alternative of creating a session first with create_personal_session.
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, so description must disclose behavior. It reveals the exact return structure and the purpose, but does not mention potential side effects, idempotency, or prerequisites (e.g., whether a session for that date already exists).
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, directly front-loaded with purpose and followed by essential return/chaining details. No wasted words.
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 single-parameter creation tool, the description covers purpose, input format, return shape, and downstream workflow. It is sufficient for an agent to invoke it correctly and chain with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates by specifying the date format (YYYY-MM-DD) for session_date, adding value beyond the bare 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?
Clearly states verb+resource: 'Create a new personal training session for a given date.' Provides exact return shape, distinguishing it from sibling tools that operate on existing sessions.
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 for the session-creation workflow, explicitly directing use of returned IDs with add_exercises_to_session and log_workout. Does not explicitly state when not to use it or alternatives, but the chaining guidance gives strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses caching behavior ('Reuses the cached workout-details response'), the need for team resolution via program_id/team_id, and the scope (per-set data for one exercise). It doesn't explicitly state read-only or error behavior, but the 'get' semantics and level of detail are sufficient for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and free of fluff. Every sentence adds value: purpose, usage context, and parameter guidance.
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 4 parameters and no output schema, the description covers purpose, usage context, and most parameters. It lacks an explicit mention of program_workout_id and return-value shape, but the caching note and 'per-set data' hint give enough context for an agent to proceed. Slightly more detail would make it 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?
Schema description coverage is 0%, so the description must explain parameters. It explains exercise_id and team_id/program_id ('Pass the exercise_id shown... plus the same program_id/team_id you used there'). However, it omits program_workout_id, a required parameter, leaving a gap for that key identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Get the full, un-slimmed per-set data for ONE exercise within a workout.' It explicitly distinguishes itself from the sibling get_workout_details by noting this returns per-set data without pulling the entire session, making its scope clear.
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?
It provides clear guidance: 'Use this after a slim get_workout_details call' and explains the trade-off (get every logged set without pulling the entire session). It also specifies the prerequisite of reusing the cached workout-details response and what parameters to pass, giving actionable when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses substantial behavior: the response can exceed 200k characters, slim mode strips specific fields, media fields are always stripped, coaching text truncates to max_text_chars, and team resolution falls back to the user's primary team. It also explains server-side team resolution when program_id is provided. No contradictions exist.
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 organized into three purposeful paragraphs: overview, usage/team resolution, and slim-mode details with an alternative. Each sentence carries operational information—response size, defaults, fallbacks, and alternatives—so the length is justified and the core purpose is front-loaded.
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 6-parameter tool with no output schema, the description is remarkably complete: it specifies input provenance, output contents and size, default behavior, truncation, and a targeted alternative. It also warns about a concrete risk (raw response >200k chars) that affects agent decisions. The only minor omission is cache_bust semantics, which does not substantially hurt usability.
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 0%, so the description must compensate, and it covers 5 of 6 parameters: program_workout_id provenance, program_id/team_id relationship, slim behavior, and max_text_chars truncation. cache_bust is the only parameter left unexplained, but it is a minor boolean flag and all required/main parameters are given clear semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get workout details for a specific program workout,' and enumerates the included content (exercises, prescribed vs. logged sets, coaching notes). It also distinguishes from sibling tools by tying to get_workout_history and directing single-exercise needs to get_exercise_detail.
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?
It explicitly instructs to pass the program_workout_id from get_workout_history, explains the trade-offs between program_id and team_id, and names get_exercise_detail as the alternative when only one exercise's per-set data is needed. It also tells when to use slim=True versus slim=False based on response size and context-window constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: date format requirements, one-day-at-a-time fetching for completeness, the default projection, and cache_bust's side effect of 'ignoring and overwriting any cached data regardless of TTL.' This goes beyond a simple read operation and is essential 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 organized into clear paragraphs: overview, date/default behavior, default projection, usage guidance, and cache_bust. Each sentence adds necessary information without fluff, making it appropriately sized for the tool's 5 parameters and behavioral nuances.
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?
Given the lack of output schema and annotations, the description is remarkably complete. It explains the return format (flat summary with listed fields), covers all parameter semantics, provides usage boundaries, and presents alternatives. No critical information seems missing for this history-retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains start/end date as a date range with YYYY-MM-DD format, weeks_back as the default fallback, include_sets as a boolean for set-level data with range restrictions, and cache_bust for forcing fresh fetches. All 5 parameters are given meaningful context.
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 workout history for a date range' with a specific verb and resource. It distinguishes itself from siblings by positioning the flat summary as for 'scanning history and finding sessions' and explicitly recommending get_workout_details for single known sessions.
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?
It explicitly guides when to use the tool ('Use this for scanning history and finding sessions'), warns against include_sets=True for broad ranges, and directs users to get_workout_details for full set data on a single session. This meets the 'when/when-not/alternatives' criterion perfectly.
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:

[![trainheroicMcp MCP server](https://glama.ai/mcp/servers/cmagorian/trainheroicMcp/badges/card.svg)](https://glama.ai/mcp/servers/cmagorian/trainheroicMcp)

Score Badge

Copy to your README.md:

[![trainheroicMcp MCP server](https://glama.ai/mcp/servers/cmagorian/trainheroicMcp/badges/score.svg)](https://glama.ai/mcp/servers/cmagorian/trainheroicMcp)

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/cmagorian/trainheroicMcp'

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