Intervals.icu MCP Server

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: add_or_update_event creates/updates events, delete_event and delete_events_by_date_range handle deletion, get_activities and get_events retrieve lists, get_event_by_id and get_activity_details fetch specific items, get_activity_intervals and get_activity_streams provide specialized data, and get_wellness_data covers a separate domain. The descriptions clearly differentiate between events and activities, and between summary and detailed data.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case: add_or_update_event, delete_event, delete_events_by_date_range, get_activities, get_activity_details, get_activity_intervals, get_activity_streams, get_event_by_id, get_events, get_wellness_data. The verbs (add_or_update, delete, get) are used predictably, and nouns (event, activity, wellness_data) are clearly specified, making the naming highly consistent and readable.
Tool Count5/5
With 10 tools, this server is well-scoped for managing athlete data in Intervals.icu, covering events, activities, and wellness data. Each tool serves a specific function (e.g., CRUD for events, detailed queries for activities), and none seem redundant or missing for the domain. This count aligns with typical server sizes (3-15 tools) and supports comprehensive workflows without being overwhelming.
Completeness4/5
The tool set provides strong coverage for the Intervals.icu domain, including CRUD for events (add/update, delete, get), detailed activity retrieval (list, details, intervals, streams), and wellness data. Minor gaps exist, such as no update or delete tools for activities (only get operations) and no tools for athlete management (e.g., list athletes), but agents can likely work around these with the available event and data tools.
Average 3.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 7 community issues answered or closed in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under GPL 3.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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions that the API key is optional with fallback to .env, but doesn't describe authentication requirements, rate limits, error handling, or what 'detailed information' includes. For a read operation with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. The two-sentence format with bullet-like 'Args:' section is readable and front-loaded. No wasted words, though the parameter section could be more integrated with the main description.
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 2 parameters with 0% schema coverage, an output schema exists (which helps), but no annotations. The description covers basic parameter meaning and authentication fallback, but lacks behavioral context, sibling differentiation, and detailed usage guidance. For a simple read operation, this is minimally adequate but has clear gaps in completeness.
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 schema provides no parameter documentation. The description adds basic semantics for both parameters: 'activity_id' as 'The Intervals.icu activity ID' and 'api_key' with optional/env fallback behavior. This compensates somewhat but doesn't provide format examples, constraints, or relationship between parameters. Given the coverage gap, this is minimal adequate compensation.
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 resource 'detailed information for a specific activity from Intervals.icu', making the purpose evident. However, it doesn't explicitly differentiate from siblings like 'get_activities' (list) vs 'get_activity_details' (single item), which would require a 5. The description is specific but lacks sibling distinction.
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 like 'get_activities' or 'get_event_by_id'. It mentions optional API key handling but gives no context about use cases, prerequisites, or comparisons with sibling tools. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a deletion operation, implying it's destructive, but doesn't clarify if deletions are permanent, reversible, or require specific permissions. It mentions optional parameters falling back to .env variables, which is useful context, but lacks details on rate limits, error handling, or what 'events' encompass (e.g., workouts, races).
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 well-structured and appropriately sized. The first sentence states the purpose clearly, followed by a bullet-point-like 'Args:' section that efficiently documents parameters. Every sentence adds value, with no redundant or vague phrasing. It could be slightly more concise by integrating parameter details into the main description, but it's already front-loaded and readable.
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 complexity (destructive operation, 4 parameters, 0% schema coverage) and the presence of an output schema (which reduces need to explain return values), the description is moderately complete. It covers the purpose and parameters well but lacks behavioral context (e.g., permanence of deletions, error cases) and usage guidelines relative to siblings. For a deletion tool with no annotations, more safety and context details would be beneficial.
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. It adds significant value by explaining all four parameters: 'athlete_id' and 'api_key' are optional with fallbacks to .env, and 'start_date' and 'end_date' specify the range in YYYY-MM-DD format. This clarifies semantics beyond the bare schema, though it doesn't detail validation rules or interdependencies.
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 purpose: 'Delete events for an athlete from Intervals.icu in the specified date range.' This specifies the verb (delete), resource (events), and scope (for an athlete, from Intervals.icu, within a date range). However, it doesn't explicitly differentiate from sibling tools like 'delete_event' (singular vs. range-based deletion).
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 doesn't mention sibling tools like 'delete_event' (for single events) or 'get_events' (for viewing events), nor does it specify prerequisites or exclusions. The agent must infer usage from the tool name and description alone.
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 full burden. It mentions the tool fetches 'detailed information' but doesn't disclose behavioral traits like authentication requirements (beyond optional parameters), rate limits, error handling, or what 'detailed information' includes. The optional parameters hint at fallback to environment variables, but this is insufficient for a mutation-free tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the purpose in the first sentence. The parameter explanations are clear and necessary given low schema coverage, with no redundant information. However, the structure could be slightly improved by separating purpose from args more distinctly.
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 has an output schema (which handles return values), no annotations, and low schema coverage, the description is moderately complete. It covers the purpose and parameters adequately but lacks usage guidelines and behavioral context (e.g., authentication, error cases), leaving gaps for a tool with three parameters and sibling alternatives.
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. It explains all three parameters: 'event_id' as the event ID, 'athlete_id' as optional with fallback to ATHLETE_ID from .env, and 'api_key' as optional with fallback to API_KEY from .env. This adds meaningful context beyond the bare schema, though it doesn't cover format details (e.g., ID structure).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information for a specific event from Intervals.icu'. It specifies the verb ('Get'), resource ('event'), and scope ('specific'), but doesn't explicitly differentiate from sibling tools like 'get_events' (which likely lists multiple events).
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 doesn't mention sibling tools like 'get_events' (for listing events) or 'get_activity_details' (for activity data), nor does it specify prerequisites or exclusions for 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 for behavioral disclosure. It mentions that parameters can fall back to environment variables, which is useful context. However, it doesn't describe what 'events' are in this context (training sessions, competitions, calendar items?), the response format, pagination behavior, rate limits, authentication requirements beyond the API key parameter, or error handling. For a data retrieval tool with no annotation coverage, this leaves significant gaps.
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 well-structured and appropriately sized. The purpose is stated concisely in the first sentence, followed by a clear parameter documentation section. Each parameter explanation is brief but informative. There's no wasted text, though the structure could be slightly improved by separating the purpose statement more distinctly from the parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. However, with no annotations and multiple sibling tools, the description should provide more context about what constitutes 'events' in this system and when to use this versus alternatives. The parameter documentation is good, but the overall context for tool selection and behavioral expectations is incomplete.
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 fully compensate for parameter documentation. It successfully documents all 4 parameters with clear semantics: what each parameter represents, optional status, default values, and format requirements (e.g., 'YYYY-MM-DD'). The description adds substantial value beyond the bare schema, though it doesn't explain relationships between parameters (e.g., what happens if start_date > end_date).
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 purpose: 'Get events for an athlete from Intervals.icu'. It specifies the verb ('Get'), resource ('events'), and source ('Intervals.icu'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_event_by_id' or 'get_activities', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_event_by_id' (for single events) and 'get_activities' (for different data types), the agent has no indication of when this batch event retrieval tool is appropriate versus those other options. The parameter documentation doesn't substitute for usage context.
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 full burden. It states 'Delete' implying a destructive mutation but doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, has rate limits, or what the output contains. This is inadequate for a mutation tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose, followed by parameter details. The Args section is structured but slightly verbose; every sentence earns its place by clarifying parameter behavior.
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 a destructive mutation tool with no annotations, 3 parameters (0% schema coverage), and an output schema (which reduces need to describe returns), the description is partially complete. It covers parameters well but lacks behavioral context like safety warnings or usage scenarios, leaving gaps for agent understanding.
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 0%, so the description must compensate. It provides clear semantics for all 3 parameters: 'event_id' as the event ID to delete, and optional 'athlete_id' and 'api_key' with fallback to environment variables. This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and resource 'event for an athlete from Intervals.icu', making the purpose unambiguous. It distinguishes from siblings like 'delete_events_by_date_range' by specifying single event deletion, though not explicitly contrasting them.
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 on when to use this tool versus alternatives like 'delete_events_by_date_range' or 'add_or_update_event'. The description only lists parameters without contextual usage advice, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions optional parameters with fallbacks to environment variables and date defaults, which is helpful. However, it doesn't describe authentication requirements, rate limits, error conditions, pagination, or what specific wellness data fields are returned. For a read operation with no annotation coverage, this leaves significant gaps.
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 well-structured with a clear purpose statement followed by organized parameter documentation. Each parameter explanation is efficient and informative. The only minor improvement would be integrating the parameter explanations more seamlessly rather than using a separate 'Args:' section.
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 that an output schema exists, the description doesn't need to explain return values. However, for a tool with 4 parameters, 0% schema description coverage, and no annotations, the description does well on parameters but lacks behavioral context about authentication, rate limits, and error handling. It's adequate but has clear gaps in operational guidance.
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 0%, so the description must fully compensate. It provides complete parameter documentation: all 4 parameters are clearly explained with their purposes, optional status, fallback behaviors, and format requirements. The description adds substantial value beyond the bare schema by explaining the .env fallback mechanism and date defaults.
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 purpose: 'Get wellness data for an athlete from Intervals.icu'. It specifies the verb ('Get'), resource ('wellness data'), and source ('Intervals.icu'), but doesn't differentiate from sibling tools like 'get_activities' or 'get_events' that also fetch data from the same platform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'get_activities' or explain what makes wellness data distinct from other data types available through the API. Usage context is implied but not explicitly stated.
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 mentions the conditional create/update behavior based on event_id, which is useful. However, it doesn't describe important behavioral aspects like authentication requirements (though it mentions API key fallback), error handling, rate limits, or what happens on success/failure. The extensive step documentation compensates somewhat but focuses more on parameter usage than tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and poorly structured for an AI agent. While the parameter and step documentation is valuable, it should be more front-loaded with core purpose and usage, with detailed examples moved to a separate section. The current structure buries the essential information in lengthy examples and step property listings, making it inefficient for quick comprehension.
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 complexity (9 parameters, nested workout_doc structure) and 0% schema coverage, the description provides substantial context. It thoroughly documents parameters and includes a rich example. With an output schema present, it doesn't need to explain return values. The main gap is lack of behavioral context like error conditions or authentication requirements, but the parameter coverage is comprehensive.
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?
With 0% schema description coverage, the description must fully compensate, which it does excellently. It provides detailed explanations for all 9 parameters, including optionality, default values, and environmental fallbacks. The extensive documentation of workout_doc structure, step properties, and usage examples adds significant semantic value beyond what the bare schema provides, making parameter understanding comprehensive.
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 purpose: 'Post event for an athlete to Intervals.icu' with the conditional update behavior when event_id is provided. It specifies the resource (event/athlete) and the action (post/update). However, it doesn't explicitly differentiate from sibling tools like 'get_event_by_id' or 'delete_event' beyond mentioning the update condition.
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 minimal usage guidance. It mentions that if event_id is provided, the event will be updated instead of created, which gives some context for when to use it for updates versus creation. However, it doesn't explain when to use this tool versus alternatives like 'delete_event' or 'get_events', nor does it mention prerequisites or typical use cases beyond the technical mapping to the API.
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 describes a read operation ('Get a list'), which implies it's non-destructive, but doesn't cover other critical aspects like authentication needs (though API key is a parameter), rate limits, error handling, or what the output contains. For a tool with no annotations and multiple parameters, this leaves significant gaps in understanding its behavior.
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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by a bullet-point list of parameters with concise explanations. Every sentence adds value, and there's no redundant information. However, it could be slightly more front-loaded by integrating key parameter details into the initial sentence, but it's still highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, but has an output schema), the description is mostly complete. It thoroughly documents all parameters, which is crucial since schema coverage is 0%. The presence of an output schema means return values don't need explanation in the description. However, it lacks behavioral context (e.g., auth, limits) and usage guidelines, which are minor gaps in an otherwise solid description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% schema description coverage. It explains all six parameters: their purposes (e.g., 'athlete_id: The Intervals.icu athlete ID'), optionality, defaults (e.g., 'defaults to 30 days ago'), and formats (e.g., 'YYYY-MM-DD format'). This fully compensates for the lack of schema descriptions, providing clear and complete parameter semantics.
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 purpose: 'Get a list of activities for an athlete from Intervals.icu'. This specifies the verb ('Get'), resource ('activities'), and source ('Intervals.icu'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_activity_details' or 'get_events', which also retrieve activity-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_activity_details' (for specific activity data) or 'get_events' (for events vs. activities), nor does it specify prerequisites or contexts for use. The only implied usage is for retrieving activity lists, but this is basic and lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what data is returned but doesn't mention authentication requirements beyond the optional api_key parameter, rate limits, pagination, error conditions, or whether this is a read-only operation. The description is functional but lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by detailed parameter documentation. It's appropriately sized for a tool with 3 parameters and comprehensive parameter documentation needs. The information is front-loaded with the core purpose first. Minor deduction for some redundancy in listing metrics both in the purpose statement and parameter 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?
Given the tool has an output schema (which handles return values), 3 parameters with 0% schema coverage, and no annotations, the description does well by thoroughly documenting all parameters. It covers what data is returned and parameter semantics. The main gap is lack of behavioral context like authentication, rate limits, or error handling, but the output schema reduces the need to describe return format.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains activity_id's purpose, clarifies api_key's optional nature and fallback behavior, documents stream_types' format and default values, and lists all available stream types. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get stream data for a specific activity from Intervals.icu' with specific metrics listed. It distinguishes from siblings like get_activity_details or get_activities by focusing on time-series stream data rather than summary or interval data. However, it doesn't explicitly contrast with these siblings in the description text 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 like get_activity_details or get_activity_intervals. It mentions the tool's scope but doesn't indicate scenarios where stream data is needed over other activity data types, nor does it mention 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what data is returned but doesn't mention authentication requirements beyond the optional api_key parameter, rate limits, error conditions, or whether this is a read-only operation. The description states it 'returns detailed metrics' which implies read-only behavior, but this isn't explicitly confirmed.
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 well-structured with a clear purpose statement followed by parameter documentation. Every sentence adds value, though the parameter documentation could be slightly more concise. The information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return value documentation), 2 parameters with good semantic coverage in the description, and no annotations, the description is reasonably complete. It covers the purpose, what data is returned, and parameter semantics. The main gap is lack of explicit behavioral context like authentication requirements or rate limits.
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?
With 0% schema description coverage, the description fully compensates by providing clear semantic information for both parameters. It explains that activity_id is 'The Intervals.icu activity ID' and api_key is 'The Intervals.icu API key (optional, will use API_KEY from .env if not provided)', adding crucial context about the optional fallback behavior not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get interval data') and resource ('for a specific activity from Intervals.icu'), distinguishing it from siblings like get_activity_details or get_activity_streams. It specifies what kind of data is returned (detailed metrics for each interval) and mentions grouped intervals as an additional feature.
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 context through the parameter documentation (activity_id is required, api_key is optional with fallback), but doesn't explicitly state when to use this tool versus alternatives like get_activity_details or get_activity_streams. No explicit guidance on when-not-to-use or comparison with sibling tools is provided.
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:

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

Score Badge

Copy to your README.md:

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

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/mvilanova/intervals-mcp-server'

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