Skip to main content
Glama

list_daily_activity

Retrieve daily activity summaries including steps, calories, and heart rate for a date range. Omits days without synced data.

Instructions

Returns 24/7 activity summaries for each day in [from, to] inclusive, ordered chronologically. Each entry: { date, steps, activeCalories, totalCalories, avgHeartRate, minHeartRate, maxHeartRate, restingHeartRate }. Days where the watch did not sync are omitted from the result. Use get_daily_activity for a single day. Requires Activity 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 synced 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

  • The `listDailyActivity` method on the SuuntoClient class executes the core logic: it constructs a URL with `from` and `to` query parameters, calls the Suunto API endpoint `/v2/activity`, and sorts results chronologically by the `date` field.
    async listDailyActivity(from: string, to: string) {
      const q = new URLSearchParams({ from, to });
      const res = await this.json<any>(`${this.dailyPrefix()}/activity?${q.toString()}`);
      return sortByDate(res);
    }
  • MCP tool schema registration for `list_daily_activity`: defines the tool description and inputSchema with `from` (required start date) and `to` (required end date) parameters, both YYYY-MM-DD format.
    {
      name: "list_daily_activity",
      description:
        "Returns 24/7 activity summaries for each day in [from, to] inclusive, ordered chronologically. Each entry: { date, steps, activeCalories, totalCalories, avgHeartRate, minHeartRate, maxHeartRate, restingHeartRate }. Days where the watch did not sync are omitted from the result. Use get_daily_activity for a single day. Requires Activity 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 synced 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:345-348 (registration)
    MCP handler routing: the `list_daily_activity` case in the switch statement that calls `suunto.listDailyActivity(a.from, a.to)` and returns the JSON-stringified result.
    case "list_daily_activity":
      return text(
        JSON.stringify(await suunto.listDailyActivity(a.from, a.to), null, 2),
      );
  • CLI wrapper for `list-daily-activity`: parses `--from` and `--to` arguments and delegates to `suunto.listDailyActivity()`.
    case "list-daily-activity": {
      const { values } = parseArgs({
        args: rest,
        options: {
          from: { type: "string" },
          to: { type: "string" },
        },
      });
      if (!values.from || !values.to) die("Usage: list-daily-activity --from YYYY-MM-DD --to YYYY-MM-DD");
      out(await suunto.listDailyActivity(values.from!, values.to!));
      break;
Behavior5/5

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

Discloses read-only nature, omission of unsynced days, acceptance of future dates, and 404 without subscription. No annotations, so description carries full burden and does so thoroughly.

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?

Single paragraph front-loads purpose and structure. Every sentence adds value, no redundancy.

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?

Complete for a list tool with 2 params and no output schema: covers output structure, edge cases, errors, and sibling distinction.

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 covers 100% of parameters. Description adds meaning: from unsynced days silently omitted, to future dates produce no entries, and recommends ≤30 days.

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 returns daily activity summaries for a date range, lists the fields, and distinguishes from the sibling get_daily_activity for single-day queries.

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?

Explicit guidance on when to use this vs. get_daily_activity, mentions omission of unsynced days, accepts future dates, suggests ≤30 day ranges, and notes subscription requirement returning 404.

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