polestar-mcp

Get global-charge-timer

get_global_charge_timer

Read-only

Retrieve the recurring charge timer configuration for your Polestar, including start/stop hours, timezone offset, and activation status. Also shows pending changes that have not yet reached the car.

Instructions

Recurring charge window: start/stop hour with timezone offset, activation flag and sync status. Pending changes appear only when an edit has not yet reached the car; an empty pending block means nothing is queued. (M2M endpoint: /v1/vehicles/{vin}/charging/global-charge-timer, scope pdp-charging/globalChargeTimer).

Input Schema

TableJSON Schema

Name	Required	Description
`raw`	No	Return the full raw API payload instead of (or after) the humanized summary. Unchanged upstream content: it carries the VIN even when POLESTAR_REDACT_VIN is on.
`vin`	No	Vehicle Identification Number. Optional when the credential has exactly one vehicle, omit it and the only vehicle is used.
`delegated_account_id`	No	Third-party credentials only: read the shared vehicles of this account for this call. Must be listed in POLESTAR_DELEGATED_ACCOUNT_IDS.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	False when the call produced no data.
`vin`	No	Vehicle the result is about, masked when POLESTAR_REDACT_VIN is on.
`code`	No	Machine-readable error code when ok is false.
`data`	No	Structured payload; shape documented per tool.
`hint`	No	Actionable guidance when ok is false.
`tool`	No	Tool that produced this result.
`message`	Yes	Result text, identical to the content block.
`requestId`	No	Upstream request id, the handle support needs.
`ageSeconds`	No	Staleness of the underlying telemetry.
`httpStatus`	No	Upstream HTTP status when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 19, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The description adds genuinely useful behavioral context beyond the readOnlyHint/openWorldHint annotations: pending changes appear only when an edit has not yet reached the car, and an empty pending block means nothing is queued. This clarifies the sync/pending semantics 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 three compact sentences with no filler: payload definition, the key pending-changes nuance, and endpoint/scope context. Every sentence earns its place, and the most non-obvious behavior is called out explicitly.

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?

For a read-only getter with a full output schema and fully documented optional parameters, the description provides the non-obvious semantics needed to understand the result (pending behavior, activation, sync status). It is slightly incomplete about selection criteria among sibling charging/timer tools, but nothing required to invoke it correctly is missing.

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%, so the schema already documents vin, raw, and delegated_account_id. The tool description adds no parameter-level semantics, which keeps this at the baseline rather than elevating it.

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 identifies the exact resource (global-charge-timer) and its payload concepts (start/stop hour, timezone offset, activation flag, sync status), making it easy to distinguish from sibling charging/vehicle getters. The action 'get' is clear from the tool name and title, and the endpoint path leaves no ambiguity about scope.

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 is given on when to use this tool versus the many sibling get_* endpoints, nor when not to use it. The word 'Recurring' implies the intended domain, but the agent is left to infer the decision boundary between this and related charging/timer tools.

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