openchargemap-mcp-server

openchargemap-mcp-server: get station comments

openchargemap_get_station_comments

Read-onlyIdempotent

Read community check-ins and comments for one Open Charge Map station — the real-world reliability signal beyond the operator-reported registry status. Returns user comments and fault reports with ratings, dates, and the outcome the driver recorded ("Charged Successfully", "Failed to Charge (Equipment Not Operational)", …), alongside the station's current registry status and last-verified date, surfacing mismatches like "listed operational, but the last few check-ins report a fault." A busy station's check-ins come back one page at a time: when a page reports truncated, repeat the call with the reported nextOffset to read the next one.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Numeric OCM station ID.
`offset`	No	Comments to skip before the returned page, for reading past a truncated result. Repeat the same call with the nextOffset value the previous one reported. Ordering is newest-first and stable, but a check-in posted between pages shifts what a later offset lands on.
`maxresults`	No	Maximum comments to return, newest first. Max 100.

Output Schema

TableJSON Schema

Name	Required	Description
`cap`	No	The maxresults cap that was applied.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Comments in the returned page.
`notice`	No	How to reach the comments this page left out, or why the station has none on record.
`comments`	No	The requested page of community comments, newest first — offset/maxresults applied. Empty with totalComments 0 means OCM has no check-ins for this station (absence of reports is not evidence the charger works); empty with a non-zero totalComments means the offset is past the last comment.
`stationId`	No	OCM station ID the comments belong to.
`truncated`	No	True when comments were left out of the returned page.
`nextOffset`	No	The offset to pass on an otherwise identical call to read the next page. Absent on the last page.
`totalCount`	No	Comments this station has on record, before the offset/maxresults page was taken — the complete count, not the page size.
`attribution`	No	Required CC BY 4.0 attribution to Open Charge Map contributors.
`stationTitle`	No	Station name, for context.
`isOperational`	No	Whether the registry marks the station operational. Absent when the operational state is unknown. Compare against the comments below — they are the real-world check.
`totalComments`	No	Comments this station has on record — the whole set, before offset/maxresults selected the page in comments. reliabilityNote counts its fault ratio over this population, not over the page.
`registryStatus`	No	Current registry operational status (operator-reported).
`reliabilityNote`	No	A caveat when the registry status, verification age, coordinates, or comments suggest the listing may not reflect reality. Omitted when there is nothing to flag.
`dateLastVerified`	No	ISO 8601 date the listing was last verified. null when never verified.
`registryStatusId`	No	Registry status ID — the value the openchargemap_find_stations statustypeid filter takes. Absent when OCM has no status on record.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed6 schema fields changedAug 25, 2026

changedInput schema / $schema

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

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

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

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "stationId",
+      "stationTitle",
+      "comments",
+      "totalComments",
+      "attribution",
+      "totalCount"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `not_found`: OCM returned an empty result for the given numeric ID (HTTP 200 with []) — no such station. `upstream_unavailable`: OCM returned a non-2xx response or timed out. `auth_failed`: OCM returned HTTP 401 or 403 — the API key is missing or invalid. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "not_found",
+            "upstream_unavailable",
+            "auth_failed"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "stationId",
-  "stationTitle",
-  "comments",
-  "totalComments",
-  "attribution",
-  "totalCount"
-]

Changed9 schema fields changedAug 6, 2026

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Comments to skip before the returned page, for reading past a truncated result. Repeat the same call with the nextOffset value the previous one reported. Ordering is newest-first and stable, but a check-in posted between pages shifts what a later offset lands on.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

changedOutput schema / properties / comments / description

Previous value: -"Community comments, newest first. Empty array means OCM has no check-ins for this station — absence of reports is not evidence the charger works."New value: +"The requested page of community comments, newest first — offset/maxresults applied. Empty with totalComments 0 means OCM has no check-ins for this station (absence of reports is not evidence the charger works); empty with a non-zero totalComments means the offset is past the last comment."

addedOutput schema / properties / nextOffset

Added value: +{
+  "description": "The offset to pass on an otherwise identical call to read the next page. Absent on the last page.",
+  "type": "number"
+}

changedOutput schema / properties / notice / description

Previous value: -"Guidance when the station has no check-ins on record."New value: +"How to reach the comments this page left out, or why the station has none on record."

changedOutput schema / properties / shown / description

Previous value: -"Number of comments returned when the cap was hit."New value: +"Comments in the returned page."

addedOutput schema / properties / totalComments

Added value: +{
+  "description": "Comments this station has on record — the whole set, before offset/maxresults selected the page in comments. reliabilityNote counts its fault ratio over this population, not over the page.",
+  "type": "number"
+}

changedOutput schema / properties / totalCount / description

Previous value: -"Number of comments returned."New value: +"Comments this station has on record, before the offset/maxresults page was taken — the complete count, not the page size."

changedOutput schema / properties / truncated / description

Previous value: -"True when comments were capped at maxresults."New value: +"True when comments were left out of the returned page."

changedOutput schema / required

Previous value: -[
-  "stationId",
-  "stationTitle",
-  "comments",
-  "attribution",
-  "totalCount"
-]New value: +[
+  "stationId",
+  "stationTitle",
+  "comments",
+  "totalComments",
+  "attribution",
+  "totalCount"
+]

Changed5 schema fields changedAug 6, 2026

addedOutput schema / properties / comments / items / properties / checkinStatus

Added value: +{
+  "description": "The visit outcome the driver recorded (e.g. \"Charged Successfully\", \"Failed to Charge (Equipment Not Operational)\"). Carries the result on check-ins that have no comment text. Absent when the visitor recorded no outcome.",
+  "type": "string"
+}

addedOutput schema / properties / comments / items / properties / checkinStatusId

Added value: +{
+  "description": "Numeric ID of the check-in outcome, stable across renames of its title.",
+  "type": "number"
+}

addedOutput schema / properties / comments / items / properties / checkinStatusIsPositive

Added value: +{
+  "description": "Whether the registry classes this outcome as a good visit. Absent when the outcome carries no verdict either way (e.g. \"Did Not Visit Location\") or when none was recorded.",
+  "type": "boolean"
+}

addedOutput schema / properties / comments / items / properties / relatedUrl

Added value: +{
+  "description": "Link the commenter attached. Absent when none was given.",
+  "type": "string"
+}

addedOutput schema / properties / registryStatusId

Added value: +{
+  "description": "Registry status ID — the value the openchargemap_find_stations statustypeid filter takes. Absent when OCM has no status on record.",
+  "type": "number"
+}

Changed4 schema fields changedJul 4, 2026

changedInput schema / properties / id / description

Previous value: -"Numeric OCM station ID. Get one from openchargemap_find_stations. Note: UUID lookup is not supported by the OCM API."New value: +"Numeric OCM station ID."

changedInput schema / properties / maxresults / description

Previous value: -"Maximum comments to return (handler trims, newest first). The OCM API returns all embedded comments — this caps what the tool surfaces. Max 100."New value: +"Maximum comments to return, newest first. Max 100."

changedOutput schema / properties / isOperational / description

Previous value: -"Whether the registry marks the station operational. Absent (not null) when status is Unknown — OCM omits the flag then. Compare against the comments below — they are the real-world check."New value: +"Whether the registry marks the station operational. Absent when the operational state is unknown. Compare against the comments below — they are the real-world check."

changedOutput schema / properties / reliabilityNote / description

Previous value: -"Server-computed caveat when status and comments disagree or the listing is stale (plain prose from observable facts; no synthetic score). Omitted when nothing to flag."New value: +"A caveat when the registry status, verification age, coordinates, or comments suggest the listing may not reflect reality. Omitted when there is nothing to flag."

First observedJun 16, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, and openWorld hints, so the safety profile is known. The description adds valuable behavioral context beyond that: it states the response contains user comments and fault reports with specific outcome values, alongside registry status and last-verified date, and explains pagination semantics ('a page reports truncated', 'repeat with nextOffset') and ordering ('newest-first'). No contradiction with 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 sentences, with the core purpose front-loaded in the first sentence. The second sentence summarizes the output content without unnecessary elaboration, and the third covers pagination concisely. There is no fluff or repetition; every clause earns its place.

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 tool's moderate complexity (3 params, one required), existing output schema, and annotations covering safety, the description provides everything needed to call it correctly: purpose, output content, pagination handling, and ordering. The output schema will document return values, so nothing critical 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% for all three parameters, so the schema already fully documents `id`, `offset`, and `maxresults` including defaults and maximums. The description does not add new parameter-level details beyond what the schema provides; it reinforces the offset pagination behavior but does not extend beyond it. Per the rubric, a baseline 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 uses a specific verb ('Read') and a clear resource ('community check-ins and comments for one Open Charge Map station'), and immediately differentiates itself from siblings by framing it as 'the real-world reliability signal beyond the operator-reported registry status.' An agent can unmistakably identify this as the tool for retrieving user comments for a specific station, distinct from find_stations (search), get_station (registry details), and lookup_reference (reference data).

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 provides clear context on when to use the tool ('beyond the operator-reported registry status') and gives concrete usage for pagination ('when a page reports truncated, repeat the call with the reported nextOffset'). It does not explicitly name alternative tools or specify when not to use it, but the purpose framing effectively guides selection. The pagination guidance is a strong practical instruction.

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

All openchargemap-mcp-server tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a distinct role: discovery (find_stations), retrieval (get_station), community feedback (get_station_comments), and reference lookup (lookup_reference). No two tools overlap in purpose, and the descriptions reinforce their boundaries.

Naming Consistency5/5

All tool names share the 'openchargemap_' prefix followed by a clear verb_noun pattern (find_stations, get_station, get_station_comments, lookup_reference). The naming is uniform and predictive, making it easy for an agent to infer function.

Tool Count5/5

With 4 tools, the server is focused and well-scoped for a read-only EV charging station registry. Each tool serves an essential query need (search, detail, comments, reference data) without unnecessary clutter.

Completeness5/5

The tool set covers the full lifecycle of querying station data: resolving reference IDs via lookup_reference, searching with filters, retrieving detailed records, and accessing community feedback. This is complete for the stated purpose, with no obvious dead ends.

openchargemap-mcp-server: get station comments

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources