io.github.matisdsp/fartlek

by matisdsp

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation5/5
Each tool has a clearly distinct purpose with explicit cross-references (e.g., garmin_brief owns today's readiness, garmin_recovery owns overtraining, garmin_load owns multi-week training dose). No two tools appear to do the same thing; even similar tools like garmin_activities/garmin_activity are distinguished by singular vs plural and description.
Naming Consistency4/5
All tools share the garmin_ prefix and lowercase snake_case, but the pattern mixes nouns (garmin_activity, garmin_week), verbs (garmin_sync), verb phrases (garmin_set_profile), and a question (garmin_whats_changed). Read vs write is somewhat predictable (nouns for queries, verbs for actions), but not uniform.
Tool Count5/5
14 tools is within the ideal 3-15 range and each tool covers a distinct aspect of Garmin data analysis: from daily brief to weekly summary, fitness trends, recovery, load, and raw data. The size feels justified for the domain.
Completeness4/5
The server covers the full workflow of an athletic coaching assistant: profile management, subjective logging, daily readiness, activity browsing and deep-dive, fitness/recovery/load analysis, week summaries, change detection, and reference/raw data escape hatches. Minor gaps exist (e.g., no direct plan editing or log deletion), but they are outside the stated purpose.
Average 4.4/5 across 14 of 14 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 102 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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?
Annotations already mark readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds analytical scope and dependency on a stored goal ('against the stored goal', 'projected to race day') but offers no behavioral details such as data source freshness or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Text is two sentences plus an introductory clause; front-loaded with 'Is training working', then lists outputs and use cases. Some redundancy exists: race projection/race planning and taper guidance/taper timing are repeated in the second sentence.
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?
With read-only annotation, an output schema, and a 2-parameter schema that fully documents inputs, the description provides enough context for a typical agent. It covers primary use cases and related tool, though it omits edge-case behavior when no goal is stored.
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?
Input schema covers both parameters (weeks, anchor_date) with descriptions and defaults, so description need not repeat them. Description does not mention these parameters at all, but schema coverage is 100%, so baseline 3 applies.
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 opens with 'Is training working:' and enumerates specific outputs (VO2max, efficiency trends, HR at fixed pace, long-run durability, race projection, form/taper). It distinguishes from siblings by naming a related tool for setting goals and specifying call intents like 'am I getting fitter'.
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?
'Call for 'am I getting fitter', race planning, taper timing, goal feasibility' provides explicit when-to-use guidance, and points to garmin_set_profile for goal configuration. However, it does not explicitly list exclusions or alternative analytical 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?
Annotations already mark readOnlyHint and destructiveHint, so the bar is lower. The description adds useful output context (verdict, alerts, yesterday's activity_id, planned workout). However, the claim 'Zero arguments' is factually wrong since the schema includes an optional date parameter, which undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded, and free of fluff. The 'Zero arguments' inaccuracy is a minor blemish, but overall it 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?
Given the presence of an output schema and strong annotations, the description covers what the tool does, when to use it, and how it differs from siblings. The only notable gap is the misleading argument count, but the core functionality is sufficiently complete for a read-only brief.
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 alone covers the date parameter with 100% coverage and a clear description. But the tool description's false 'Zero arguments' statement actively misleads the agent about parameter usage, so the description detracts from rather than adds to parameter understanding.
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 what the tool does: provides a fused daily brief for today's readiness and training status. It differentiates from siblings by explicitly directing to garmin_activity for a single session and garmin_activities for browsing.
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 'Call FIRST for anything about TODAY' and gives clear alternatives: 'One session → garmin_activity; browsing → garmin_activities.' This is textbook when-to-use 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it is 'compacted and hard-capped,' 'bounded,' and tied to a single named source. This gives the agent a clear expectation of constrained, raw output, though it does not detail response formatting 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 with no filler. It front-loads the core concept ('Bounded escape hatch'), immediately adds usage restrictions, and ends with a clear prohibition. Every phrase earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover safety, the description does not need to explain return values or destructive behavior. It provides essential context about boundedness, raw values, and usage policy. It does not enumerate all source-specific dependencies, but the schema covers those details, so the description is reasonably complete for a deliberately constrained escape-hatch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description should compensate. It only implicitly references 'source' via 'one named Garmin source' and 'hard-capped' via max_points, but provides no guidance on date, series, or activity_id dependencies. The schema itself documents activity_id as required for activity_* sources and weather, but the description adds minimal parameter-level value.
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 conveys that this is a bounded way to access raw values from a single named Garmin source, and explicitly contrasts it with synthesis tools by saying 'Use ONLY when a synthesis tool cannot answer and the user explicitly asks for raw values.' However, it relies on the metaphor 'escape hatch' instead of a direct verb like 'retrieve' or 'fetch,' so it is clear but not maximally explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: only when a synthesis tool cannot answer and the user explicitly requests raw values. It also states a firm exclusion: 'Never a starting point.' This clearly distinguishes it from sibling synthesis tools and prevents inappropriate first-use.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful context about what the output contains (formula, inputs, thresholds, caveats), which goes beyond the annotations and helps the agent understand what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core purpose. It avoids redundancy and every phrase adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a reference tool with an output schema and two optional parameters, the description provides sufficient context: what it computes, trustworthiness, and usage modes. It could be more explicit about how it relates to sibling tools like garmin_brief or garmin_fitness, but it is otherwise 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 50% (only 'metric' has a description). The description partially compensates by indicating that 'metric' specifies a single metric for in-depth info and that no arguments are needed for the index. However, the 'topic' parameter is not explained, leaving some ambiguity.
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 explains that the tool provides reference information about how metrics are computed, including formulas, inputs, thresholds, and caveats. It is distinct from sibling tools which likely focus on data retrieval or summaries, though it lacks an explicit verb like 'returns' or 'provides'.
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 direct usage guidance: 'No arguments for the index; metric="acwr" for one in depth.' This clarifies two modes of invocation. However, it does not explicitly compare with alternative sibling tools or state when not to use it.
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?
Beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds valuable behavioral context: 'Local only' and 'only provided fields change' disclose that the tool operates on a local profile and performs partial updates without affecting unspecified fields. This goes beyond what annotations alone convey.
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 the core content front-loaded and no redundant phrases. Every clause adds information: the field list, the local/partial update semantics, and the sibling-tool exclusion. It is concise without sacrificing clarity.
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 (11 optional parameters) and the presence of an output schema, the description provides sufficient high-level context: what the profile is for, which fields are affected, and the boundary with garmin_log. It lacks detailed cross-parameter relationships, but those are partially captured in schema descriptions, and the local/partial update statement reduces risk of misuse.
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 only 36% schema description coverage, the description compensates by grouping parameters into semantic categories: goal race (date, distance, fixed-time), phase, weekly availability, intensity preference, LT1 override. It enriches the meaning of parameters like goal_target_km by explaining fixed-time events (e.g., '24h with a target distance'). However, not every parameter (e.g., phase_week, phase_total_weeks) is explicitly mentioned, though they fall under 'phase'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource ('athlete context the watch cannot know') and lists the specific fields that are set, distinguishing it from the sibling tool garmin_log. Though it lacks an explicit verb like 'set' or 'update', the tool name supplies that action and the description enumerates the profile attributes, making the purpose clear.
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 explicit when-not-to-use guidance ('Injuries and illness go to garmin_log') and clarifies the scope of use ('Local only; only provided fields change'). It implies when to use the tool—when providing athlete context the watch cannot know—but does not explicitly state alternatives beyond the garmin_log exclusion.
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?
Annotations already declare readOnlyHint and destructiveHint, and the description adds meaningful context: it scans all metrics, filters to statistically significant changes, ranks safety-first, and returns 'nothing notable' when nothing tripped. This goes beyond the minimal safety profile without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with usage triggers and followed by behavioral details. Every sentence adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single optional parameter, read-only annotations, an output schema, and a clear purpose, the description covers all essential context. It also provides a fallback behavior and a pointer to a sibling tool, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed metadata for since_days (default, min, max). The description does not mention the parameter, but the schema fully documents it. This matches the baseline for high schema 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 scans every tracked metric and returns only statistically significant changes, ranked safety-first. It also distinguishes itself from siblings by explicitly noting that today's readiness is handled by garmin_brief, making its purpose unique.
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?
Explicitly provides when to use via trigger phrases ('anything I should know?', 'what's new?', 'catch me up', 'after days away') and mentions garmin_brief as an alternative for readiness. However, it doesn't explicitly state when not to use, stopping just short of full when/when-not guidance.
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 annotations already indicating readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: it discloses truncation behavior ('truncation is disclosed with narrowing advice') and describes the output structure ('One row per session, each carrying the activity_id'). This goes beyond the annotations by explaining result-set limits and the relationship to garmin_activity.
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, front-loaded with the primary action ('Browse the log and get activity IDs'). Each sentence adds essential information: purpose, output format, and filtering/truncation behavior. No wasted words 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?
Given the output schema exists and the tool has four optional parameters, the description covers the core functionality, filtering options, truncation behavior, and the connection to garmin_activity. It doesn't mention default date ranges or limit defaults, but these are documented in the schema. The description is sufficiently complete for a read-only browsing 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 description coverage is 50%, with start_date and end_date having explicit date format descriptions. The description mentions 'Filter by date range and sport,' which adds context for sport and date parameters, but it does not clarify the 'limit' parameter beyond what the schema already provides (min/max/default). The truncation hint partially compensates, but the tool could be more explicit about how limit interacts with truncation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Browse the log and get activity IDs.' It specifies the resource (the log) and the action (browse/get IDs), and distinguishes itself from sibling tools like garmin_activity by noting the IDs are what that tool accepts. This makes the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Filter by date range and sport; truncation is disclosed with narrowing advice.' This indicates when filters should be applied to avoid truncation. It also implicitly guides the user to use garmin_activity for further details on each activity. However, it lacks explicit when-not-to-use guidance or direct comparison with alternatives like garmin_log.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: it reports multi-week trends normalized to the athlete's own norm and excludes single-day readiness. This goes beyond the annotation safety profile without contradicting it.
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, densely packed with domain-specific information. Front-loaded with the core output and followed by usage and exclusions. 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?
The tool's complexity, output schema availability, and sibling context are fully addressed. The description covers the key domain, use cases, and alternatives, while the existence of an output schema eliminates the need to explain return values. Parameters are fully documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on the parameters (weeks, anchor_date), but the schema already documents them adequately. No additional semantic value is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'load' with a clear resource: multi-week training load metrics (CTL/ATL/TSB, ramp rate, ACWR, etc.). It explicitly contrasts with sibling tools (garmin_brief, garmin_recovery), making its unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call ('am I training too much', ramp/taper dosing, periodization) and what it is NOT for (single-day readiness, overtraining physiology), naming the alternative tools. This provides unambiguous usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so no safety disclosure is needed. The description adds behavioral context: it compares to personal baselines and performs a multi-marker audit, which clarifies the analysis scope. It does not mention any side effects or limitations, but for a read-only tool that is acceptable.
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 tight sentences, front-loaded with the tool's core outputs. Every sentence earns its place: what it provides, when to call it, and how it differs from a sibling tool. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema present, the description doesn't need to detail return values. It covers purpose, usage triggers, exclusions, and ownership. The two optional parameters are simple and well-documented in the schema, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'days' and 'anchor_date' have clear descriptions in the input schema. The description doesn't add extra parameter detail, but with complete schema coverage, baseline 3 is appropriate. It implicitly refers to a time window ('vs personal baselines') without augmenting 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 identifies the tool's function: analyzing sleep, HRV, resting HR, and load structure against personal baselines, plus an overtraining audit. It distinguishes itself from siblings by explicitly claiming ownership of overtraining questions and pointing to garmin_brief for single-day go/no-go.
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 gives explicit trigger conditions: 'Call for tiredness, sleep, am I overtraining or getting sick, or when another tool flags recovery.' It also specifies what it does not cover (single-day go/no-go is garmin_brief), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by detailing the report's contents, including conditional plan compliance "where a plan exists," which helps the agent set expectations for the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose and content list, followed by usage guidance and sibling differentiation. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a read-only annotation, simple optional parameter fully described in the schema, and an output schema present, the description covers the key aspects: content, usage, and alternatives. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for anchor_date is complete ("YYYY-MM-DD, its Mon-Sun week"), providing full parameter semantics. The description reinforces the idea of a specific week but doesn't add new format details, so the baseline of 3 is appropriate given 100% schema 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 explicitly states the tool reports one week in session-level detail, enumerating specific content: load vs recent weeks, intensity distribution, per-day session table with activity_ids, recovery summary, and plan compliance. This clearly distinguishes it from siblings, especially garmin_load, which it explicitly names for multi-week trajectories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: "Call for 'how was my week' or a specific week," and also gives a clear alternative: "Multi-week trajectory is garmin_load." This tells the agent exactly when to use this tool and when to use a different one.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations: the kinds of analysis performed (e.g., 'rep-by-rep fade', 'planned-vs-executed'), the selection fallback to the latest activity, and the addition of lap tables or HR/pace curves for 'splits' and 'full'. 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?
Three compact sentences deliver all key information with no fluff. The first sentence front-loads the core purpose, the second covers selection logic, and the third explains detail levels. Every clause adds value and is appropriately sized for the complexity.
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 tool's moderate complexity and the presence of an output schema, the description covers purpose, selection modes, detail levels, and analytical insights. It is complete enough for an agent to select and invoke the tool correctly. The 'ONE session' phrasing also prevents confusion with the plural sibling garmin_activities.
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 description coverage is only 25%, so the description must compensate, and it does extensively. It explains how activity_id, date, and sport interact in selection, and clarifies that omitting both activity_id and date returns the latest activity. It also gives meaning to the 'detail' parameter by specifying what 'splits' and 'full' add. This is well beyond the schema's bare parameter names.
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 'ONE session in depth,' clearly identifying the resource (a single Garmin activity/session) and the operation (retrieving detailed analysis). It distinguishes itself from the sibling tool 'garmin_activities' by explicitly focusing on one session rather than a list, and the phrases 'execution vs structure, rep-by-rep fade, decoupling, comparison to the closest past session, planned-vs-executed' specify the kind of depth provided.
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 explicit selection instructions: 'Select by activity_id, by date, or omit both for the latest — add sport for the latest of that sport.' It also explains when to use 'splits' and 'full' detail levels. However, it does not explicitly name alternatives or state when not to use this tool versus siblings, though the 'ONE session' wording implies the contrast with garmin_activities.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds behavioral context by noting the data 'changes rarely' and suggesting a single call, which informs the agent about stability and call frequency. It does not contradict annotations, and the added context goes beyond what the structured fields provide.
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 redundant words. The first sentence lists the data categories in a compact, scannable format. The second sentence delivers usage guidance and the sibling reference. Every clause contributes meaning.
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 that the tool has an output schema (which handles return details), no parameters, and annotations covering safety, the description fully covers the essential context: what the tool provides, when to call it, and how to update the underlying data. The presence of sibling tools like 'garmin_reference' and 'garmin_set_profile' makes the explicit differentiation valuable and 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, so the schema contains no information to clarify. The description's content list serves as the semantic context for what the tool returns, effectively compensating for the lack of parameters. With no params, the baseline is 4, and the description meets that baseline by conveying the scope of the reference card.
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 'Reference card' followed by a concrete list of contents (zones, thresholds, PRs, goal and phase, baselines, injury notes, device data coverage), making the tool's purpose immediately clear. It also distinguishes itself from the sibling 'garmin_set_profile' by explicitly stating that changing the profile is a different tool's job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call once when athlete context is unknown; it changes rarely.' It also provides an alternative: 'To change it, garmin_set_profile.' This clearly tells the agent when to invoke this tool and when to use a sibling instead.
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?
The description adds behavioral detail beyond annotations, such as the effect of backfill_days (deepens sleep/HRV history), the resumable nature of backfill, and that it reports freshness. While it doesn't discuss rate limits or side effects, it provides meaningful context for a mutation tool with minimal 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?
Two sentences, front-loaded with the primary action, and no unnecessary words. Every clause adds value: the backfill explanation, the resumable nature, and the usage warning.
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 presence of an output schema (noted in context) and the clarity of sibling relationships, the description covers the essential aspects: purpose, usage conditions, parameter semantics, and behavioral expectations. It is complete for a tool of this complexity.
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?
Even though schema coverage is 0%, the description explains the semantic of backfill_days: 'backfill_days > 0, deepens sleep/HRV history.' This compensates for the lack of parameter descriptions in the schema, though it doesn't mention the default or range (which are 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 states a specific verb and resource: 'Force a refresh and report freshness, or start a resumable historical backfill.' It clearly distinguishes this from siblings by noting that 'every other tool auto-refreshes,' implying this is the manual override.
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?
Explicit usage guidance is provided: 'Use only if data looks stale.' It also implicitly names the alternative (every other tool auto-refreshes), giving a clear when and when-not to use the tool.
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?
Beyond the annotations (readOnly=false, idempotent=true, destructive=false), the description discloses important downstream effects: the data 'feeds sRPE load and caps the readiness verdict.' It also explains the flag lifecycle ('set flag; resolve when healed'), adding behavioral context far beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the core purpose front-loaded in the first phrase. Every sentence adds value: field enumeration, downstream consequences, and a specific interaction guideline. No filler or redundant restatement of the tool name.
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 an 11-parameter, presumably write-oriented tool, the description covers what to log, the exact scales, the flag lifecycle, the effect on load/readiness, and when to prompt for missing data. The existence of an output schema reduces the need to describe return values, and the description stands well alongside sibling tools.
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?
Despite the very low schema description coverage (9%), the description compensates thoroughly by enumerating all key parameters with their scales: RPE 1-10, Hooper wellness dimensions (fatigue, soreness, stress, mood, sleep quality) each 1-7, notes, and flags. It also clarifies the resolve_flag behavior and the expected values for wellness 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 opens with 'Subjective data the watch cannot capture,' clearly identifying the tool's resource and scope: logging RPE, Hooper wellness, notes, and flags. It distinguishes itself from sibling tools by contrasting with objective watch-captured data, and names concrete fields with ranges.
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 explicit guidance for when to log RPE ('Ask for RPE after discussing a session if missing') and when to set/resolve illness or injury flags. It implies the tool is for subjective data only, which differentiates it from objective sibling tools, but it does not explicitly name alternatives or state when not 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:

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

Score Badge

Copy to your README.md:

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

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/matisdsp/fartlek'

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