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.7/5 across 4 of 4 tools scored.
Each tool has a distinct, non-overlapping purpose: searching stations, retrieving details, reading community comments, and looking up reference IDs. No ambiguity exists between tools.
All tools follow the consistent verb_noun pattern with the 'openchargemap_' prefix: find_stations, get_station, get_station_comments, lookup_reference. No deviations.
With 4 tools, the server is well-scoped for its domain. Each tool serves a necessary function without bloat or deficiency, covering search, detail, community feedback, and reference data.
The toolset covers the full lifecycle of querying EV charging stations: finding, retrieving details, gathering user reports, and resolving filter IDs. No obvious gaps for a read-only registry.
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 — treat an old dateLastVerified or a non-operational status as a reliability caveat.
| 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. Larger values cost more payload and upstream load — prefer tightening filters over raising this. | |
| 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?
Description supplements annotations (readOnlyHint, openWorldHint) with critical behavioral traits: it is coordinate-native and does not geocode, and it cautions about reliability of last-verified date and registry status. 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 well-structured and front-loaded but somewhat lengthy. However, every sentence contributes meaningful information, so it remains efficient. A slight trim could improve conciseness, but overall it is clear and organized.
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, no required params, nested objects, output schema present), the description covers all necessary aspects: search modes, parameter interpretations, ID resolution, reliability caveats, and result contents. No gaps identified.
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%, but the description adds significant value beyond schema: it explains use cases for levelid, provides example IDs for connection types and usage types, and gives practical advice on distance and maxresults. This helps the agent choose appropriate values.
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 from the global registry, specifying 'Find EV charging stations...near a point or within a bounding box.' It distinguishes itself from siblings by mentioning the need to pre-geocode place names and resolve filter IDs using other tools, making the purpose unambiguous.
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 provides explicit guidance on when to use center vs bounding box, how to resolve place names and filter IDs, and includes tips like using levelid=3 for coarse fast charging and keeping distance small for urban areas. It also warns about stale registry status, suggesting complementary tools.
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. Obtain an ID from openchargemap_find_stations.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric OCM station ID (e.g. 145452). Obtain one from openchargemap_find_stations. Note: UUID lookup is not supported by the OCM API. | |
| 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 | Server-computed caveat when registry status and recency suggest the listing may not reflect reality (plain prose from observable facts; no synthetic score). Omitted when status is fresh and uncontested. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint. Description adds details about what the record contains and notes that includeComments adds payload and reliability signal, adding context beyond 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?
Two well-structured sentences, front-loaded with purpose, every sentence adds value without redundancy.
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 presence of output schema, description covers purpose, parameter usage, and contextual distinctions from siblings. No apparent gaps.
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% with good descriptions. Description adds meaning by explaining that includeComments adds payload and contrasts with the comments-only tool, and notes that ID must be numeric.
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 sibling tools by referencing openchargemap_find_stations for obtaining IDs 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?
Explicitly says when to use (to get full record), how to obtain the ID, and points to the alternative for comments. Lacks explicit 'when not to use' but provides clear context.
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 so you can flag mismatches like "listed operational, but the last few check-ins report a fault." Obtain a station ID from openchargemap_find_stations.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric OCM station ID. Get one from openchargemap_find_stations. Note: UUID lookup is not supported by the OCM API. | |
| maxresults | No | Maximum comments to return (handler trims, newest first). The OCM API returns all embedded comments — this caps what the tool surfaces. 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 (not null) when status is Unknown — OCM omits the flag then. Compare against the comments below — they are the real-world check. |
| registryStatus | No | Current registry operational status (operator-reported). |
| reliabilityNote | No | 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. |
| 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?
The description adds substantial behavioral context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) by detailing the returned data: user comments, fault reports, ratings, dates, registry status, and last-verified date. It also explains the cross-referencing use case. 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), front-loaded with the main action, and efficiently conveys purpose, use case, and integration hints without redundancy.
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 has two well-documented parameters and an output schema exists, the description sufficiently covers the tool's purpose, usage, and output expectations. It explains the return elements and the practical application, leaving no critical gaps.
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% with descriptions for both parameters. The description adds value by explaining how to obtain the station ID and clarifying that maxresults caps the surfaced comments (not the API response). This goes beyond the schema's basic descriptions.
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 reads community check-ins and comments for a specific station, emphasizing its role as a real-world reliability signal beyond operator-reported status. It distinguishes from siblings like openchargemap_find_stations (which obtains station IDs) and openchargemap_get_station (likely station details).
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 provides clear context for when to use the tool (to get real-world reliability) and instructs to obtain a station ID from openchargemap_find_stations. However, it does not explicitly state when not to use it or mention alternative tools beyond the implicit distinction from operator-reported status.
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. Served from a bundled snapshot — offline and instant. Use the returned id(s) in openchargemap_find_stations.
| 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. Use the id in a find_stations filter. |
| 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?
Annotations already indicate readOnly, idempotent, and not openWorld. The description adds valuable context: 'served from a bundled snapshot — offline and instant,' which clarifies behavior beyond 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 compact yet comprehensive, front-loading purpose, then examples, then browsing, then offline note, then direction to the intended output consumer. No unnecessary words.
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 (3 params, 1 required, enum), the description fully explains input, output, behavior, and integration with sibling tool. Output schema exists but is not needed for completeness.
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?
With 100% schema coverage, the description still adds significant meaning: explains query case-insensitivity, alias matching, mapping from category to ID type, and browsing behavior. Examples clarify usage.
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's action: resolving reference data to integer IDs for use as filters in openchargemap_find_stations. It distinguishes from sibling tools (station lookup/comments) by its unique purpose.
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 explains when to use (to get IDs for filters), provides examples for each category, and mentions browsing. It does not explicitly state when not to use, but the context makes it clear.
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!