Polar MCP

Polar Temperature Measurements

polar_list_temperature_measurements

Read-onlyIdempotent

List body temperature measurements from Polar within a date range, returning paginated results for tracking trends or reviewing readings over time.

Instructions

List temperature measurements in a date range. Requires temperature_measurement:read.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No	Polar page number.
`after`	No	Inclusive start date. Serialized as a Polar date or date-time according to the endpoint contract.
`limit`	No	Local page-size hint used for pagination safety.
`before`	No	Exclusive end date. Serialized as a Polar date or date-time according to the endpoint contract.
`features`	No	Optional Polar v4 feature flags. Values are validated per endpoint; feature ranges that require one day are hydrated safely.
`all_pages`	No	Fetch multiple pages up to max_pages.
`max_pages`	No	Maximum pages to fetch when all_pages is true.
`privacy_mode`	No	Optional per-call privacy override. Defaults to POLAR_PRIVACY_MODE or structured. raw returns upstream Polar JSON. summary removes GPS/map details.
`response_format`	No		markdown
`explicit_user_intent`	No	Required true when privacy_mode=raw or include_gps=true (agent escalation of redaction).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes
`records`	Yes
`endpoint`	Yes
`has_more`	Yes
`next_page`	No
`privacy_mode`	Yes
`pages_fetched`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.5.4Oct 4, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / after / description

Previous value: -"Only return Polar records after this time. Converted to Polar's inclusive from query parameter."New value: +"Inclusive start date. Serialized as a Polar date or date-time according to the endpoint contract."

changedInput schema / properties / before / description

Previous value: -"Only return Polar records before this time. Converted to Polar's exclusive to query parameter."New value: +"Exclusive end date. Serialized as a Polar date or date-time according to the endpoint contract."

addedInput schema / properties / explicit_user_intent

Added value: +{
+  "description": "Required true when privacy_mode=raw or include_gps=true (agent escalation of redaction).",
+  "type": "boolean"
+}

addedInput schema / properties / features

Added value: +{
+  "description": "Optional Polar v4 feature flags. Values are validated per endpoint; feature ranges that require one day are hydrated safely.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / privacy_mode / description

Previous value: -"Optional per-call privacy override. Defaults to POLAR_PRIVACY_MODE or structured. raw returns upstream Polar JSON. summary minimizes sensitive health and profile details."New value: +"Optional per-call privacy override. Defaults to POLAR_PRIVACY_MODE or structured. raw returns upstream Polar JSON. summary removes GPS/map details."

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv0.3.6Jul 9, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds a genuinely useful auth requirement ('Requires temperature_measurement:read'), but says nothing about pagination, privacy_mode behavior, or redaction escalation that the tool supports.

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 short sentences with zero waste; the scope (date range) and the permission requirement are both front-loaded and immediately actionable.

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 an output schema present and 90% schema coverage, the description need not explain return values or most parameters. It covers the core purpose and the required scope, though it omits any hint of the privacy_mode/raw escalation flow that the tool exposes.

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 90%, so the schema already documents all ten parameters (page, after, before, limit, features, privacy_mode, etc.). The description only echoes the date-range concept, adding no syntax or format detail beyond what the schema provides. Baseline 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?

States a specific verb ('List') and resource ('temperature measurements') plus a scoping constraint (date range), so the agent can tell what it returns. However, it does not differentiate from the many sibling polar_list_* tools (e.g. activity, sleeps, sports) beyond the resource name itself.

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?

'in a date range' implies when it applies, and 'Requires temperature_measurement:read' gives a prerequisite. But there is no explicit when-to-use vs alternatives guidance or exclusion criteria among the crowded polar_list_* family.

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

Deploy Server