Polar Fitness MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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).
Tool Count5/5
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.
Completeness5/5
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.
Average 3.9/5 across 13 of 13 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Polar Fitness MCP Server MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![Polar Fitness MCP Server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/andresaguirre08/PolarMCP/badges/card.svg)](https://glama.ai/mcp/servers/andresaguirre08/PolarMCP)

Score Badge

Copy to your README.md:

[![Polar Fitness MCP Server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/andresaguirre08/PolarMCP/badges/score.svg)](https://glama.ai/mcp/servers/andresaguirre08/PolarMCP)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![Polar Fitness MCP Server MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fandresaguirre08%2FPolarMCP%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/andresaguirre08/PolarMCP)

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/andresaguirre08/PolarMCP'

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