openchargemap-mcp-server
Server Details
Find EV charging stations, detail, and reliability check-ins via the global Open Charge Map.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 4 of 4 tools scored.
Each tool has a distinct, non-overlapping purpose: finding stations, getting station details, reading comments, and looking up reference IDs. No ambiguity between them.
All tools follow a consistent 'openchargemap_verb_noun' pattern (find_stations, get_station, get_station_comments, lookup_reference), making the naming predictable and easy to navigate.
With 4 tools, the server is well-scoped for its purpose: search, detail retrieval, community feedback, and reference lookup. Each tool earns its place without excess.
The tool set covers the core workflow for EV charging station information: finding stations, inspecting detailed records, reading community comments, and resolving reference data. No significant gaps are apparent.
Available Tools
4 toolsopenchargemap_find_stationsopenchargemap-mcp-server: find stationsARead-onlyInspect
Find EV charging stations from the global Open Charge Map registry near a point or within a bounding box. Provide either a center (latitude + longitude + distance) or a boundingbox; optionally scope to a country with countrycode. This tool is coordinate-native and does not geocode place names — resolve a place like "Ballard, Seattle" to coordinates with openstreetmap_geocode first, then pass them here. Filter by connector type, minimum power (kW), operator/network, usage type (public/free/membership), charge level, operational status, and minimum charge points. Filter IDs are integers — resolve a connector or network name to its ID with openchargemap_lookup_reference (e.g. "CCS" -> 33). Each result includes title, address, distance from the search point, connections (type, power, count), operator, access rules, registry operational status, and the last-verified date.
| Name | Required | Description | Default |
|---|---|---|---|
| levelid | No | Charge level ID (1=Low <2kW, 2=Medium >2kW, 3=High >40kW/fast). Array OR-matched. Use 3 as a coarse "fast charging only" filter when a specific connector is not required. | |
| distance | No | Search radius from the center point, in the unit given by distanceUnit (default km). Max 500. Keep small (5-25) for dense urban areas; widen for rural coverage. | |
| latitude | No | Center latitude (WGS84 decimal degrees). Use with longitude + distance for a radius search. Resolve place names via openstreetmap_geocode first. | |
| longitude | No | Center longitude (WGS84 decimal degrees). Use with latitude + distance for a radius search. | |
| maxresults | No | Maximum stations to return, ordered by distance from the search point. Max 200. | |
| minpowerkw | No | Minimum charging power in kW across any connection at the station. Use ~50 for DC fast charging, ~150 for high-power DC. Stations whose fastest connection is below this are excluded. | |
| operatorid | No | Operator/network ID, or array of IDs (OR-matched). Resolve a network name with openchargemap_lookup_reference (category "operators") — e.g. "Tesla", "ChargePoint". | |
| boundingbox | No | Bounding-box search as an alternative to a center+radius. Mutually exclusive with latitude/longitude/distance. | |
| countrycode | No | Restrict to one country by ISO 3166-1 alpha-2 code (e.g. "US", "FR", "GB"). Omit for a global search. The server is global by default — there is no implicit country. | |
| usagetypeid | No | Usage/access type ID, or array (OR-matched). Resolve via openchargemap_lookup_reference (category "usagetypes") — e.g. Public=1, Public-Pay At Location=5, Public-Membership Required=4. | |
| distanceUnit | No | Unit for the distance parameter and the returned distance values. | KM |
| statustypeid | No | Registry operational-status ID, or array (OR-matched). Resolve via openchargemap_lookup_reference (category "statustypes"). NOTE: registry status is operator-reported and can be stale — combine with dateLastVerified and openchargemap_get_station_comments to judge real-world reliability, do not treat it as ground truth. | |
| minchargepoints | No | Minimum number of charge points (stalls) at the station. Filters out single-point locations when you need a station likely to have an open stall. | |
| connectiontypeid | No | Connector type ID, or an array of IDs (OR-matched). Resolve names with openchargemap_lookup_reference — e.g. CCS (Type 2)=33, CHAdeMO=2, NACS/Tesla Supercharger=27, Type 2 socket=25, Type 1/J1772=1. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The maxresults cap that was applied. |
| shown | No | Number of stations returned when the cap was hit. |
| stations | Yes | Matching stations, ordered by distance from the search point. |
| truncated | No | True when results were capped at maxresults. |
| totalCount | Yes | Number of stations returned. |
| attribution | Yes | Required attribution to Open Charge Map contributors under CC BY 4.0. |
| searchSummary | Yes | Human-readable echo of the resolved search: location mode, scope, and active filters as the server applied them. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and open-world. The description adds behavioral context: it does not geocode, status is operator-reported and can be stale, and suggests combining with other tools. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but packed with essential information. It is front-loaded with the main purpose. While not bulleted, every sentence contributes value; a slight restructuring could improve scanability.
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 tool's complexity (14 parameters, nested objects, many filters), the description covers all key aspects: input alternatives, prerequisites, filter usage, result fields, and caveats. It references sibling tools appropriately and explains output structure.
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%, meeting the baseline of 3. The description enhances parameter understanding with practical usage tips (e.g., minpowerkw values, statustypeid caveat, connectiontypeid examples), making it more than a bare schema repeat.
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 finds EV charging stations near a point or within a bounding box, using a specific verb and resource. It distinguishes itself from siblings (get_station, get_comments, lookup_reference) by focusing on search and listing.
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 tells when to use this tool: for coordinate-native searches, and provides step-by-step guidance: geocode places first, resolve filter IDs via openchargemap_lookup_reference, and cautions about status staleness. It also advises on parameter values like distance and minpowerkw.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openchargemap_get_stationopenchargemap-mcp-server: get stationARead-onlyIdempotentInspect
Get the full record for one Open Charge Map station by its numeric OCM ID. Returns every connection (type, level, power, current, quantity, per-connection status), the operator and network, usage and access restrictions (pay-at-location, membership, access key), the number of charge points, general comments, usage cost, the data provider, media, and verification recency. Set includeComments to also return community check-ins inline.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric OCM station ID (e.g. 145452). | |
| includeComments | No | Include community check-ins and comments inline in the response. Adds payload but gives the real-world reliability signal alongside the registry status. For comments alone, use openchargemap_get_station_comments. |
Output Schema
| Name | Required | Description |
|---|---|---|
| station | Yes | The full station record. |
| attribution | Yes | Required CC BY 4.0 attribution to Open Charge Map contributors. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds rich behavioral context: it details the returned fields (connections, operator, restrictions, etc.) and warns that includeComments adds payload and provides a reliability signal. No contradictions.
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 (4 sentences) and well-structured: first sentence states purpose, second lists what's returned, third explains includeComments parameter. No waste, every sentence adds value.
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 presence of an output schema, the description does not need to detail every return field. It covers all key aspects of the response and references the sibling tool for comments. Complete and informative.
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%, but the description adds meaning beyond the schema: for includeComments, it explains the trade-off (adds payload but gives real-world reliability signal) and suggests the sibling tool for comments alone. This extra context justifies a 4.
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 it gets the full record for one station by numeric OCM ID. It distinguishes from siblings like openchargemap_find_stations (which lists/finds stations) and openchargemap_get_station_comments (for comments alone).
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?
It tells when to use the tool: to get a full record for a specific station ID. It provides an explicit alternative for comments, but does not fully contrast with find_stations. However, the context implies that if you have an ID, use this; otherwise use find.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openchargemap_get_station_commentsopenchargemap-mcp-server: get station commentsARead-onlyIdempotentInspect
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 and dates, 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."
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric OCM station ID. | |
| maxresults | No | Maximum comments to return, newest first. Max 100. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The maxresults cap that was applied. |
| shown | No | Number of comments returned when the cap was hit. |
| notice | No | Guidance when the station has no check-ins on record. |
| comments | Yes | Community comments, newest first. Empty array means OCM has no check-ins for this station — absence of reports is not evidence the charger works. |
| stationId | Yes | OCM station ID the comments belong to. |
| truncated | No | True when comments were capped at maxresults. |
| totalCount | Yes | Number of comments returned. |
| attribution | Yes | Required CC BY 4.0 attribution to Open Charge Map contributors. |
| stationTitle | Yes | 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. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent behavior. Description adds context about returning comments alongside registry status and surfacing mismatches, providing behavioral insights beyond annotations. No contradiction.
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 sentences, front-loaded with purpose, no unnecessary words. Efficiently conveys key points without extra fluff.
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 existence of an output schema and comprehensive annotations, the description sufficiently covers the tool's value and behavior. It completes the picture by highlighting the mismatch detection feature, making it contextually complete.
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%, thoroughly documenting both parameters. Description does not add additional meaning beyond the schema, so a 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?
Description clearly states the tool reads community check-ins and comments for a specific station, using a specific verb ('read') and resource. It distinguishes from sibling tools like get_station and find_stations by focusing on real-world reliability signals beyond registry status.
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?
Description implies usage for checking real-world reliability but does not explicitly state when to use this tool vs alternatives or mention any exclusions. No direct guidance on when not to use it or which sibling to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openchargemap_lookup_referenceopenchargemap-mcp-server: lookup referenceARead-onlyIdempotentInspect
Resolve Open Charge Map reference data to the integer IDs that openchargemap_find_stations filters require. Pick a category and pass a name or code to resolve — "CCS" or "Tesla Supercharger" -> a connectiontypeid, "ChargePoint" -> an operatorid, "Public - Pay At Location" -> a usagetypeid, "France" or "FR" -> a country. Omit the query to browse the whole category.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum entries to return when browsing or when a query matches several. Max 100. | |
| query | No | Name, title, code, or alias to resolve (e.g. "CCS", "CHAdeMO", "Tesla", "Public", "France", "FR"). Case-insensitive, matches on title, formal name, and known aliases. Omit to browse the entire category. | |
| category | Yes | Which reference set to query. connectiontypes -> connectiontypeid; operators -> operatorid; usagetypes -> usagetypeid; statustypes -> statustypeid; currenttypes -> current type; levels -> charge level (1/2/3); countries -> ISO country. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. |
| shown | No | Number of entries returned when the cap was hit. |
| notice | No | Guidance when a query matched nothing. |
| matches | Yes | Matching reference entries, best/exact match first. |
| category | Yes | The reference category queried. |
| truncated | No | True when a browse was capped at limit. |
| totalCount | Yes | Number of entries returned. |
| attribution | Yes | Required CC BY 4.0 attribution to Open Charge Map contributors. |
| filterParam | No | The find_stations input parameter these IDs feed (e.g. "connectiontypeid"). Omitted for categories with no direct filter (currenttypes; countries use countrycode). |
| snapshotDate | Yes | Date the bundled reference snapshot was captured, so callers know the data vintage. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: case-insensitivity, matching on title/formal name/aliases, and browsing when query omitted. Annotations already indicate read-only and idempotent, and the description does not contradict them.
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 remarkably concise: two sentences. The first sentence states the primary purpose, and the second packs multiple usage examples without redundancy. Every word 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?
Given the tool's moderate complexity (3 params, 100% schema coverage, output schema exists), the description fully covers all needed context: resolution mechanics, category mapping, query flexibility, and limit constraints. Nothing is missing.
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 schema descriptions already explain parameters. The tool description enhances this by showing how each category maps to ID types and giving examples (e.g., 'CCS' -> connectiontypeid). It also clarifies that query is optional for browsing.
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 resolves reference data (names/codes) to integer IDs needed by the sibling tool openchargemap_find_stations. It provides specific examples per category, making the purpose distinct from siblings which deal with stations/comments.
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 tells when to use it (to resolve names/codes to IDs for filters) and provides concrete examples for each category. It also notes that omitting the query browses the entire category, giving clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!