Skip to main content
Glama

get-activity-hr-zones

Retrieve the heart rate time-in-zone breakdown for any Garmin activity. Analyze time spent in each heart rate zone using your activity ID.

Instructions

Get heart rate time-in-zone breakdown for an activity

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
activityIdYesThe activity ID

Implementation Reference

  • src/tools.ts:211-223 (registration)
    The tool 'get-activity-hr-zones' is registered via `server.tool()` with a Zod schema expecting 'activityId' (string). The handler calls `client.get('activity-service/activity/${activityId}/hrTimeInZones')` and returns the JSON result.
    server.tool(
      "get-activity-hr-zones",
      "Get heart rate time-in-zone breakdown for an activity",
      {
        activityId: z.string().describe("The activity ID"),
      },
      async ({ activityId }) => {
        const client = getClient();
        const data = await client.get(
          `activity-service/activity/${activityId}/hrTimeInZones`
        );
        return jsonResult(data);
      }
  • The handler function for 'get-activity-hr-zones': receives { activityId }, calls the Garmin API endpoint 'activity-service/activity/${activityId}/hrTimeInZones' via the shared client, and returns the data as JSON.
    async ({ activityId }) => {
      const client = getClient();
      const data = await client.get(
        `activity-service/activity/${activityId}/hrTimeInZones`
      );
      return jsonResult(data);
    }
  • Input schema: { activityId: z.string() } - a single required string parameter describing the activity ID.
    {
      activityId: z.string().describe("The activity ID"),
    },
  • The jsonResult helper function used by the handler to wrap API response data into MCP-compatible content format.
    function jsonResult(data: unknown) {
      return {
        content: [{ type: "text" as const, text: JSON.stringify(data, null, 2) }],
      };
    }
  • The getClient helper function that checks for an existing Garmin session and returns the shared HTTP client used in the handler.
    function getClient() {
      if (!sessionExists()) {
        throw new Error(
          "No Garmin session found. The user needs to run: npx garmin-connect-mcp login"
        );
      }
      return getSharedClient();
    }
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get' which implies a read operation, but does not detail what the breakdown contains (e.g., zone names, durations), any prerequisites (e.g., activity must have HR data), or whether modifications occur. Significant gaps exist.

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 a single sentence of 8 words, conveying the core purpose without redundancy. It is appropriately sized but lacks supplementary structure (e.g., bullet points) that could improve scanning.

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

Completeness2/5

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

Given no output schema and low annotation coverage, the description should explain what the tool returns (e.g., zone durations, percentages). It omits crucial details about the breakdown format, making it insufficient for an agent to fully understand the output.

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

Parameters3/5

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

The schema covers the single parameter with a description ('The activity ID'), so baseline is 3. The tool description adds no extra meaning beyond what the schema already provides, so no improvement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves 'heart rate time-in-zone breakdown for an activity', specifying both the resource (heart rate zones) and the scope (per activity). This distinguishes it from sibling tools like get-daily-heart-rate or get-hr-zones-config.

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. For example, it does not mention that get-hr-zones-config is for configuration or that get-daily-heart-rate is for daily summaries. The description is silent on selection criteria.

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

Install Server

Other Tools

Latest Blog Posts

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/etweisberg/garmin-connect-mcp'

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