Skip to main content
Glama

list_recovery

Retrieve daily recovery and HRV summaries (score, stress, readiness) for each day in a date range, ordered chronologically.

Instructions

Returns recovery and HRV summaries for each day in [from, to] inclusive, ordered chronologically. Each entry: { date, recoveryScore (0–100), hrv (ms, rMSSD), stressLevel, readiness }. Days without recovery data are omitted. Use get_recovery for a single day. Requires Recovery API subscription on apizone; returns 404 without it. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromYesStart date YYYY-MM-DD, inclusive. Must be ≤ to. Days without recovery data are silently omitted, not 404.
toYesEnd date YYYY-MM-DD, inclusive. Future dates are accepted but produce no entries. Prefer ranges ≤ 30 days for responsiveness.

Implementation Reference

  • API method that executes the HTTP request to Suunto's recovery endpoint. Calls GET /v2/recovery?from=...&to=..., parses JSON, and sorts results chronologically by date.
    async listRecovery(from: string, to: string) {
      const q = new URLSearchParams({ from, to });
      const res = await this.json<any>(`${this.dailyPrefix()}/recovery?${q.toString()}`);
      return sortByDate(res);
    }
  • MCP tool handler that dispatches 'list_recovery' calls to suunto.listRecovery(a.from, a.to) and returns the result as formatted JSON text.
    case "list_recovery":
      return text(JSON.stringify(await suunto.listRecovery(a.from, a.to), null, 2));
  • Input schema definition for the 'list_recovery' tool: requires 'from' and 'to' date strings with YYYY-MM-DD format validation.
    {
      name: "list_recovery",
      description:
        "Returns recovery and HRV summaries for each day in [from, to] inclusive, ordered chronologically. Each entry: { date, recoveryScore (0–100), hrv (ms, rMSSD), stressLevel, readiness }. Days without recovery data are omitted. Use get_recovery for a single day. Requires Recovery API subscription on apizone; returns 404 without it. Read-only.",
      inputSchema: {
        type: "object",
        properties: {
          from: {
            type: "string",
            format: "date",
            pattern: "^\\d{4}-\\d{2}-\\d{2}$",
            minLength: 10,
            maxLength: 10,
            examples: ["2026-04-01"],
            description: "Start date YYYY-MM-DD, inclusive. Must be ≤ to. Days without recovery data are silently omitted, not 404.",
          },
          to: {
            type: "string",
            format: "date",
            pattern: "^\\d{4}-\\d{2}-\\d{2}$",
            minLength: 10,
            maxLength: 10,
            examples: ["2026-04-30"],
            description: "End date YYYY-MM-DD, inclusive. Future dates are accepted but produce no entries. Prefer ranges ≤ 30 days for responsiveness.",
          },
        },
        required: ["from", "to"],
      },
    },
  • src/index.ts:269-297 (registration)
    Tool registration entry in the tools array that defines name 'list_recovery', description, and inputSchema for the MCP server.
    {
      name: "list_recovery",
      description:
        "Returns recovery and HRV summaries for each day in [from, to] inclusive, ordered chronologically. Each entry: { date, recoveryScore (0–100), hrv (ms, rMSSD), stressLevel, readiness }. Days without recovery data are omitted. Use get_recovery for a single day. Requires Recovery API subscription on apizone; returns 404 without it. Read-only.",
      inputSchema: {
        type: "object",
        properties: {
          from: {
            type: "string",
            format: "date",
            pattern: "^\\d{4}-\\d{2}-\\d{2}$",
            minLength: 10,
            maxLength: 10,
            examples: ["2026-04-01"],
            description: "Start date YYYY-MM-DD, inclusive. Must be ≤ to. Days without recovery data are silently omitted, not 404.",
          },
          to: {
            type: "string",
            format: "date",
            pattern: "^\\d{4}-\\d{2}-\\d{2}$",
            minLength: 10,
            maxLength: 10,
            examples: ["2026-04-30"],
            description: "End date YYYY-MM-DD, inclusive. Future dates are accepted but produce no entries. Prefer ranges ≤ 30 days for responsiveness.",
          },
        },
        required: ["from", "to"],
      },
    },
  • src/cli.ts:149-160 (registration)
    CLI handler for 'list-recovery' command that parses --from and --to flags then calls suunto.listRecovery().
    case "list-recovery": {
      const { values } = parseArgs({
        args: rest,
        options: {
          from: { type: "string" },
          to: { type: "string" },
        },
      });
      if (!values.from || !values.to) die("Usage: list-recovery --from YYYY-MM-DD --to YYYY-MM-DD");
      out(await suunto.listRecovery(values.from!, values.to!));
      break;
    }
Behavior5/5

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

No annotations provided, so description carries full burden. Discloses read-only nature, omission of days without data, subscription dependency, future date behavior, and performance advisory for ≤30 day ranges.

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

Conciseness5/5

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

Concise at 4 sentences. Front-loaded main purpose, then details structure, alternative, subscription info, and caveats. No wasted words.

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

Completeness5/5

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

No output schema, but description fully explains output format and fields. Covers error conditions (404) and edge cases (future dates, omitted days). Complete for a date-range list tool.

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 coverage is 100% with clear parameter descriptions. Description adds inclusive range semantics, silent omission of days without data, future date behavior, and recommended range size.

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?

Clearly states it returns recovery and HRV summaries for each day in a date range, ordered chronologically. Distinguishes from sibling `get_recovery` by specifying it's for a range vs single day.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool (date range) and when to use alternative (`get_recovery` for single day). Mentions subscription requirement and 404 error case.

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/googlarz/suunto-mcp'

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