Skip to main content
Glama

get_azm_timeseries

Retrieve Active Zone Minutes time series data from Fitbit, including total minutes and breakdown by fat burn, cardio, and peak zones for a specified date range.

Instructions

Get the raw JSON response for Active Zone Minutes (AZM) time series data from Fitbit over a date range (max 1095 days). Returns total AZM plus breakdown by fat burn, cardio, and peak zones.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
startDateYesThe start date for which to retrieve data (YYYY-MM-DD)
endDateYesThe end date for which to retrieve data (YYYY-MM-DD)

Implementation Reference

  • Handler function that constructs the specific API endpoint for Active Zone Minutes (AZM) time series and invokes the shared handleFitbitApiCall utility to fetch data from Fitbit.
    handler: async ({ startDate, endDate }: AzmTimeSeriesParams) => {
      const endpoint = `activities/active-zone-minutes/date/${startDate}/${endDate}.json`;
      
      return handleFitbitApiCall<AzmTimeSeriesResponse, AzmTimeSeriesParams>(
        endpoint,
        { startDate, endDate },
        getAccessTokenFn,
        {
          errorContext: `AZM data from ${startDate} to ${endDate}`
        }
      );
    }
  • Parameter type definition (AzmTimeSeriesParams) and input schema using shared CommonSchemas for startDate and endDate validation.
    type AzmTimeSeriesParams = Pick<CommonParams, 'startDate' | 'endDate'>;
    
    registerTool(server, {
      name: 'get_azm_timeseries',
      description: "Get the raw JSON response for Active Zone Minutes (AZM) time series data from Fitbit over a date range (max 1095 days). Returns total AZM plus breakdown by fat burn, cardio, and peak zones.",
      parametersSchema: {
        startDate: CommonSchemas.startDate,
        endDate: CommonSchemas.endDate,
      },
  • Module-level registration function that configures and registers the get_azm_timeseries tool with the MCP server.
    export function registerAzmTimeSeriesTool(
      server: McpServer,
      getAccessTokenFn: () => Promise<string | null>
    ): void {
      type AzmTimeSeriesParams = Pick<CommonParams, 'startDate' | 'endDate'>;
    
      registerTool(server, {
        name: 'get_azm_timeseries',
        description: "Get the raw JSON response for Active Zone Minutes (AZM) time series data from Fitbit over a date range (max 1095 days). Returns total AZM plus breakdown by fat burn, cardio, and peak zones.",
        parametersSchema: {
          startDate: CommonSchemas.startDate,
          endDate: CommonSchemas.endDate,
        },
        handler: async ({ startDate, endDate }: AzmTimeSeriesParams) => {
          const endpoint = `activities/active-zone-minutes/date/${startDate}/${endDate}.json`;
          
          return handleFitbitApiCall<AzmTimeSeriesResponse, AzmTimeSeriesParams>(
            endpoint,
            { startDate, endDate },
            getAccessTokenFn,
            {
              errorContext: `AZM data from ${startDate} to ${endDate}`
            }
          );
        }
      });
    }
  • src/index.ts:86-86 (registration)
    Invocation of the tool registration during MCP server setup in the main entry point.
    registerAzmTimeSeriesTool(server, getAccessToken);
  • Core helper function used by the tool handler to perform the Fitbit API request, handle errors, and format the MCP tool response.
    export async function handleFitbitApiCall<TResponse, TParams>(
      endpoint: string,
      params: TParams,
      getAccessTokenFn: () => Promise<string | null>,
      options: {
        apiBase?: string;
        successDataExtractor?: (data: TResponse) => unknown[] | null;
        noDataMessage?: string;
        errorContext?: string;
      } = {}
    ): Promise<ToolResponseStructure> {
      const {
        apiBase = FITBIT_API_VERSIONS.V1,
        successDataExtractor,
        noDataMessage,
        errorContext = JSON.stringify(params)
      } = options;
    
      const responseData = await makeFitbitRequest<TResponse>(
        endpoint,
        getAccessTokenFn,
        apiBase
      );
    
      if (!responseData) {
        return createErrorResponse(
          `${ERROR_MESSAGES.API_REQUEST_FAILED} for ${errorContext}. ${ERROR_MESSAGES.CHECK_TOKEN_PERMISSIONS}.`
        );
      }
    
      // Check for empty data if extractor provided
      if (successDataExtractor) {
        const extractedData = successDataExtractor(responseData);
        if (!extractedData || extractedData.length === 0) {
          return createNoDataResponse(noDataMessage || errorContext);
        }
      }
    
      return createSuccessResponse(responseData);
    }
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns 'raw JSON response' and specifies the 1095-day maximum range, which adds useful context beyond the schema. However, it doesn't cover other behavioral aspects like authentication requirements, rate limits, error conditions, or pagination, leaving gaps for a read operation.

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?

The description is a single, well-structured sentence that efficiently conveys purpose, scope, and return value. It is front-loaded with the core action and resource, followed by constraints and output details, with zero wasted words or redundancy.

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

Completeness3/5

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and output format but lacks details on authentication, error handling, or sibling tool differentiation, which would be helpful for an AI agent to use it correctly in context.

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?

Schema description coverage is 100%, with both parameters (startDate, endDate) fully documented in the schema. The description adds no additional parameter semantics beyond implying date-range filtering, so it meets the baseline of 3 without compensating for any gaps, as none exist in the schema.

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 specific action ('Get the raw JSON response'), resource ('Active Zone Minutes (AZM) time series data from Fitbit'), and scope ('over a date range (max 1095 days)'). It distinguishes from siblings by specifying AZM data rather than activity goals, exercises, sleep, etc., making the purpose unambiguous.

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?

The description implies usage for retrieving AZM time series data within a date range, but provides no explicit guidance on when to use this tool versus alternatives like 'get_activity_timeseries' or 'get_daily_activity_summary'. It mentions the 1095-day limit, which is helpful context, but lacks sibling differentiation or exclusion 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/TheDigitalNinja/mcp-fitbit'

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