The Fitbit MCP Server acts as a bridge between an LLM (like Claude) and the Fitbit API, enabling health and fitness data retrieval for the user.
Capabilities:
Retrieve Weight Data: Fetch weight data for specified periods (1d, 7d, 30d, 3m, 6m, 1y)
Retrieve Sleep Data: Access sleep logs for specific date ranges (max 100 days) using YYYY-MM-DD format
Retrieve Profile Information: Get user's Fitbit profile including personal details like name, age, gender, height, and weight
The server uses OAuth 2.0 for secure authentication and is designed to be extensible for adding more Fitbit API endpoints in the future.
Retrieves health and fitness data from a user's Fitbit account, including weight measurements, sleep logs, and user profile information. Currently supports endpoints for weight data by period, sleep data by date range, and profile details, with planned support for steps, heart rate, and activity data.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fitbit MCP Server show me my sleep patterns from last week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect AI assistants to your Fitbit health data
Give your AI assistant access to your Fitbit data for personalized health insights, trend analysis, and automated tracking. Works with Claude Desktop and other MCP-compatible AI tools.
🏃 Exercise & Activities - Get detailed workout logs and activity data
😴 Sleep Analysis - Retrieve sleep patterns and quality metrics
⚖️ Weight Tracking - Access weight trends over time
❤️ Heart Rate Data - Monitor heart rate patterns and zones
🍎 Nutrition Logs - Review food intake, calories, and macros
👤 Profile Info - Access basic Fitbit profile details
Ask your AI things like: "Show me my sleep patterns this week" or "What's my average heart rate during workouts?"
Related MCP server: coros-mcp
🚀 Want to test the tools right away?
Create an app with OAuth 2.0 Application Type: Personal
Set Callback URL: http://localhost:3000/callback
Note your Client ID and Client Secret
Install the package globally:
npm install -g mcp-fitbitAdd to your Claude Desktop config file:
{
"mcpServers": {
"fitbit": {
"command": "mcp-fitbit",
"args": [],
"env": {
"FITBIT_CLIENT_ID": "your_client_id_here",
"FITBIT_CLIENT_SECRET": "your_client_secret_here"
}
}
}
}Config file location:
Windows: %AppData%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Restart Claude Desktop and ask about your Fitbit data!
Get Fitbit API credentials (see Installation below)
Then run:
git clone https://github.com/TheDigitalNinja/mcp-fitbit
cd mcp-fitbit
npm install
# Create .env with your Fitbit credentials
npm run devBoth options open the MCP Inspector at http://localhost:5173 where you can test all tools interactively and handle the OAuth flow.
Get Fitbit API credentials at dev.fitbit.com
Set OAuth 2.0 Application Type to Personal
Set Callback URL to http://localhost:3000/callback
Install the package:
npm install -g mcp-fitbitCreate .env file in the package directory:
When you run mcp-fitbit for the first time, it will tell you exactly where to create the .env file. It will look something like:
C:\Users\YourName\AppData\Roaming\npm\node_modules\mcp-fitbit\.envAdd your credentials to the .env file:
FITBIT_CLIENT_ID=your_client_id_here
FITBIT_CLIENT_SECRET=your_client_secret_hereRun the server:
mcp-fitbitGet Fitbit API credentials at dev.fitbit.com
Set OAuth 2.0 Application Type to Personal
Set Callback URL to http://localhost:3000/callback
Clone and setup:
git clone https://github.com/TheDigitalNinja/mcp-fitbit
cd mcp-fitbit
npm installCreate .env file:
FITBIT_CLIENT_ID=your_client_id_here
FITBIT_CLIENT_SECRET=your_client_secret_hereBuild the server:
npm run buildTool | Description | Parameters |
| Weight data over time periods |
|
| Sleep logs for date range (max 100 days) |
|
| Activity/exercise logs after date |
|
| Daily activity summary with goals |
|
| User's activity goals (daily/weekly) |
|
| Activity time series data (max 30 days) |
|
| Active Zone Minutes time series (max 1095 days) |
|
| Heart rate for time period |
|
| Heart rate for date range (max 1 year) |
|
| Complete nutrition data for a day |
|
| Individual nutrient over time |
|
| Individual nutrient for date range |
|
| User profile information | None |
Nutrition resources: caloriesIn, water, protein, carbs, fat, fiber, sodium
Activity time series resources: steps, distance, calories, activityCalories, caloriesBMR, tracker/activityCalories, tracker/calories, tracker/distance
Using npm package (recommended):
Add to claude_desktop_config.json:
{
"mcpServers": {
"fitbit": {
"command": "mcp-fitbit",
"args": []
}
}
}Using local development version:
Add to claude_desktop_config.json:
{
"mcpServers": {
"fitbit": {
"command": "node",
"args": ["C:\\path\\to\\mcp-fitbit\\build\\index.js"]
}
}
}Config file locations:
Windows: %AppData%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
When you first ask your AI assistant to use Fitbit data:
The server opens your browser to http://localhost:3000/auth
Log in to Fitbit and grant permissions
You'll be redirected to a success page
Your AI can now access your Fitbit data!
npm run lint # Check code quality
npm run format # Fix formatting
npm run build # Compile TypeScript
npm run dev # Run with MCP inspectorArchitecture: See TASKS.md for improvement opportunities and technical details.
Get the raw JSON response for user's activity goals from Fitbit. Supports 'daily' and 'weekly' periods. Returns goal values for steps, distance, calories, floors, active minutes, and active zone minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| period | Yes | Goal period - either 'daily' or 'weekly' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. It mentions 'raw JSON response' but lacks details on read-only nature, authentication needs, rate limits, or error handling. This is insufficient for a safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence states purpose and format, second lists what is returned. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description lists the returned goal values but lacks details on response structure, error cases, or usage context. It is adequate but not complete for an agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, with description and enum. The tool description adds that it supports 'daily' and 'weekly' periods, which overlaps with schema. No additional semantic value beyond schema is provided, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get', the resource 'user's activity goals from Fitbit', and lists the returned fields (steps, distance, etc.). It distinguishes from sibling tools that handle timeseries or summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for retrieving goal settings, but does not compare to siblings like get_activity_timeseries or provide conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for activity time series data from Fitbit over a date range (max 30 days). Supports various resource paths like 'steps', 'distance', 'calories', 'activityCalories', 'caloriesBMR'.
| Name | Required | Description | Default |
|---|---|---|---|
| resourcePath | Yes | Activity resource to retrieve (e.g., 'steps', 'distance', 'calories') | |
| startDate | Yes | The start date for which to retrieve data (YYYY-MM-DD) | |
| endDate | Yes | The end date for which to retrieve data (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns raw JSON and imposes a 30-day max range. However, it does not mention whether the operation is read-only, authentication requirements, rate limits, or other behavioral traits that would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences, front-loaded with the core purpose. Every element is necessary, and there is no redundancy. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 required parameters and no output schema, the description adequately covers the tool's function, return format, date constraint, and supported resource paths. It is complete enough for most use cases, though a more detailed explanation of the output structure could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with descriptions for all three parameters. The description adds examples for resourcePath but does not provide additional semantic information for startDate or endDate beyond what the schema already defines. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'raw JSON response for activity time series data from Fitbit over a date range (max 30 days)'. It lists specific resource paths like 'steps', 'distance', etc., which distinguishes it from sibling tools that focus on goals, daily summaries, or other specific data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving time series data over a date range, but it does not provide explicit guidance on when to use this tool versus alternatives such as get_daily_activity_summary or get_heart_rate_by_date_range. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | Yes | The start date for which to retrieve data (YYYY-MM-DD) | |
| endDate | Yes | The end date for which to retrieve data (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool returns raw JSON and has a 1095-day max range, but does not cover authentication, rate limits, or side effects. The description adds some behavioral context but is not comprehensive for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with purpose, and contains no extraneous words. Every sentence adds value: first sentence states the action and resource, second details return composition. It is properly sized for the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (total AZM plus breakdown). The two parameters are fully documented in the schema. Minor gap: no explicit differentiation from sibling tools, but overall the description completes the picture for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear descriptions for both parameters. The description adds the 1095-day max range context but does not significantly enhance parameter meaning beyond what the schema already provides. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves raw JSON for Active Zone Minutes time series from Fitbit over a date range. It specifies the resource (AZM time series), action (get), and scope (max 1095 days, breakdown by zones). This effectively distinguishes it from sibling tools like get_activity_timeseries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for AZM data but provides no explicit guidance on when to use this tool over alternatives. It mentions the 1095-day max constraint but lacks when-not conditions or alternative tool references. Usage is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for daily activity summary from Fitbit for a specific date. Includes goals, steps, calories, distances, and heart rate zones. Requires a 'date' parameter in YYYY-MM-DD format.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The date for which to retrieve data (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'Get the raw JSON response' implying read-only, and mentions date format and included fields. It does not disclose auth requirements, rate limits, or error conditions, but for a simple data retrieval tool, it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, output content, and required parameter format. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return is 'raw JSON' and lists key fields. It could mention that data is for the authenticated user or error handling, but for a low-complexity tool with a single parameter, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the 'date' parameter, which already includes format. The description adds value by specifying it is for a 'specific date' and listing the fields returned, but does not add new information about the parameter itself beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves raw JSON for daily activity summary, listing specific data categories (goals, steps, calories, etc.). It distinguishes from siblings like get_activity_timeseries or get_activity_goals by focusing on a comprehensive daily summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a one-day activity summary, but does not explicitly compare to sibling tools or state when not to use it (e.g., for multi-day data use get_activity_timeseries). No alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for exercise and activity logs from Fitbit after a specific date. Requires 'afterDate' parameter in 'YYYY-MM-DD' format. Retrieves a detailed list of logged exercises and activities.
| Name | Required | Description | Default |
|---|---|---|---|
| afterDate | Yes | Retrieve activities after this date (YYYY-MM-DD) | |
| limit | No | Maximum number of items to return (1-100, default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states it returns 'raw JSON response' and is a 'get' operation. It does not disclose authentication needs, rate limits, or any behavioral traits about the response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, the last of which ('Retrieves a detailed list...') is redundant with the first sentence. It is functional but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and two well-documented parameters, the description is minimally complete, but it lacks details on pagination behavior (limit parameter) and the structure of the 'raw JSON response'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so baseline is 3, but the description adds only the date format requirement already present in the schema, and does not reference the 'limit' parameter or add any additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'exercise and activity logs' with a specific verb 'Get' and key resource 'raw JSON response', distinguishing it from sibling tools like get_activity_timeseries which provide time-series data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required 'afterDate' parameter and its format, but provides no guidance on when to use this tool versus alternatives like get_activity_goals or get_daily_activity_summary, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive nutrition data (calories, protein, carbs, fat, fiber, sodium) from Fitbit food log for a specific date. Returns daily summary totals and individual food entries with nutritional values.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The date for which to retrieve food log data (YYYY-MM-DD or 'today'). Defaults to 'today'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly indicates a read operation and enumerates the returned nutritional fields. However, it omits details like authentication requirements, error handling for invalid dates, or data availability conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences, ~25 words) and immediately front-loads the purpose. Every word adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately covers what the tool does and returns. It mentions both daily totals and individual entries. A small gap is the lack of mention about data source prerequisites (e.g., Fitbit connection) which is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the date parameter is documented). The description adds context by listing the nutritional fields returned, which helps understand the parameter's purpose. This meets the baseline without significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get', the resource 'comprehensive nutrition data from Fitbit food log', and explicitly states it is for a specific date. It distinguishes from sibling tools like get_nutrition_by_date_range by emphasizing the single date focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific date but does not provide explicit guidance on when to use this tool versus alternatives like get_nutrition_by_date_range or get_nutrition. No when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for heart rate data from Fitbit for a specified period ending today or on a specific date. Requires a 'period' parameter such as '1d', '7d', '30d', '1w', '1m' and optionally accepts 'date' parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| period | Yes | The time period for which to retrieve heart rate data. | |
| date | No | The date for which to retrieve heart rate data (YYYY-MM-DD or 'today'). Defaults to 'today'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It mentions returning 'raw JSON response' but omits critical details such as authentication requirements, rate limits, error handling, or what happens if data is unavailable. This leaves significant gaps for an agent to infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly to the point, and includes all essential information without any extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description provides basic parameter usage but fails to clarify the structure of the 'raw JSON response' or error scenarios. It is minimally adequate for a simple tool but leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description merely repeats the enum values for 'period' and the format for 'date', adding no new semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'raw JSON response for heart rate data from Fitbit', and specifies the scope 'for a specified period ending today or on a specific date'. It distinguishes from the sibling 'get_heart_rate_by_date_range' by focusing on period-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that a 'period' parameter is required and an optional 'date' can be used, which implies usage context. However, it does not provide explicit guidance on when to use this tool over the sibling 'get_heart_rate_by_date_range' or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for heart rate data from Fitbit for a specific date range. Requires 'startDate' and 'endDate' parameters in 'YYYY-MM-DD' format. Note: The API enforces a maximum range of 1 year.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | Yes | The start date for which to retrieve heart rate data (YYYY-MM-DD). | |
| endDate | Yes | The end date for which to retrieve heart rate data (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the raw JSON response format and the 1-year API constraint, but omits other behavioral traits like auth requirements, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no unnecessary words, and efficiently communicates the core purpose and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should fully explain the return value—'raw JSON response' is vague. While it covers the date range constraint, it lacks details on data structure or error scenarios, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds date format and max range context, but the schema already documents the pattern and required parameters, adding minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves raw JSON heart rate data from Fitbit for a specific date range, specifying the resource, verb, and scope. It distinguishes itself from sibling tools by focusing on heart rate and date range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides date format and API range limit guidance, but does not explicitly state when to use this tool versus siblings like get_heart_rate, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for nutrition data from Fitbit for a specified resource and period ending today or on a specific date. Requires 'resource' parameter (caloriesIn, water) and 'period' parameter such as '1d', '7d', '30d', '1w', '1m', '3m', '6m', '1y' and optionally accepts 'date' parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes | The nutrition resource to retrieve data for. | |
| period | Yes | The time period for which to retrieve nutrition data. | |
| date | No | The date for which to retrieve nutrition data (YYYY-MM-DD or 'today'). Defaults to 'today'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions the output is 'raw JSON' and implies a read-only operation, but does not state authentication needs, rate limits, data scope, or side effects. The description is insufficient for complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no redundant phrases. It efficiently conveys the core purpose and key parameters, though it could benefit from structured formatting (e.g., bullet points) for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic functionality for a simple data retrieval tool with three parameters and no output schema. However, it omits explanation of the return format beyond 'raw JSON', fails to differentiate from get_nutrition_by_date_range, and does not clarify expected data granularity or potential limitations, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage (all three parameters include descriptions). The description adds value by explaining the period ends relative to today and the date defaults to 'today', but mostly restates schema enums. Baseline for high coverage is 3, and the description provides marginal additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves raw JSON nutrition data from Fitbit for a specified resource and period, ending today or on a specific date. It enumerates the allowed resource and period values. However, it does not distinguish itself from the sibling tool get_nutrition_by_date_range, missing an opportunity to clarify when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the required parameters (resource, period) and optional date, but provides no guidance on when to use this tool versus alternatives like get_nutrition_by_date_range. It lacks explicit when-to-use, prerequisites, or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for nutrition data from Fitbit for a specific resource and date range. Requires 'resource' parameter (caloriesIn, water), 'startDate' and 'endDate' parameters in 'YYYY-MM-DD' format. Note: The API enforces a maximum range of 1,095 days.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes | The nutrition resource to retrieve data for. | |
| startDate | Yes | The start date for which to retrieve nutrition data (YYYY-MM-DD). | |
| endDate | Yes | The end date for which to retrieve nutrition data (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the maximum date range constraint (1,095 days) and that the tool returns 'raw JSON response', which is beyond annotations (none provided). However, it does not mention authentication, rate limits, or behavior on invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose and resource parameter, second adds the date range constraint. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple retrieval tool with 3 parameters. Missing full enum listing in description, and no output format details (no output schema). The max range constraint is helpful. Covers key behavioral traits but could include more context on response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds the max days constraint for dates, which is not in the schema. It also reiterates the date format. The mention of only two resources ('caloriesIn, water') is incomplete, but the constraint adds value for agent planning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves nutrition data by date range and mentions specific resource options ('caloriesIn, water'), but the schema includes additional options (protein, carbs, etc.) not listed. It distinguishes from siblings like 'get_nutrition' by specifying date range, but does not explicitly differentiate from 'get_food_log' or other date range tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_nutrition' (single date) or 'get_food_log'. The description does not specify prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for the user's Fitbit profile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It only mentions 'raw JSON response' but omits details like authentication requirements, rate limits, or whether all profile fields are returned. This minimal disclosure is insufficient for an agent to anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words. It front-loads the key verb and resource, making it efficient for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. However, a note on the depth of profile data returned would slightly improve completeness. Overall, adequate for an agent's initial selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, achieving 100% coverage by default. The description adds no parameter-specific meaning, but since there are none, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the raw JSON response for the user's Fitbit profile, distinguishing it from sibling tools that retrieve specific data like activity or sleep. The verb 'Get' and resource 'user's Fitbit profile' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general profile retrieval, but no explicit guidance on when to use this versus alternatives. Since siblings cover specific domains, the profile tool's purpose is implied, but no exclusions or when-not-to-use considerations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for sleep logs from Fitbit for a specific date range. Requires 'startDate' and 'endDate' parameters in 'YYYY-MM-DD' format. Note: The API enforces a maximum range of 100 days.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | Yes | The start date for which to retrieve data (YYYY-MM-DD) | |
| endDate | Yes | The end date for which to retrieve data (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses 100-day max range and raw JSON format. However, does not mention authentication needs, rate limits, or handling of missing data. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Front-loaded with purpose and follows with a key constraint. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description covers the essential: what data is returned, required parameters, and a critical constraint. Could mention response shape or error cases, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds value by explicitly stating date format and enforcing 100-day max range beyond schema. Format info is redundant with schema pattern, but the range constraint is extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves raw JSON sleep logs for a date range. Distinguishes from sibling tools like get_activity_timeseries by specifying 'sleep logs' and 'raw JSON response'. Verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells when to use (get sleep logs by date range) and includes date format requirement and 100-day max range. Lacks explicit when-not or comparison to alternatives, but sibling tools are clearly distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw JSON response for weight entries from Fitbit for a specified period ending today. Requires a 'period' parameter such as '1d', '7d', '30d', '3m', '6m', '1y'
| Name | Required | Description | Default |
|---|---|---|---|
| period | Yes | The time period for which to retrieve data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only mentions 'raw JSON response' without disclosing rate limits, data freshness, or side effects. Minimal behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant words. Front-loaded with verb and resource, then scope and requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 1 parameter and no output schema. Description adequately states purpose and parameter requirement. Could mention return data structure but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema fully describes the period parameter with enum and description. Description adds no new semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get' and resource 'raw JSON response for weight entries from Fitbit' with scope 'for a specified period ending today'. Distinguishes from siblings which target different Fitbit data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Context with siblings implies weight data, but no alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_activity_goalsget_activity_timeseriesget_azm_timeseriesget_daily_activity_summaryget_exercisesget_food_logget_heart_rateget_heart_rate_by_date_rangeget_nutritionget_nutrition_by_date_rangeget_profile2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / propertiesAdded value: +{}get_sleep_by_date_range2 fields changedInput schema / properties / endDate / descriptionPrevious value: -"The end date for which to retrieve sleep data (YYYY-MM-DD)."New value: +"The end date for which to retrieve data (YYYY-MM-DD)"Input schema / properties / startDate / descriptionPrevious value: -"The start date for which to retrieve sleep data (YYYY-MM-DD)."New value: +"The start date for which to retrieve data (YYYY-MM-DD)"get_weight1 field changedInput schema / properties / period / descriptionPrevious value: -"The time period for which to retrieve weight data."New value: +"The time period for which to retrieve data"get_profileget_sleep_by_date_rangeget_weightMost tools have distinct purposes targeting specific Fitbit data types like activity, heart rate, nutrition, sleep, and weight, with clear boundaries. However, there is some overlap between get_heart_rate and get_heart_rate_by_date_range, and between get_nutrition and get_nutrition_by_date_range, which could cause confusion as they serve similar functions with different parameter structures.
All tool names follow a consistent snake_case pattern with a clear 'get_' prefix followed by a descriptive noun or phrase, such as get_activity_goals, get_daily_activity_summary, and get_sleep_by_date_range. This uniformity makes the tool set predictable and easy to navigate.
With 13 tools, the server is well-scoped for accessing various Fitbit data categories like activity, heart rate, nutrition, sleep, and profile. Each tool serves a specific purpose without redundancy, aligning well with the domain's complexity and providing comprehensive data retrieval capabilities.
The tool set covers key Fitbit data areas including activity, heart rate, nutrition, sleep, weight, and profile, offering good CRUD-like retrieval operations. However, there are minor gaps such as the lack of tools for updating or deleting data, which might limit full lifecycle management, though this is typical for read-focused health data servers.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pace is a remote MCP server that exposes wearable and fitness data to Claude via the Model Context Protocol. It connects to Garmin, Oura, Whoop, Polar, Fitbit and 20+ devices and provides 15 tools for querying sleep, activity, recovery, and training data. Hosted on Google Cloud Run, OAuth 2.1 authentication, Streamable HTTP transport. Instructions: First you need to create an account at: https://pacetraining.co and connect your wearables. After that you can connect the remote Server via Custom Connector in Claude and OAuth 2.1 Flow startet.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
MCP server for Withings health data — sleep, activity, heart, and body metrics.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
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
