Skip to main content
Glama
Sign In
garminconnect-js

garminconnect-js

by DynamicsNinja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_in_progress_badges

Read-only

Retrieve Garmin Connect badges that are still in progress by merging earned and available badge lists and filtering for partial completion.

Instructions

Badges with progress towards them, from the earned and available lists. No HTTP path of its own: calls getEarnedBadges() and getAvailableBadges(), filters each with an in-progress predicate (progress truthy; if progress === target, only "in progress" when badgeLimitCount is set and badgeEarnedNumber < badgeLimitCount), then merges both filtered lists into a Map keyed by badgeId (available overwrites earned on collision, keeping the earned entry's position); never raises: a null from either call is treated as []. Badges carry badgeImageUrls (inherited from the two calls).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_in_progress_badges"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only supply readOnlyHint and openWorldHint, so the description carries most of the behavioral burden and does so well: it discloses that the tool never raises (null from either call becomes []), how collisions resolve (available overwrites earned but keeps the earned position), and that badgeImageUrls is inherited. The remaining gap is that it describes internal mechanics more than agent-facing behavior such as result size or typical progress values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause, but the body is one very long compound sentence dense with implementation detail (progress truthy, progress === target, badgeLimitCount/badgeEarnedNumber comparison). Much of this reads as internal source-level logic rather than guidance the agent needs to select or call the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must explain the return shape and it does: a Map keyed by badgeId, plus the presence of badgeImageUrls. Combined with the never-raises guarantee and merge semantics, an agent has everything needed to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. The schema is empty and closed (additionalProperties: false), consistent with the no-argument contract implied by the description.

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 opening clause states a specific resource and scope: badges with progress towards them, drawn from the earned and available lists. This clearly distinguishes it from siblings get_earned_badges and get_available_badges, since it names both as its inputs and defines itself as the merged/derived view.

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?

Usage is implied rather than stated – an agent can infer this is the tool to call when it wants only in-progress badges rather than full earned/available lists, because the description spells out the filtering predicate. However, there is no explicit when-to-use vs. the two sibling calls it wraps, and no exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools