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., "@Polar Fitness MCP Server summarize my workouts and sleep from the last 7 days"
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 server that turns raw Polar device data into AI-ready fitness insights. Exercise samples, heart rate streams, sleep hypnograms, and recovery metrics are preprocessed into compact summaries — so an AI assistant can analyse days of health data without blowing its context window.
1. Register at admin.polaraccesslink.com — create a new API client, note your client_id and client_secret, and set the redirect URI to https://localhost:8080/callback.
2. Install
npm install
npm run build3. Configure — add to your MCP client (Claude Code settings.json, Claude Desktop, etc.):
{
"mcpServers": {
"polar-accesslink": {
"command": "node",
"args": ["/path/to/polar-accesslink-mcp-server/dist/index.js"]
}
}
}4. Authenticate — ask Claude to generate your authorization URL using your client ID, complete the browser flow, then exchange the code for an access token. Add the returned credentials to your config:
{
"mcpServers": {
"polar-accesslink": {
"command": "node",
"args": ["/path/to/polar-accesslink-mcp-server/dist/index.js"],
"env": {
"POLAR_ACCESS_TOKEN": "your_access_token",
"POLAR_USER_ID": "your_user_id"
}
}
}
}5. Register your user — after restarting, ask Claude to call polar_register_user. This is required before accessing any data.
Related MCP server: Oura MCP Server
Exercise tracking — workouts with heart rate zones, training load, and preprocessed sample metrics (pace splits, power, altitude, cadence, HRV)
Daily activity — steps, calories, active/inactive duration with hourly step buckets and activity zone breakdowns
Sleep analysis — sleep score, stages (light/deep/REM), sleep architecture, and heart rate trends during sleep
Continuous heart rate — 24/7 heart rate data with preprocessed half-hourly buckets (avg/min/max)
Nightly recharge — ANS charge, HRV trends, and breathing rate analysis
Cardio load — daily strain, tolerance, and load ratio metrics
SleepWise alertness — hourly alertness predictions based on sleep quality
Exercise downloads — export workouts in FIT, TCX, or GPX format
Dual output — all tools support markdown (human-readable) or json (structured) response formats
The Polar AccessLink API returns raw sensor data — thousands of individual heart rate readings, comma-separated sample strings with tens of thousands of values, and per-minute hypnogram entries. Passing this directly to an AI assistant would consume most of the context window on a single tool call, leaving little room for conversation or multi-tool workflows.
This server preprocesses raw data into compact, meaningful summaries before it reaches the AI:
Raw API Data | Preprocessed Output |
~5,000 comma-separated speed/distance values | Per-km pace splits with avg speed |
~8,000 heart rate samples per day | 48 half-hourly buckets (avg/min/max) + daily stats |
Per-minute sleep hypnogram entries | Sleep architecture: cycle count, deep/REM distribution, time to first deep sleep |
Per-minute heart rate during sleep | Min, avg, nadir (rolling average), and trend slope (bpm/hr) |
Raw HRV and breathing samples | Min/max/trend statistics via linear regression |
Raw power samples | Avg, normalized power, max, and variability index |
Per-second altitude readings | Total ascent/descent + elevation range |
The result is that a full day of activity, sleep, and heart rate data fits comfortably in a few hundred tokens instead of tens of thousands — making multi-day queries and cross-domain analysis practical within a single conversation.
The server provides 13 tools across 5 domains.
Tool | Description |
| Generate the OAuth authorization URL to start the setup flow. |
| Exchange an authorization code for an access token. Returns |
Tool | Description |
| Register a new user with Polar AccessLink. Required before accessing any data. |
| Get user information including name, registration date, and physical attributes. |
Tool | Description |
| Get exercises from the last 30 days. Optionally include preprocessed sample metrics (pace splits, power, altitude, cadence, HRV, temperature). Supports date range filtering. |
| Download exercise data to a file in FIT, TCX, or GPX format. |
Tool | Description |
| Get daily activity summaries with preprocessed hourly step buckets and activity zone duration breakdowns. Returns last 28 days by default, or a custom date range. |
Tool | Description |
| List physical information entries including weight, height, heart rate zones, and VO2 max. |
| Get continuous heart rate data with preprocessed half-hourly buckets (avg/min/max) and daily statistics. |
| List sleep records with sleep score, stages, continuity, and preprocessed sleep architecture (cycle analysis, deep/REM distribution). |
| List nightly recharge data with ANS charge, HRV min/max/trend, and breathing rate analysis. |
| Get daily cardio load metrics including strain, tolerance, load ratio, and load level thresholds. |
| Get SleepWise alertness predictions with hourly breakdowns including alertness grade, classification, and sleep inertia. |
The Polar AccessLink API only provides access to recent data:
Data Type | Retention |
Exercises | 30 days |
Daily Activity | 28 days |
Continuous Heart Rate | 28 days |
Sleep | 28 days |
Nightly Recharge | 28 days |
Cardio Load | 28 days |
SleepWise Alertness | 28 days |
Physical Information | No limit |
To preserve historical data, export regularly using polar_download_exercise or the json response format.
You need to register your user. Ask Claude to call polar_register_user after configuring your access token.
Authorization codes are single-use and expire quickly. Generate a new authorization URL and complete the flow again.
Verify your client_id and client_secret are correct at admin.polaraccesslink.com.
Ensure your Polar device has synced with Polar Flow
The API only returns recent data (see Data Retention)
If you prefer not to use Claude's OAuth helper tools:
Create an application at admin.polaraccesslink.com
Set your redirect URI (e.g., https://localhost:8080/callback)
Direct users to authorize:
https://flow.polar.com/oauth2/authorization?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URI&scope=accesslink.read_allCopy the code parameter from the redirect URL
Exchange the code for tokens:
curl -X POST https://polarremote.com/v2/oauth2/token \
-u "CLIENT_ID:CLIENT_SECRET" \
-d "grant_type=authorization_code&code=AUTH_CODE&redirect_uri=YOUR_REDIRECT_URI"Use access_token as POLAR_ACCESS_TOKEN and x_user_id as POLAR_USER_ID
Register your user:
curl -X POST https://www.polaraccesslink.com/v3/users \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"member-id": "YOUR_USER_ID"}'Download exercise data to a file in FIT, TCX, or GPX format. The format is determined by the file extension. GPX is only available for exercises with GPS data.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | File path to save the exercise data (must end in .fit, .tcx, or .gpx) | |
| exerciseId | Yes | The exercise ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate not read-only, not destructive, and idempotent; the description adds file-format behavior and the GPS constraint without contradicting the 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?
Two concise sentences that front-load the purpose and contain no redundant or irrelevant wording.
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?
Sufficient for a straightforward download operation with two clearly described parameters and no output schema; could optionally mention overwrite behavior or success indication, but these are 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?
The schema covers both parameters, and the description adds meaningful detail by explaining that file extension determines format and that GPX requires GPS data.
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 downloads exercise data to a file in FIT, TCX, or GPX format, distinguishing it from sibling get/list tools by its file-download purpose.
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?
Implies when to use it—when a file export is needed—and notes the GPX GPS restriction, but it does not explicitly contrast with alternatives like polar_get_exercises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exchange an OAuth authorization code for an access token. Returns the POLAR_ACCESS_TOKEN and POLAR_USER_ID needed to configure the MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
| clientId | Yes | Your Polar API client ID | |
| redirectUri | No | OAuth redirect URI (must match the one used in authorization, defaults to https://localhost:8080/callback) | |
| clientSecret | Yes | Your Polar API client secret | |
| authorizationCode | Yes | The authorization code received from the OAuth callback |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds that the tool returns POLAR_ACCESS_TOKEN and POLAR_USER_ID, which clarifies the side effect (obtaining credentials). It does not mention rate limits or failure modes, but the annotation and description together provide adequate 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 succinct, using two sentences to convey the core action, output, and purpose. There is no redundant or 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 there is no output schema, the description compensates by stating the return values (POLAR_ACCESS_TOKEN and POLAR_USER_ID) and their role in configuration. It lacks details about error handling or prerequisites, but for this straightforward exchange operation, the provided context is sufficient.
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 complete (100%) and each parameter has a description, so the schema already conveys the semantics. The description does not add extra parameter context, maintaining the baseline of 3.
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 (exchange) and the resource (OAuth authorization code) and the outcome (access token). It distinguishes this tool from siblings because it is the only one that performs this exchange, while polar_get_authorization_url generates the URL for obtaining the code.
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 after receiving an authorization code and explicitly mentions that the returned token and user ID are needed to configure the MCP server, giving clear context. It does not explicitly mention alternatives, but the sibling polar_get_authorization_url makes the flow obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily activity summaries from the last 28 days with preprocessed hourly step buckets and zone duration breakdowns. Optionally filter by date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date (YYYY-MM-DD). If omitted, returns last 28 days. | |
| from | No | Start date (YYYY-MM-DD). If omitted, returns last 28 days. | |
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable context about the nature of the data ('preprocessed', specific breakdowns), making expectations clear without contradicting the 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 a single, well-structured sentence that packs all essential information without fluff or redundancy. It reads naturally and efficiently.
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?
Since there is no output schema, the description does a good job of communicating what the response will contain (daily activity summaries, hourly step buckets, zone durations). It could be slightly more specific about response structure or pagination, but overall it gives enough context for an agent to understand the tool's scope.
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 descriptions already cover all parameters (from, to, format) with formats, defaults, and behavior. The tool description adds no significant new semantic information beyond repeating the date-range behavior, so the 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 tool's purpose with a specific verb ('Get') and explicitly enumerates the resource (daily activity summaries) and the included data (hourly step buckets, zone duration breakdowns). It distinguishes well from sibling tools like polar_get_exercises or polar_get_heart_rate.
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 indicates when to use it (retrieve activity summaries) and mentions the optional date-range filter, giving useful context. However, it does not explicitly mention when to prefer alternative tools (e.g., for exercise details or sleep data), so it could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate the Polar OAuth authorization URL. Use this to start the OAuth flow and get an authorization code. Requires your Polar API client ID from https://admin.polaraccesslink.com/
| Name | Required | Description | Default |
|---|---|---|---|
| clientId | Yes | Your Polar API client ID from https://admin.polaraccesslink.com/ | |
| redirectUri | No | OAuth redirect URI (optional, defaults to https://localhost:8080/callback) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint:true, idempotent:true, and destructiveHint:false, covering the safety profile. The description adds no additional behavioral details beyond stating it generates a URL, which is already implied. It does not contradict the annotations, but also does not go beyond them, so the bar for adding context above annotations is not met.
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, two sentences long, and directly states the purpose and required input. No unnecessary fluff or repetition beyond the schema, making it well-structured 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?
This is a simple tool with two parameters, one required, no output schema, and no nested objects. The description clearly explains its role in the OAuth flow, and sibling tools like polar_exchange_authorization_code provide the context for the next step. Nothing critical is missing for an agent to use it correctly.
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 both parameters, with clear descriptions for clientId and redirectUri. The tool description repeats the clientId requirement but does not add any extra semantic detail beyond what is already in the schema. 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 that the tool generates the Polar OAuth authorization URL for starting the OAuth flow and obtaining an authorization code. It distinguishes itself from sibling tools like exchange_authorization_code, which is the subsequent step.
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 explicitly says 'Use this to start the OAuth flow,' giving clear context for when to invoke it. It implies the next step (exchange_authorization_code) without naming it directly, but the sibling list makes the usage context clear. Missing an explicit 'instead of' alternative, hence not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily cardio load metrics including strain, tolerance, load ratio, and load level thresholds. Returns last 28 days by default, or a custom date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date (YYYY-MM-DD). Required if 'from' is provided. | |
| from | No | Start date (YYYY-MM-DD). If omitted, returns last 28 days. | |
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, and non-destructive behavior, and the description adds helpful context about the default date range. No contradictions exist between the description and 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 concise, using only two sentences with no redundant or extraneous information, and it directly communicates the tool's core behavior.
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 no output schema, the description usefully names the returned metrics and default range. It is sufficient for basic invocation, though it could be slightly more explicit about the response shape.
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 schema already covers all parameters with descriptions, and the prose adds context about the default 28-day window and custom range. This slightly enhances parameter understanding beyond the schema alone.
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 a specific action ('Get daily cardio load metrics'), names the resource, and lists distinguishing metrics such as strain, tolerance, load ratio, and thresholds, making it easy to differentiate from sibling Polar 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?
Provides useful usage context by noting the default 28-day window and custom date range, but does not explicitly explain when to prefer this tool over alternatives like heart rate or sleep tools; the distinction is implicit from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get exercises from the last 30 days. Optionally filter by date range or include preprocessed sample metrics (heart rate stats, speed splits, power, altitude, etc.). Always returns heart rate zones and training load data.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date (YYYY-MM-DD). If omitted, returns up to today. | |
| from | No | Start date (YYYY-MM-DD). If omitted, returns last 30 days. | |
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
| samples | No | Include preprocessed sample data (heart rate stats, speed splits, power metrics, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful behavioral detail about return contents (heart rate zones and training load) and the optional samples flag. No contradictions with annotations were found.
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, using two clear sentences with no redundant wording. All important options are mentioned without clutter.
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 moderate complexity and absence of an output schema, the description adequately conveys what the tool returns. It does not mention pagination or error cases, but the core behavior and return contents are sufficiently described for an agent to make an informed call.
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 schema covers all four parameters with descriptions, including default behavior for omitted from/to, the format enum, and the samples boolean. The description reinforces these defaults, going slightly beyond the schema by mentioning the last-30-day default and the always-included heart rate/training load data.
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 operation ('Get exercises'), the default 30-day window, and optional filters. It does not explicitly differentiate from sibling tools like polar_get_activities or polar_download_exercise, but the focus on exercises with heart rate zones and training load provides reasonable distinction.
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 optional date filtering and sample metrics inclusion, but it does not provide explicit guidance on when to prefer this tool over closely related siblings such as polar_get_activities or polar_download_exercise. The 'Always returns heart rate zones and training load data' hint is useful but not a full usage guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get continuous heart rate data for a date range with preprocessed half-hourly buckets (avg/min/max). Always returns heart rate zone summaries and daily statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date (YYYY-MM-DD) | |
| from | Yes | Start date (YYYY-MM-DD) | |
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations by mentioning that the response always includes heart rate zone summaries and daily statistics, and that data is preprocessed into half-hourly buckets. It does not address side effects, auth requirements, or rate limits, but annotations already cover the read-only, idempotent nature.
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 and directly conveys the key facts: the action, the data type, the aggregation, and the guaranteed return fields. There is no redundancy or 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 the simple parameter set (3 parameters, no nested objects) and lack of an output schema, the description provides sufficient context for an agent to understand what the tool does and what it returns. No additional details are necessary for basic usage.
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 schema provides 100% coverage with descriptions for all three parameters (from, to, format). The description does not add any additional parameter-level guidance beyond what is in the schema, so the 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 tool's purpose: retrieving continuous heart rate data for a date range. It also specifies the data granularity (half-hourly buckets) and that it always returns zone summaries and daily statistics, making it distinct from other Polar health tools like sleep or cardio load.
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 explicitly state when to use this tool over alternatives. It simply describes what the tool does, relying on the tool name and sibling context for differentiation, which is insufficient guidance for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SleepWise alertness data including alertness grade, classification, and sleep inertia. Returns last 28 days by default, or a custom date range. Set hourly=true to include hourly alertness breakdowns.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date (YYYY-MM-DD). Required if 'from' is provided. | |
| from | No | Start date (YYYY-MM-DD). If omitted, returns last 28 days. | |
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
| hourly | No | Include hourly alertness breakdowns (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds no additional behavioral details such as response size or data availability limitations, but the annotations cover the main safety profile.
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, front-loads the resource and data types, and spends no words on unnecessary detail. It efficiently communicates defaults and the main option.
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 sufficiently states what data is returned and the key options. It could mention that output format can be markdown or JSON, but that is already covered in the schema. Overall, the description is complete enough for an agent to call the tool correctly.
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 schema provides full descriptions and enums for all parameters. The description reinforces the purpose of 'from' and 'hourly', though it does not add much beyond the schema. Since schema coverage is 100%, the baseline is 3; the description adds a small amount of context for 'from' and 'hourly'.
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 resource (SleepWise alertness data), the specific data types (alertness grade, classification, sleep inertia), and the optional hourly breakdown. It is distinguishable from sibling tools by naming SleepWise and specific metrics.
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 default behavior (last 28 days) and how to customize with date range or hourly flag. It does not explicitly mention when to use this tool versus siblings like sleep or nightly recharge, but the resource clarity makes the usage context fairly evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the registered Polar user including registration date, name, and physical attributes.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and side-effect transparency. The description adds the return content (user details), but does not mention output format or potential errors. This is acceptable given the annotation coverage, but not rich in extra behavioral context.
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, clear sentence with no redundant words. It directly states the tool's purpose and key output fields, making it efficient and easy to parse.
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 the essential aspects: what the tool does and what it returns. It lacks details about prerequisites such as authentication, but that is likely shared across all Polar tools and not specific to this one. Overall, it provides sufficient context for a simple getter.
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 only parameter 'format' is fully described in the schema with an enum and default. Since schema coverage is 100%, the description adds no additional meaning beyond what is already in the schema, hitting the baseline score.
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 uses the specific verb 'Get' and identifies the resource as the registered Polar user, with explicit details (registration date, name, physical attributes). This clearly distinguishes it from sibling tools like polar_get_heart_rate or polar_get_sleepwise, which target other 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 purpose is implicit: it is the go-to tool for user profile information. However, it does not explicitly name alternative tools or specify conditions for when to prefer this over others, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List nightly recharge data including ANS charge, HRV, and recovery metrics. Always returns preprocessed sample data (heart rate stats, HRV min/max/trend, breathing rate min/max/trend) positioned alongside existing API averages.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date (YYYY-MM-DD). If omitted, returns up to today. | |
| from | No | Start date (YYYY-MM-DD). If omitted, returns last 28 days. | |
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. However, the description's phrase 'Always returns preprocessed sample data' is ambiguous and could be interpreted as returning non-real or incomplete data, which is a transparency concern not resolved by 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 brief and directly addresses the tool's purpose. The repeated mention of 'preprocessed sample data' and listing the same metrics twice adds slight redundancy, but it is not overly 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?
Given no output schema, the description should explain more about returned data structure and any caveats. The 'sample data' phrase is unexplained and could leave an agent uncertain about the reliability or freshness of results, which is a significant gap in context.
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 clarifies the date range defaults and response format enum values. It adds useful context beyond the schema, though parameter behaviors like timezone handling are not mentioned.
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 lists nightly recharge data and specifies the key metrics (ANS charge, HRV, recovery). It does not explicitly name sibling tools for differentiation, but the resource and action are clear.
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 nightly recharge data, but does not explicitly state when to choose this over alternatives like polar_get_sleepwise or polar_list_sleep. It also lacks context about the 'sample data' caveat, which could mislead an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List physical information entries including weight, height, heart rate zones, and VO2 max. Creates a temporary transaction to pull data (not committed, so data remains available for future pulls).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral nuance: it 'creates a temporary transaction' but does not commit, meaning data remains available for future pulls. This goes beyond the annotations (readOnlyHint: false) and clarifies the side effect profile, even though idempotency is not explicitly discussed.
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 exactly two sentences with no verbose preamble. The first sentence states the primary purpose, and the second provides a concise behavioral caveat. Every sentence 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?
The description gives enough context for the agent to know what data is listed and that a format parameter controls output. No output schema is provided, but the enumerated fields and format parameter partially compensate. It could mention return structure, but this is minor given the tool's simplicity.
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 single parameter 'format' is fully documented in the schema with an enum (markdown/json), default value, and a clear description. Since schema description coverage is 100%, the description does not need to add extra parameter semantics; baseline 3 applies.
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's specific verb ('List') and resource ('physical information entries'), and enumerates the exact data types included (weight, height, heart rate zones, VO2 max). This distinguishes it from sibling tools like polar_list_sleep or polar_list_nightly_recharge without needing to open the schema.
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 purpose makes it obvious when to use the tool (when physical info is needed), but the description does not explicitly compare it to alternatives or state when not to use it. The transaction note is more about side effects than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sleep records including sleep score, duration, and sleep stages (light, deep, REM). Always returns heart rate stats and sleep architecture summary from preprocessed hypnogram and heart rate samples.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date (YYYY-MM-DD). If omitted, returns up to today. | |
| from | No | Start date (YYYY-MM-DD). If omitted, returns last 28 days. | |
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint, idempotentHint, destructiveHint) already convey safety and side-effect expectations. The description adds that the tool 'always returns' specific fields, which is informative but does not go beyond what annotations already imply. No contradictory behavior is described.
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, concise and to the point. It front-loads the primary action and lists key output details without unnecessary fluff. Excellent structure.
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 there is no output schema, the description sufficiently indicates what the response will contain (sleep score, duration, stages, heart rate stats, architecture summary). It does not mention pagination, errors, or limits, but these are not essential for a simple read-only list operation. Overall, the description provides adequate context for an agent to call the tool correctly.
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 clear descriptions for each parameter (date range and format). The description adds no extra meaning to the parameters themselves, but it does explain the output content, which indirectly aids parameter understanding. 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 tool lists sleep records and specifies the included data (sleep score, duration, stages, heart rate stats, architecture summary). It does not explicitly distinguish from sibling tools like polar_list_nightly_recharge or polar_get_sleepwise, but the verb and resource are specific enough.
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 guidance on when to use this tool versus alternatives, nor any conditions that would make it the preferred choice. It simply describes what it does, with no explicit 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new user with the Polar AccessLink API. This creates a link between your application and the Polar user.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false and idempotent=true. Description adds that the tool creates a link between application and Polar user, which is a useful side-effect note, but it omits other behavioral details like required user consent or auth state. With annotations covering the main flags, a 3 is appropriate.
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 succinct sentences, no redundant fluff, and the core action and consequence are conveyed efficiently.
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 tool's purpose depends heavily on the Polar OAuth flow (sibling tools include authorization and code exchange), but the description does not explain how the user is identified, what credentials are needed, or the proper sequence. No output schema is provided, so the result shape is also unknown. This leaves significant context 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% (one parameter 'format' fully documented with enum, default, and description). The description does not add extra parameter context beyond the schema, but the baseline holds. The mismatch between the registration operation and only a format parameter is a schema completeness concern, not a parameter-semantics gap.
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?
States a specific verb ('Register') and resource ('new user with the Polar AccessLink API') and clarifies it creates a link. Clearly distinguishes from sibling tools like polar_get_user and polar_exchange_authorization_code.
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. Does not mention prerequisites such as having an authorization code or being authenticated, nor when polar_exchange_authorization_code or polar_get_user would be more appropriate.
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.0polar_download_exercisepolar_exchange_authorization_codepolar_get_activitiespolar_get_authorization_urlpolar_get_cardio_loadpolar_get_exercisespolar_get_heart_ratepolar_get_sleepwisepolar_get_userpolar_list_nightly_rechargepolar_list_physical_infopolar_list_sleeppolar_register_userEach tool targets a distinct resource and action, such as authorization, user management, sleep, activities, exercises, heart rate, and cardio load. No two tools have overlapping purposes.
All tools follow a consistent 'polar_verb_noun' pattern. Verbs like get, list, exchange, register, and download are used appropriately, and nouns are clear (user, sleep, activities, exercises).
With 13 tools, the set is well-scoped for a fitness data API covering authentication, user profiles, and various health metrics. It fits comfortably within the typical 3-15 range.
The tool surface covers the core Polar Flow data domains: user, activities, exercises, sleep, heart rate, cardio load, physical info, and OAuth flow. No major missing operations are apparent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect your wearables, rings and training apps, then ask your AI about your own health data.
Connect your health, fitness, nutrition, sleep, and wearable data to your AI assistant.
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
Private Apple Health metrics and workout detail for ChatGPT, Claude, and any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/andresaguirre08/PolarMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
