Find the cheapest EV charging stations in France, Benelux, and Denmark based on your specific car and charging cards.
Scored across 3 tools
Each tool has a distinct resource and action: find_vehicle resolves the car, list_charging_cards resolves the driver's cards, and search_chargers performs the price search. Descriptions even explain how the IDs chain together, leaving no plausible misselection.
All three names follow a strict snake_case verb_noun pattern (find_vehicle, list_charging_cards, search_chargers). The verbs also accurately signal the cardinality of results (find vs list vs search).
Three tools is on the lean side but each is essential to the single workflow and clearly earns its place. It is well-scoped for a focused charger-matching service, just slightly under what a fuller feature set might offer.
The surface covers the full workflow from vehicle identification through card lookup to charger search, with sensible chaining and guidance output. Minor gaps exist, such as fetching details for a single charger or reusing a saved session, but these are workable around.
Find the exact version of the driver's electric car, to get its vehicle_id.
The car decides compatible plugs, the power it can draw and its battery
size, so it changes every price. Returns up to 8 versions, newest first. If
they differ in battery or power, ask the driver which one (or ask for the
year and search again with a more precise query).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Make and model, optionally version or year, e.g. "Tesla Model 3 Long Range 2024". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only and open-world profile, but the description adds real behavioral detail: results are capped at 8 versions and returned newest first. It does not cover failure modes (e.g., no match found), so it falls slightly short of full disclosure.
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?
Three short sentences: purpose first, rationale second, behavior and fallback third. The middle sentence on plug/power/battery rationale is arguably expendable, but it is front-loaded and readable with no wasted filler.
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?
For a single-parameter lookup with no output schema, the description supplies everything needed: the return cardinality, sort order, and an ambiguity-resolution procedure. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'query' parameter is already documented with an example. The description reinforces query refinement (adding a year for precision) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource ('Find the exact version of the driver's electric car') and names the concrete output goal ('to get its vehicle_id'). It also explains why the vehicle matters (it determines compatible plugs, power draw, and battery size, which drive price), which no sibling tool addresses.
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?
Gives an explicit fallback path when results are ambiguous: if versions differ in battery or power, ask the driver which one, or request the year and re-search with a more precise query. This tells the agent both when to use the tool and how to disambiguate afterward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List charging cards and subscriptions, to get the card_ids of the ones the driver has.
A card or plan the driver owns can make a charger cheaper than its walk-up
price. One label can cover several ids: pass all of them.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Part of the card or subscription name, e.g. "chargemap". Empty for the most common ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: a single label may map to multiple ids and all of them must be passed, which affects how the caller uses the result. It omits return shape and pagination, keeping it short of a 5.
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?
Three short sentences, front-loaded with the purpose before the rationale. Each sentence carries information, though the middle sentence is slightly conversational rather than directive.
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?
No output schema exists, and the description partly compensates by indicating that card_ids are the payoff, but it does not describe the returned structure or whether results are paginated. For a simple single-parameter list tool this is nearly sufficient.
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 the query parameter is already documented with an example ('chargemap') and default behavior. The description adds nothing about the query parameter itself; the 'pass all of them' note concerns downstream ids rather than this input. Baseline 3 applies.
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?
States a specific verb and resource ('List charging cards and subscriptions') plus the outcome it enables ('to get the card_ids of the ones the driver has'). Siblings find_vehicle and search_chargers cover clearly different resources, so an agent can route without ambiguity.
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?
Gives a clear motivating context: use this to obtain card_ids, and explains that an owned card/plan can beat a charger's walk-up price. It does not name an explicit alternative or a when-not condition, but the trigger condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the cheapest chargers within 3 km of a place, for this car and these cards.
Before the first search of a conversation, unless you already know them,
ask the driver in one question for their car and their charging cards or
subscriptions ("none" is fine), then use find_vehicle and
list_charging_cards. Reuse vehicle_id and card_ids afterwards.
Takes 5 to 20 seconds. Returns up to 10 offers sorted by total price, a
link that opens the full list and map, and `guidance`: follow it when you
answer.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | City, address, station or postcode. Use this, or latitude and longitude. | |
| card_ids | No | From list_charging_cards: every id of every card the driver has. | |
| latitude | No | Use with longitude when the driver's position is known. | |
| longitude | No | ||
| energy_kwh | No | Energy to add, instead of battery percentages. | |
| vehicle_id | No | From find_vehicle. Omitted: a default car (Renault 5). | |
| charger_speed | No | "normal" by default; "fast" if the driver is in a hurry, on a motorway or names a fast network; "slow" for overnight or long parking. | normal |
| battery_start_pct | No | ||
| battery_target_pct | No | ||
| accepts_operator_app | No | False if the driver refuses to install an operator's app. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds meaningful behavior beyond that — a 5–20 second latency window, a cap of 10 offers sorted by total price, a returned link to the full list/map, and a `guidance` field the agent is told to follow when answering. This is exactly the operational context annotations cannot convey.
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?
Front-loads the purpose, then the workflow instruction, then the runtime/return contract — a sensible order. The prose is tight and every sentence is actionable, though the three-block layout runs slightly long for the amount of information conveyed.
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?
For a 10-parameter, no-output-schema tool, the description covers the key gaps: how to source the ids, latency expectations, result count/sorting, and the `guidance` return value. The remaining battery/energy parameters are adequately covered by the schema, so nothing critical 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 70%, so the schema documents most parameters itself. The description reinforces the provenance of vehicle_id and card_ids (from find_vehicle / list_charging_cards) and implies the place-based 3 km search, but says nothing about battery_start_pct, battery_target_pct, energy_kwh, charger_speed, or accepts_operator_app beyond what the schema already states.
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?
States a specific verb (find), resource (chargers), and scope (cheapest, within 3 km of a place, for this car and these cards). An agent can immediately tell this apart from the lookup siblings find_vehicle and list_charging_cards, which are named as inputs rather than alternatives.
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?
Gives explicit sequencing: before the first search of a conversation, ask the driver for car and cards in one question, then call find_vehicle and list_charging_cards, and reuse vehicle_id/card_ids afterwards. It names the prerequisite tools and the state to carry forward, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_vehiclelist_charging_cardssearch_chargers
Add one secure layer between your agents and this server.