Which integrations are available for this server?

Provides access to Fitbit health and fitness data including activity tracking, sleep logs, heart rate, steps, body measurements, food and water logs, lifetime statistics, device information, and earned badges through Fitbit's public API.

How do I use FitBit MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FitBit MCP show my sleep data from yesterday" 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.

FitBit MCP

by NitayRabi

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Fitbit MCP (Model Context Protocol)

Disclaimer: This is an unofficial integration built using Fitbit's public API and is not affiliated with or endorsed by Fitbit Inc.

A Model Context Protocol (MCP) implementation for Fitbit, enabling AI assistants to access and analyze your Fitbit health and fitness data.

Usage

For JSON configuration (for use with AI assistant frameworks):

{
  "command": "npx",
  "args": ["-y", "fitbit-mcp", "--stdio"],
  "env": {
    "FITBIT_ACCESS_TOKEN": "YOUR_FITBIT_ACCESS_TOKEN"
  }
}

Or with arguments instead of environment variables:

{
  "command": "npx",
  "args": ["-y", "fitbit-mcp", "--stdio", "--fitbit-token=YOUR_FITBIT_ACCESS_TOKEN"]
}

Related MCP server: fitbit-mcp

Available Tools

This MCP provides the following tools for AI assistants to access your Fitbit data:

getUserProfile: Get your Fitbit profile information
getActivities: Get activity data for a specified date
getSleepLogs: Get sleep data for a specified date
getHeartRate: Get heart rate data for a specified date and period
getSteps: Get step count for a specified date and period
getBodyMeasurements: Get weight and body fat data
getFoodLogs: Get food log data for a specified date
getWaterLogs: Get water consumption data for a specified date
getLifetimeStats: Get lifetime activity statistics
getUserSettings: Get user settings and preferences
getFloorsClimbed: Get floors climbed data
getDistance: Get distance data
getCalories: Get calories burned data
getActiveZoneMinutes: Get active zone minutes data
getDevices: Get information about connected Fitbit devices
getBadges: Get earned badges and achievements

Most tools accept optional parameters:

date: Date in YYYY-MM-DD format (defaults to today)
period: Time period for data (1d, 7d, 30d, 1w, 1m)

Obtaining a Fitbit Access Token

To get a Fitbit access token:

Create an application at Fitbit Developer Portal
Set OAuth 2.0 Application Type to "Personal"
Set Callback URL to "http://localhost:3000"
After creating the application, note your Client ID and Client Secret
Use the OAuth 2.0 authorization flow to obtain an access token

For detailed instructions on OAuth authentication, see the Fitbit API Documentation.

Contributing

Contributions are welcome! Here's how you can contribute:

Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

Every pull request triggers a GitHub Actions workflow that verifies the build process.

Development Setup

# Clone the repository
git clone https://github.com/your-username/fitbit-mcp.git
cd fitbit-mcp

# Install dependencies
npm install

# Build the project
npm run build

# Run in development mode
npm run dev

Release Process

To publish a new version to NPM:

Update the version in package.json
Create a new GitHub release with a tag like v1.0.1
The GitHub Actions workflow will automatically build and publish the package to NPM

Make sure you have the NPM_TOKEN secret configured in your GitHub repository settings.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

16 tools

getActiveZoneMinutesD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.
`period`	No	Period for data: 1d, 7d, 30d, 1w, 1m

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getActivitiesD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getBadgesD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getBodyMeasurementsD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.
`period`	No	Period for body data: 1d, 7d, 30d, 1w, 1m

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getCaloriesD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.
`period`	No	Period for data: 1d, 7d, 30d, 1w, 1m

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getDevicesD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getDistanceD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.
`period`	No	Period for data: 1d, 7d, 30d, 1w, 1m

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getFloorsClimbedD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.
`period`	No	Period for data: 1d, 7d, 30d, 1w, 1m

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getFoodLogsD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getHeartRateD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.
`period`	No	Period for heart rate data: 1d, 7d, 30d

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getLifetimeStatsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getSleepLogsD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getStepsD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.
`period`	No	Period for step data: 1d, 7d, 30d, 1w, 1m

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getUserProfileD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getUserSettingsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getWaterLogsD

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. If not specified, will use today.

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

16 tool updatesv1.0.0Jan 3, 2026
- ChangedgetActiveZoneMinutes2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetActivities2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetBadges1 field changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
- ChangedgetBodyMeasurements2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetCalories2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetDevices1 field changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
- ChangedgetDistance2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetFloorsClimbed2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetFoodLogs2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetHeartRate2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetLifetimeStats1 field changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
- ChangedgetSleepLogs2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetSteps2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
- ChangedgetUserProfile1 field changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
- ChangedgetUserSettings1 field changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
- ChangedgetWaterLogs2 fields changed
  - addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
  - addedInput schema / additionalProperties
```
Added value: +false
```
16 tool updatesSep 25, 2025
- First observedgetActiveZoneMinutes
- First observedgetActivities
- First observedgetBadges
- First observedgetBodyMeasurements
- First observedgetCalories
- First observedgetDevices
- First observedgetDistance
- First observedgetFloorsClimbed
- First observedgetFoodLogs
- First observedgetHeartRate
- First observedgetLifetimeStats
- First observedgetSleepLogs
- First observedgetSteps
- First observedgetUserProfile
- First observedgetUserSettings
- First observedgetWaterLogs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific Fitbit data categories like heart rate, sleep, steps, badges, etc. There is no overlap or ambiguity between tools - an agent can easily select the right tool for each type of data retrieval.

Naming Consistency5/5

All 16 tools follow a perfectly consistent 'getNoun' or 'getAdjectiveNoun' naming pattern using camelCase. The naming convention is uniform throughout the entire toolset with no deviations.

Tool Count4/5

16 tools is slightly high but reasonable for a comprehensive fitness data API. Each tool represents a distinct data category that Fitbit tracks, so most tools earn their place, though some consolidation might be possible.

Completeness2/5

The toolset is severely incomplete as it only provides read-only data retrieval operations. There are no tools for creating, updating, or deleting any Fitbit data (like logging food/water, starting activities, or updating goals), which are essential for a full fitness tracking workflow.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SomviaOAuth
app.somvia
Private Apple Health metrics and workout detail for ChatGPT, Claude, and any MCP client.
Health & Wellness Fitness Tracking
2
Fulcra ContextOAuth
com.fulcradynamics
Collect Apple Health data from your wearables through the Context app and query it via MCP
Health & Wellness Data Platforms Research & Data
2
Pace COAuth
app.run.europe-west1.pace-mcp-820971109121
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.
Customer Data Platforms Fitness Tracking Health & Wellness
3
Withings Health DataOAuth
io.github.akutishevsky
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Health & Wellness Research & Data
239

Related MCP Servers

Fitbit MCP Server
Health & Wellness Agent Orchestration API Testing
TheDigitalNinja
A
license
A
quality
C
maintenance
A Model Context Protocol server that bridges LLMs (like Claude) with the Fitbit API, allowing the LLM to request and retrieve user health and fitness data through defined tools.
Updated a year ago (2025-05-27 05:20 UTC)
13
22
33
MIT
fitbit-mcp
Health & Wellness Fitness Tracking
partymola
A
license
A
quality
A
maintenance
MCP server for the Fitbit Web API with OAuth PKCE, local cache, and trend analysis.
Updated 6 days ago (2026-08-31 01:14 UTC)
18
2
GPL 3.0
Fitbit MCP
Health & Wellness Fitness Tracking
davidmosiah
A
license
A
quality
A
maintenance
Local-first MCP server that connects AI agents to your Fitbit activity, sleep, heart-rate, HRV, SpO2 and weight data.
Updated 8 days ago (2026-08-29 10:27 UTC)
33
260
4
MIT
Garmin MCP Server
Health & Wellness Fitness Tracking
Shubhaankar-Sharma
A
license
Not graded
quality
D
maintenance
This Model Context Protocol (MCP) server connects to Garmin Connect and exposes your fitness and health data to Claude and other MCP-compatible clients.
Updated 4 months ago (2026-05-11 05:23 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/NitayRabi/fitbit-mcp'

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