List, fetch, create, edit (replace), delete and schedule structured workouts on Garmin Connect (runn
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.8/5 across 16 of 16 tools scored. Lowest: 3.1/5.
Every tool has a clearly distinct purpose. The Garmin-specific tools each handle a unique operation on workouts or accounts, and the platform tools (authenticate, connect, marketplace, etc.) are separate and easily distinguishable.
The naming is inconsistent: Garmin tools use a consistent 'garmin_verb_noun' pattern, but the platform tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) lack any prefix or pattern, creating a mismatch.
With 16 tools, the count is slightly above the typical sweet spot but still justified. The domain of workout management requires several operations, and the platform utilities are essential for the server's operation within the MCP ecosystem.
The Garmin workout tools cover the full lifecycle: create, retrieve, update, delete, plus scheduling. Listing accounts and the platform utilities round out the surface. Minor gaps (e.g., no tool to fetch activities) are acceptable given the server's focus on 'treinos' (workouts).
authenticateAMCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and non-destructive. Description adds context about permanent vs session authentication, but doesn't explicitly state state-changing behavior or idempotence benefit. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences: first states purpose, second explains best practice, third explains the two usage modes. No wasted words, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, no output schema), the description covers usage and parameters well. It lacks explicit success/failure behavior, but is otherwise complete for an auth tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for the single optional parameter 'token'. Description fully compensates by explaining the token is a JWT and how to use it in both modes (no args for link, token argument for session).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for authentication, specifying the verb 'log in' and resource 'access token'. It distinguishes from siblings as the sole authentication tool among many garmin and other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two usage modes: permanent config vs session-only via token. It provides clear context but lacks explicit when-not-to-use guidance, though no alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connectAReturns connection status and URLs. When all providers are connected, returns authenticated:true and empty pending[]. When credentials are missing, returns connect_url for the toolkit and per-install URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safety profile (readOnly, idempotent). Description adds meaningful response details (authenticated flag, URLs) 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded, no wasted words. Efficiently conveys core behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool, description covers both major states and output characteristics. Could mention any prerequisites or error scenarios, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description does not need to add parameter info. Baseline 4 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns connection status and URLs, with specific distinctions between connected and missing credentials states. However, could more explicitly contrast with sibling 'authenticate' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as a status check, but no explicit guidance on when to use versus other tools like 'authenticate' or 'connect' alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_delete_workoutBInspectDelete a workout template from Garmin Connect by workout_id.
Bulk support: accepts workout_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| workout_id | Yes | ||
| workout_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims a destructive operation ('delete'), but annotations set destructiveHint: false, creating a contradiction. No disclosure of consequences, permissions, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with verb and resource, no wasted words. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description covers core usage but omits return value, error handling, and prerequisites. Barely adequate for a simple deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% globally, but the description adds meaning: 'by workout_id' clarifies the required parameter, and 'accepts workout_ids for batched execution' explains the array parameter. The 'account' parameter remains undocumented, but overall the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'workout template', and distinguishes from siblings like garmin_edit_workout and garmin_get_workout by specifying bulk support via workout_ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like garmin_unschedule_workout. The description implies use for deletion but lacks context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_edit_workoutBInspectReplace a workout: uploads a new workout from payload, then deletes workout_id (no native PUT). Returns new workout_id and previous_workout_id.
Bulk support: accepts workout_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| workout | Yes | ||
| workout_id | Yes | ||
| workout_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description says it deletes the old workout, contradicting the destructiveHint=false annotation. This is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff, front-loaded with the core mechanism. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on error cases, order of bulk execution, structure of the workout object, and handling of missing workouts. No output schema to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Clarifies workout_id, workout, and workout_ids, but ignores the 'account' parameter entirely. With 0% schema description coverage, the description should cover all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it replaces a workout by uploading a new one then deleting the old, with bulk support. Distinguishes from sibling tools like garmin_delete_workout and garmin_get_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (no native PUT) and mentions bulk support, but could better contrast with alternatives like garmin_submit_workout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_get_scheduled_workoutAGet one scheduled workout entry by scheduled_workout_id.
Bulk support: accepts scheduled_workout_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| scheduled_workout_id | Yes | ||
| scheduled_workout_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the bulk execution capability, which is a key behavioral trait beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences, no fluff. First sentence defines primary function, second adds bulk support. Ideal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with good annotations, the description covers the core action and bulk variant. However, it omits return format or what constitutes a 'scheduled workout entry', which could be important given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must explain parameters. It names 'scheduled_workout_id' and 'scheduled_workout_ids', but the 'account' parameter is left undocumented. This partial coverage is better than nothing but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves one scheduled workout by ID, with bulk support. However, it does not explicitly differentiate from similar siblings like garmin_get_workout or garmin_list_scheduled_workouts, leaving the agent to infer based on the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one or multiple scheduled workouts by ID, but lacks guidance on when to prefer this over list or other get variants. No exclusions or context about prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_get_workoutAGet one workout template by workout_id (full structure: segments, steps, targets). Includes raw_data JSON string.
Bulk support: accepts workout_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| workout_id | Yes | ||
| workout_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by detailing the response structure (segments, steps, targets) and the inclusion of a raw_data JSON string. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no fluff. The first sentence immediately conveys the core purpose, and the second sentence adds bulk support context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description adequately covers what the tool returns and its bulk capability. It does not specify error handling or authentication needs, but the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the use of workout_id and workout_ids, but fails to mention the account parameter. With 0% schema description coverage, the description must fully compensate; the omission of account leaves meaning incomplete for this optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a workout template by ID, specifying it returns the full structure including segments, steps, and targets, and mentions bulk support. This distinguishes it from sibling tools like garmin_list_workouts or garmin_delete_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by noting that it can retrieve a single workout via workout_id or multiple via workout_ids for batched execution. It does not explicitly state when not to use or contrast with alternatives, but the guidance is sufficient for a read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_list_accountsAList all Garmin logins linked to this install (id, email, label, created_at).
| Name | Required | Description | Default |
|---|---|---|---|
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds that the tool lists 'all Garmin logins' but does not disclose additional behavioral traits (e.g., authentication requirements, caching). With annotations present, the description provides adequate but minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the purpose and key fields without extra verbiage. It is front-loaded with the action and is highly efficient, earning its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation, and the description covers the resource and output fields explicitly. There is no output schema, but the fields are enumerated. Minor gaps exist (e.g., no mention of pagination or limits), but overall the description is sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single optional parameter 'account'. The description does not explain the parameter's purpose or how it affects the list. The description focuses on the output fields, leaving parameter semantics completely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool lists all Garmin logins linked to the install, including the fields returned (id, email, label, created_at). The verb 'List' and resource 'Garmin logins' are specific, distinguishing it from sibling tools focused on authentication or workouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing linked accounts but lacks explicit when-to-use or when-not-to-use guidance. Sibling tool names (e.g., authenticate, connect, garmin_list_workouts) provide context, but the description does not directly address alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_list_scheduled_workoutsAList calendar scheduled workouts for a given month/year from Garmin calendar-service.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| month | Yes | ||
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint (all safe). Description adds minimal behavioral context: it lists from 'Garmin calendar-service' for a given month/year. No extra details on pagination, rate limits, or auth requirements beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words. No fluff, front-loaded with action and scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (read-only list, no output schema), the description tells what the tool returns (list of scheduled workouts) and for what period. However, it omits output format details, behavior when no workouts found, and purpose of the account parameter. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions 'month/year' which maps to two required params, but does not explain the optional 'account' parameter. No parameter descriptions in schema either, so meaning of 'account' is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (list), resource (calendar scheduled workouts), and scope (for a given month/year from Garmin calendar-service). Among siblings, it distinguishes itself from garmin_get_scheduled_workout (singular) and garmin_list_workouts (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for listing by month/year, but does not explicitly state when to use this vs alternatives like garmin_get_scheduled_workout or garmin_list_workouts. No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_list_workoutsBList saved workouts from Garmin Connect (workout-service). Returns summaries plus raw_data (full JSON string from Garmin).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| start | No | ||
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent hints, so the description adds modest value by mentioning raw_data return. No additional behavioral details (e.g., rate limits, data freshness) beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are concise and front-loaded: the first states the core action and source, the second adds key detail about return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, and no param descriptions, the description is insufficient for correct invocation. Missing pagination context, account significance, and output structure beyond 'summaries plus raw_data'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any parameters (limit, start, account). It fails to add meaning beyond the property names and types, leaving the agent to guess semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists saved workouts from Garmin Connect and returns summaries plus raw_data. This specifies the action and resource, distinguishing it from sibling tools like garmin_get_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 garmin_get_scheduled_workout or filtering options. The description lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_schedule_workoutBInspectSchedule an existing workout onto the calendar. date must be YYYY-MM-DD (or ISO-8601 date prefix). Returns Garmin schedule response as raw_data.
Bulk support: accepts workout_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| account | No | ||
| workout_id | Yes | ||
| workout_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks details about behavioral traits beyond annotations. Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description does not explain potential side effects, required permissions, or error conditions. The mention of 'raw_data' response is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the main purpose and date format. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of multiple sibling tools and the lack of output schema, the description is incomplete. It does not clarify error handling, prerequisites (e.g., workout must exist), or the structure of the response. The bulk support mention is helpful but leaves many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for date (format) and workout_ids (bulk support), but does not describe account or workout_id beyond their names. Overall, it provides partial but not complete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (schedule an existing workout onto the calendar) and specifies the date format. However, it does not explicitly distinguish this from sibling tools like garmin_submit_workout, though the action of scheduling vs submitting is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a format guideline for the date parameter and mentions bulk support for workout_ids, but it does not give guidance on when to use this tool versus alternatives, such as when to use garmin_schedule_workout vs garmin_unschedule_workout or garmin_submit_workout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_submit_workoutAInspectCreate a new structured workout on Garmin Connect. Body must match Garmin API (workoutName, sportType, workoutSegments with ExecutableStepDTO / RepeatGroupDTO). You may omit displayOrder/displayable everywhere and the endCondition on RepeatGroupDTO — the server normalizes them automatically (see workout.description). Multi-sport: sportTypeKey multi_sport (typically sportTypeId 5) with one segment per discipline. Returns workout_id and raw_data.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| workout | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses server normalization of omitted fields and automatic handling of certain properties, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise (3 sentences) and front-loaded, though could be more structured with bullets. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers complex nesting and multi-sport scenarios. Notes return value despite no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains the 'workout' parameter structure in detail, including DTO names and multi-sport specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new structured workout') and the resource ('on Garmin Connect').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on body structure, omittable fields, and multi-sport handling. Implicitly distinguishes from create/edit/delete siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
garmin_unschedule_workoutAInspectRemove workout from calendar by scheduled_workout_id (does not delete the workout template).
Bulk support: accepts scheduled_workout_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| scheduled_workout_id | Yes | ||
| scheduled_workout_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that unscheduling does not delete the template, aligning with annotations. However, no further behavioral traits like authorization needs or side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no filler. Every sentence adds value: first explains core action, second notes bulk capability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and minimal annotations, the description adequately covers the primary action and bulk support but omits details about the account parameter, return behavior, or prerequisites, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the purpose of scheduled_workout_id and the bulk support via scheduled_workout_ids. However, the account parameter is left undocumented, imposing an information gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove workout from calendar by scheduled_workout_id' and differentiates it from deleting the workout template, distinguishing it from sibling tool garmin_delete_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for what the tool does and does not do (does not delete template), but does not explicitly state when to use it instead of alternatives like garmin_delete_workout or garmin_schedule_workout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketplaceAInspectThe official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them. Covers capability requests like "find an MCP that does X", "consulta um CPF", "is there a tool for Y". Core flow: action=search discovers MCPs by intent → describe returns one MCP's full profile (every tool with its id + params, pricing, auth) so you pick the right tool_id → invoke RUNS that tool. KEY: invoke works even when the MCP is NOT installed — it runs the tool pontualmente (one-off), without adding the MCP to the toolkit and without bloating the tool list. If the MCP needs a credential/login, invoke returns a connect link; if it is paid and the wallet is empty, invoke returns a checkout/top-up link (the user opens it, then you retry). Use install only to make an MCP PERMANENT in the active toolkit (its tools then show up natively in future sessions); prefer invoke for a single/occasional use. list_tools lists what is callable right now. subscribe/cancel handle per-MCP billing; report_bug sends feedback; request_mcp asks us to build a NEW MCP when nothing fits. Search/describe flag installed_in_toolkit vs installed_in_workspace. Writes (install/uninstall/subscribe/cancel and the one-off install behind invoke) require workspace owner/admin. It also carries the mcp.ai PROMPT LIBRARY, which is about ready-made prompt TEXT rather than MCPs: search_prompts finds one, get_prompt returns its full text with {{variables}} filled, and publish_prompt saves a prompt and returns a shareable mcp.ai/p/ link that opens without login.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| action | No | search | |
| mcp_id | No | ||
| message | No | ||
| tool_id | No | ||
| arguments | No | {} | |
| immediate | No | ||
| tier_slug | No | ||
| prompt_body | No | ||
| prompt_slug | No | ||
| prompt_tool | No | ||
| prompt_vars | No | {} | |
| conversation | No | [] | |
| prompt_title | No | ||
| request_name | No | ||
| cancel_reason | No | ||
| cancel_comment | No | ||
| prompt_targets | No | ||
| report_context | No | ||
| prompt_category | No | ||
| request_details | No | ||
| prompt_description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=false and no destructiveness hint, but the description adds rich behavioral context: invoke works even when the MCP is not installed, runs one-off without bloating the toolkit, returns connect/checkout links for auth/billing, and writes require workspace owner/admin. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place, covering many actions and edge cases without padding. It front-loads the core purpose and uses a flow-based structure that aids comprehension, though it could be more scannable with bullet points or section breaks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 23 parameters, 14 actions, and no output schema, the description covers the core conceptual model, including billing/auth fallbacks, install vs invoke distinction, and the prompt library. Missing parameter-level details for some actions and no mention of list/search return shapes, but the essential workflow is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It explains the action enum semantics and key parameters (action, mcp_id, tool_id, prompt_slug) through the described flow. However, it does not explain many other parameters (limit, query, tier_slug, immediate, conversation, cancel_reason), leaving the agent to infer their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It outlines specific capability requests and a core flow (search → describe → invoke), distinguishing it from sibling tools like connect, authenticate, and the garmin-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is pervasive: 'prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT in the active toolkit', and alternatives are named ('list_tools lists what is callable right now', 'report_bug sends feedback', 'request_mcp asks us to build a NEW MCP').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_bugBReport a bug, missing feature, or send feedback. Include the conversation array with recent messages for reproduction.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| message | Yes | ||
| conversation | No | [] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency and non-destructiveness. The description adds that the conversation array should be included for reproduction, which is useful behavioral context. However, it does not disclose any side effects or permission requirements beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Extremely concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple bug-reporting tool with no output schema and basic parameters, the description is adequate but lacks detail on parameter usage beyond conversation. It leaves some gaps but is sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains one of three parameters (conversation) by stating its purpose for reproduction, but does not describe 'message' or 'context' parameters. This leaves significant ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for reporting bugs, missing features, or feedback, using a specific verb+resource. It distinguishes itself from sibling tools (mostly Garmin-related) by its unique purpose, though it does not explicitly compare with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool versus alternatives. The description simply states what it does but lacks context on prerequisites, when to choose it over other tools, or 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.
show_versionAShow the current MCP platform and adapter versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior. The description adds the specific version details (MCP platform and adapter) but doesn't disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and result, with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with full annotation coverage, the description sufficiently covers the tool's purpose and behavior. No output schema exists, but the return value (version info) is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters; the description doesn't need to add parameter meaning. Baseline score of 4 is appropriate per evaluation guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Show') and resource ('MCP platform and adapter versions'). It distinguishes itself from siblings that cover authentication, workout management, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of showing version information is self-evident. While no explicit when-to-use or exclusion criteria are provided, the tool's simplicity and uniqueness among siblings make guidelines unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_infoAReturns the current toolkit state: installed MCPs, their connection status, the accounts connected to each one, and how many catalog tools each exposes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description is consistent with these, adding detail on return content but no further behavioral context like rate limits or data freshness. It meets the minimum bar but doesn't enrich beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and then lists the returned components. Every clause adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only info tool with no parameters and no output schema, the description fully specifies the tool's scope and output. An agent can confidently decide when and how to invoke this tool based on the provided detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. The description adds clarity about what the returned state includes, which is useful given no parameter details are needed. Baseline for 0 params is 4 and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Returns') and identifies the resource ('current toolkit state'). It enumerates the specific content returned (installed MCPs, connection status, connected accounts, catalog tool counts), which distinguishes it from sibling tools like authenticate or list_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: call this to inspect toolkit state. It doesn't explicitly mention when not to use it or name alternative tools, but the context is obvious from the description and sibling list. A strong but not fully explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.