The Withings MCP Server provides comprehensive access to Withings Health API data through Claude Desktop, enabling natural language queries of your fitness and wellness metrics.
Health Data Access:
Body Measurements: Weight, BMI, body fat percentage, muscle mass, bone mass, fat-free mass, blood pressure, heart rate, SpO2, body temperature, pulse wave velocity, and height
Activity Tracking: Daily steps, calories burned, distance traveled, and elevation gained
Sleep Analysis: Duration, sleep phases (deep, REM, light), wake-up counts, breathing disturbances, apnea events, snoring, and respiratory rate—available as both summaries and granular phase-by-phase details
Workout Sessions: Training and workout session data
Heart Rate Monitoring: Intraday heart rate measurements over specific time periods
User Information: Basic profile data for the authenticated user
Key Features:
OAuth2 Authentication: Secure connection with automatic token generation, storage, and refresh
Flexible Queries: Filter by date ranges (YYYY-MM-DD or Unix timestamps), measurement types, and categories (real measurements vs. user objectives)
Automatic Timezone Conversion: All timestamps converted from UTC to local time
Incremental Updates: Use lastupdate parameter for efficient data retrieval
Multiple Installation Options: Docker (recommended) or local Python installation with automatic credential management from .env file
Claude Desktop Integration: Configure as an MCP server for seamless natural language health data queries
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., "@Withings MCP Server show my weight and heart rate from the past 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.
An MCP (Model Context Protocol) server for integration with the Withings Health API. This server provides access to health data including body measurements, activities, sleep, and more.
OAuth2 Authentication with the Withings API
Body Measurements: Weight, body fat, muscle mass, blood pressure, heart rate, SpO2, etc.
Activity Data: Steps, calories, distance, elevation
Sleep Data: Sleep duration, deep sleep, REM sleep, wake-up counts
Workout Data: Training sessions and details
Heart Rate: Intraday heart rate measurements
Automatic Timezone Conversion: All timestamps are automatically converted from UTC to your local timezone
Related MCP server: Withings MCP Client
Python 3.10, 3.11, or 3.12 (Python 3.13+ is not yet supported by the MCP SDK)
Withings API credentials (Client ID and Client Secret)
Create Withings API Credentials:
Create a new application
Note your Client ID and Client Secret
Set the Redirect URI to http://localhost:8080/callback
Configure environment variables:
# Copy the example file
cp .env.example .env
# Edit .env and add your credentials
WITHINGS_CLIENT_ID=your_client_id_here
WITHINGS_CLIENT_SECRET=your_client_secret_here
WITHINGS_REDIRECT_URI=http://localhost:8080/callbackGenerate OAuth tokens:
# First, install locally to run token generation
python -m venv .venv
source .venv/bin/activate
pip install -e .
python generate_tokens.pyBuild and run with Docker:
# Build the image
docker build -t withings-mcp-server .
# Run with docker-compose
docker-compose up -dClone repository and install dependencies:
# IMPORTANT: Use Python 3.12 or lower (3.13+ not yet supported)
python3.12 -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install dependencies
pip install -e .Create Withings API Credentials:
Create a new application
Note your Client ID and Client Secret
Set the Redirect URI to http://localhost:8080/callback
Configure environment variables:
# Copy the example file
cp .env.example .env
# Edit .env and add your credentials
WITHINGS_CLIENT_ID=your_client_id_here
WITHINGS_CLIENT_SECRET=your_client_secret_here
WITHINGS_REDIRECT_URI=http://localhost:8080/callbackwithings-mcp-server/
├── src/
│ └── withings_mcp_server/
│ ├── __init__.py
│ ├── auth.py # OAuth2 authentication
│ └── server.py # MCP server implementation
├── tests/
│ ├── __init__.py
│ └── test_withings.py # Manual test script
├── generate_tokens.py # Token generation script
├── .env.example # Example environment variables
├── .gitignore
├── pyproject.toml
└── README.mdBefore using the MCP server, you can verify the connection with the test script:
# Activate virtual environment if not already done
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Run the test script
python tests/test_withings.pyThe test script will guide you through the OAuth flow and test various API endpoints:
✓ OAuth authentication
✓ User information
✓ Body measurements (last 30 days)
✓ Activity data (last 7 days)
✓ Sleep data (last 7 days)
Before first use, you need to generate OAuth2 tokens. Tokens are automatically saved to the .env file and refreshed when needed.
Use the dedicated token generation script:
python generate_tokens.pyThe script will guide you through all steps:
✓ Check your API credentials
✓ Generate the authorization URL
✓ Exchange the code for tokens
✓ Save tokens automatically to .env
✓ Verify tokens with a test API call
You can also use the test script which combines OAuth flow and API tests:
python tests/test_withings.pyGet authorization URL:
Use the get_authorization_url tool to generate an OAuth URL
Authenticate in browser:
Open the URL in your browser and authorize access
Receive authorization code:
After successful authorization, you'll be redirected to your Redirect URI with a code parameter
Token management:
Access and Refresh Tokens are automatically:
Saved to the .env file
Refreshed when expired
Updated after each refresh
get_authorization_urlGenerates an OAuth2 authorization URL.
Parameters:
scope (optional): OAuth scopes (default: "user.info,user.metrics,user.activity")
get_user_infoRetrieves user information.
get_measurementsRetrieves body measurements.
Parameters:
meastype (optional): Measurement type
1: Weight (kg)
4: Height (m)
5: Fat-free mass (kg)
6: Body fat percentage (%)
8: Fat mass (kg)
9: Diastolic blood pressure (mmHg)
10: Systolic blood pressure (mmHg)
11: Heart rate (bpm)
12: Temperature (°C)
54: SpO2 (%)
71: Body temperature (°C)
76: Muscle mass (kg)
88: Bone mass (kg)
91: Pulse wave velocity (m/s)
category (optional): Category (1=real, 2=user_objective)
startdate (optional): Start date (YYYY-MM-DD or Unix timestamp)
enddate (optional): End date (YYYY-MM-DD or Unix timestamp)
lastupdate (optional): Only measurements since this timestamp
get_activityRetrieves daily activity data.
Parameters:
startdateymd (optional): Start date (YYYY-MM-DD)
enddateymd (optional): End date (YYYY-MM-DD)
lastupdate (optional): Only activities since this timestamp
get_sleep_summaryRetrieves sleep summary.
Parameters:
startdateymd (optional): Start date (YYYY-MM-DD)
enddateymd (optional): End date (YYYY-MM-DD)
lastupdate (optional): Only sleep data since this timestamp
get_sleep_detailsRetrieves detailed sleep data with all sleep phases.
Parameters:
startdate (optional): Start date (YYYY-MM-DD or Unix timestamp)
enddate (optional): End date (YYYY-MM-DD or Unix timestamp)
get_workoutsRetrieves workout/training sessions.
Parameters:
startdateymd (optional): Start date (YYYY-MM-DD)
enddateymd (optional): End date (YYYY-MM-DD)
get_heart_rateRetrieves heart rate measurements over a time period.
Parameters:
startdate (optional): Start date (YYYY-MM-DD or Unix timestamp)
enddate (optional): End date (YYYY-MM-DD or Unix timestamp)
To use the server with Claude Desktop, add the following to your MCP configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"withings": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e", "WITHINGS_CLIENT_ID=your_client_id",
"-e", "WITHINGS_CLIENT_SECRET=your_client_secret",
"-e", "WITHINGS_ACCESS_TOKEN=your_access_token",
"-e", "WITHINGS_REFRESH_TOKEN=your_refresh_token",
"withings-mcp-server"
]
}
}
}Note: The server automatically loads credentials from .env file in the project root. You don't need to specify tokens in the config.
{
"mcpServers": {
"withings": {
"command": "/path/to/withings-mcp-server/.venv/bin/python",
"args": ["-m", "withings_mcp_server"]
}
}
}The server will automatically:
Load credentials from .env file
Refresh expired tokens
Save refreshed tokens back to .env
After configuration, you can make the following requests in Claude Desktop:
"Show me my weight measurements from the last 7 days"
"How many steps did I walk today?"
"How was my sleep quality last night?"
"Show me my heart rate data from today"For more details about the Withings API:
MIT
If Claude Desktop shows "Request timed out" when connecting:
Check Python version: The MCP SDK requires Python 3.10-3.12 (3.13+ not supported)
/path/to/.venv/bin/python --versionRecreate virtual environment with correct Python version:
rm -rf .venv
python3.12 -m venv .venv
source .venv/bin/activate
pip install -e .Update Claude Desktop config to use the correct Python path
If you get invalid_token or 401 errors:
The server now auto-refreshes tokens, but if that fails:
cd /path/to/withings-mcp-server
source .venv/bin/activate
python generate_tokens.pyRestart Claude Desktop to pick up the new tokens
Note: Tokens are stored in .env and automatically refreshed. Don't put tokens in claude_desktop_config.json - the server loads them from .env automatically.
Python 3.13+ is not yet supported by the MCP SDK (use 3.10-3.12)
Tokens are automatically refreshed when they expire
All dates can be specified as YYYY-MM-DD or Unix timestamp
The API is subject to Withings rate limits (see API documentation)
Timestamps are converted to local timezone: All date/time fields in responses are automatically converted from UTC to your local timezone in ISO 8601 format (e.g., 2025-12-25T14:30:00+01:00)
Schimmi — https://schimmilab.de Issues und Pull Requests willkommen.
Get daily activity data (steps, calories, distance, elevation)
| Name | Required | Description | Default |
|---|---|---|---|
| startdateymd | No | Start date in YYYY-MM-DD format | |
| enddateymd | No | End date in YYYY-MM-DD format | |
| lastupdate | No | Get activities modified since this timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as data range limits, authentication needs, rate limits, or whether data is aggregated per day. Only the data types are listed.
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, no redundant information. Front-loaded with the tool's purpose. Every word is necessary.
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?
Without annotations or output schema, the description is minimal. It lacks details on return format, pagination, or any constraints. For a 3-parameter tool, more context is needed.
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%, with all parameters described. The description does not add further meaning beyond the schema (e.g., that 'startdateymd' and 'enddateymd' define the range, or that 'lastupdate' filters by modification time). Baseline 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 resource 'daily activity data', and lists specific data types (steps, calories, distance, elevation). This distinguishes it from sibling tools like get_heart_rate or get_sleep_details.
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 (e.g., get_workouts, get_heart_rate). No conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OAuth2 authorization URL to authenticate with Withings
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | OAuth scopes (comma-separated): user.info, user.metrics, user.activity | user.info,user.metrics,user.activity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool gets a URL, with no mention of side effects (none expected), rate limits, or user interaction required. This leaves the agent with minimal understanding of the tool's behavior beyond the basic action.
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 a single, front-loaded sentence with no unnecessary words. Every part is essential, making it highly 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?
Given the tool's simplicity (one optional param, no output schema), the description is largely sufficient. However, it could briefly mention that the URL requires user interaction to complete authentication, but this is not critical for a tool that simply returns a URL.
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 'scope', and the description does not add any extra meaning beyond the schema's own description. As per guidelines, with high schema coverage the baseline is 3, and the description provides no additional 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 states the action ('Get'), the resource ('OAuth2 authorization URL'), and the target ('authenticate with Withings'). It is specific and easily distinguishable from sibling tools which are all data retrieval functions.
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 does not provide explicit guidance on when to use this tool vs alternatives, such as indicating it should be called first before other API calls. The context implies it is for authentication, but no direct instructions or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get heart rate measurements over a time period
| Name | Required | Description | Default |
|---|---|---|---|
| startdate | No | Start date (YYYY-MM-DD) or Unix timestamp | |
| enddate | No | End date (YYYY-MM-DD) or Unix timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full burden for behavioral traits. It fails to disclose important details such as data granularity, time zone handling, potential rate limits, or what happens if dates are missing. The description only implies time-range scoping.
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—one sentence with nine words. It is front-loaded with the core action. However, it may be too terse at the expense of completeness.
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 should clarify what the tool returns (e.g., list of records, timestamps, units). It does not. The tool is simple but lacks details on default behavior, edge cases, or data structure, leaving the agent underinformed.
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 provides 100% coverage with descriptions for 'startdate' and 'enddate'. The description adds no additional meaning beyond the schema, just 'over a time period'. Baseline score of 3 is appropriate as schema already documents parameters.
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 heart rate measurements over a time period. The verb 'Get' and resource 'heart rate measurements' are specific. However, it does not differentiate from siblings like 'get_measurements' which might overlap, and lacks detail on the type of measurements (e.g., minute-by-minute, average).
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 usage guidance is provided. The description does not indicate when to use this tool over alternatives (e.g., get_activity, get_measurements), nor does it mention prerequisites or contexts like activity tracking vs. resting state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get body measurements (weight, fat mass, muscle mass, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| meastype | No | Measurement type: weight=1, height=4, fat_free_mass=5, fat_ratio=6, fat_mass_weight=8, diastolic_bp=9, systolic_bp=10, heart_rate=11, temperature=12, spo2=54, body_temp=71, muscle_mass=76, bone_mass=88, pulse_wave_velocity=91 | |
| category | No | Measurement category: 1=real, 2=user_objective | 1 |
| startdate | No | Start date (YYYY-MM-DD) or Unix timestamp | |
| enddate | No | End date (YYYY-MM-DD) or Unix timestamp | |
| lastupdate | No | Get measurements modified since this timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only restates basic purpose without disclosing behavioral traits like pagination, permissions, or side effects.
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 specific examples, efficiently front-loaded, though extreme brevity may limit completeness.
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?
With 5 parameters and no output schema, description lacks guidance on output format, optionality, or typical usage patterns, leaving gaps for the 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; description lists example types but adds little meaning beyond what is already in 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?
Description clearly states verb 'get' and resource 'body measurements' with examples, distinguishing it from siblings like get_heart_rate or get_activity.
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 vs. alternatives, no prerequisites or exclusions mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed sleep data with all sleep phases
| Name | Required | Description | Default |
|---|---|---|---|
| startdate | No | Start date (YYYY-MM-DD) or Unix timestamp | |
| enddate | No | End date (YYYY-MM-DD) or Unix timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It only mentions that sleep phases are included but does not specify return format, pagination, date range limits, or other behavioral traits.
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 a single sentence of 8 words with no extraneous content. It is concise but could potentially include more useful information without being verbose.
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?
There is no output schema, so the description should compensate by hinting at the return format. It only says 'detailed sleep data with all sleep phases', which is vague. Considering the complexity of sleep phases, more detail would 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 coverage of parameters is 100%, both with descriptions in the schema. The description adds no additional meaning beyond what the schema already provides, so baseline score 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 'detailed sleep data', and specifies 'with all sleep phases', which distinguishes it from the sibling tool 'get_sleep_summary' that likely provides summary 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 guidance is provided on when to use this tool versus alternatives like 'get_sleep_summary'. There is no explicit mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get sleep summary data (duration, deep sleep, REM, wake up count, breathing disturbances, apnea, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| startdateymd | No | Start date in YYYY-MM-DD format | |
| enddateymd | No | End date in YYYY-MM-DD format | |
| lastupdate | No | Get sleep data modified since this timestamp | |
| data_fields | No | Comma-separated list of data fields to include (e.g., 'breathing_disturbances_intensity,apnea_hypopnea_index,snoring,rr_average'). If not specified, returns default fields. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only lists data fields and does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or what happens when no data exists.
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 is concise and directly states purpose with examples, though it could be structured slightly better 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 provides a reasonable list of returned data but lacks explanation of date range behavior, pagination, or handling of missing data. No output schema exists, so description must carry more load.
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% with descriptions for all parameters. The description adds examples for data_fields, but overall does not significantly enhance understanding 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?
The description clearly states the tool retrieves sleep summary data and lists typical data fields. However, it does not differentiate from sibling tools like get_sleep_details, which may provide more detailed sleep 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 guidance on when to use this tool versus alternatives. No context on required parameters or typical use cases, despite 0 required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user information from Withings account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description indicates a read operation but does not disclose authentication requirements, data freshness, or what specific information is returned.
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 concise sentence that directly states the tool's purpose with no extraneous information.
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 parameters and low complexity, the description is largely sufficient. However, without an output schema, an agent might not know what data to expect.
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 no parameters, so the description need not add param details. It mentions 'user information' generally, but omits specifics about what fields are included.
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 identifies the action (get) and resource (user information from Withings account). It distinguishes from sibling tools like get_activity, get_heart_rate, etc., which target 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 general user profile data, but does not explicitly state when to use this over alternatives or mention prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get workout/training sessions data
| Name | Required | Description | Default |
|---|---|---|---|
| startdateymd | No | Start date in YYYY-MM-DD format | |
| enddateymd | No | End date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It only states the tool 'gets' data, which implies a read operation, but does not confirm safety, authentication needs, or any side effects.
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 a single sentence with no unnecessary words. It is front-loaded and efficient, though it could benefit from slightly more detail.
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 has only two simple parameters, no output schema, and no annotations, the description provides minimal but adequate context. It explains what the tool returns but omits details on output format or limitations.
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% with both parameters having descriptions. The description does not add meaning beyond what the schema provides, so baseline score 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 states the verb 'Get' and the resource 'workout/training sessions data'. It is specific, but does not differentiate from the sibling tool 'get_activity', which could have overlapping functionality.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'get_activity', nor does it specify any prerequisites or contexts.
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_sleep_summary1 field changedInput schema / properties / data_fieldsAdded value: +{
+ "description": "Comma-separated list of data fields to include (e.g., 'breathing_disturbances_intensity,apnea_hypopnea_index,snoring,rr_average'). If not specified, returns default fields.",
+ "type": "string"
+}get_activityget_authorization_urlget_heart_rateget_measurementsget_sleep_detailsget_sleep_summaryget_user_infoget_workoutsAll tools have clearly distinct purposes: activity, heart rate, body measurements, sleep details vs summary, workouts, user info, and authorization. Even the two sleep tools are well-differentiated by detail level.
All tools follow a perfect 'get_<resource>' pattern with snake_case, making it predictable and easy for an agent to infer tool purposes.
With 8 tools, the server covers a comprehensive but focused set of health data endpoints without being overwhelming or too sparse.
The server covers all major Withings health metrics (activity, heart, sleep, workouts, body measurements, user info). Missing write operations and some niche metrics like blood pressure, but core read functionality is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Read wearables and lab health data — sleep, activity, workouts, timeseries, lab tests and orders.
Connect your Oura Ring account securely in minutes. Enable authorized access to your sleep, activi…
Connect your Oura Ring account to enable secure, authenticated access in your workflows. Generate…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Schimmilab/withings-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server