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

Annotations already mark the tool as read-only and open-world, so the safety profile is covered. The description adds useful behavioral detail: it delegates to ANWB EV route planning, requires specific EV inputs, and returns distance, duration, battery consumption, charging stops, and nearby charging stations. 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?

Every sentence earns its place: action, required inputs, outputs, and coordinate format with a pointer to find_locations. No filler or repetition of schema fields.

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 tool with no output schema, the description gives enough about return values and prerequisites. It mentions the related find_locations tool, explains the locations serialization, and makes the tool's EV-specific scope clear. The remaining parameter details are already in the schema.

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?

The input schema has 100% description coverage, so the schema carries most parameter meaning. The description reinforces the locations format and prerequisite workflow, but does not add new details beyond the schema for parameters like carId, capacity, or stateOfCharge. Baseline 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?

The description opens with a specific verb and resource: 'Calculate an electric vehicle route between two or more locations using ANWB EV route planning.' This clearly distinguishes it from general routing tools like calculate_route and also states the key outputs the agent can expect.

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 gives clear usage context: use for EV routes requiring car ID, battery capacity, and state of charge. It also explicitly instructs the agent to 'Use find_locations first to get coordinates for place names.' It does not explicitly name calculate_route as the non-EV alternative, but the EV-specific framing implies the distinction.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower. The description adds useful behavior beyond those flags: it returns distance, duration, turn-by-turn directions, toll information (car/caravan only), and optional alternative routes. This communicates mode-dependent behavior and response content 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the core purpose appears first, followed by concrete format guidance and a prerequisite. Every sentence earns its place without redundant restatement of the tool title or schema.

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 read-only route calculation tool with no output schema, the description covers the essential prerequisites, coordinate format, supported modes, and return contents. The rich input schema fills in parameter-level details like routeType and avoid options, 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 description coverage is 100%, so the schema already documents every parameter. The description adds a clear coordinate-pair example and the find_locations workflow, but it does not materially deepen the meaning of parameters beyond what the schema already provides.

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 a specific action ('Calculate a route'), the resource ('between two or more locations using ANWB route planning'), and the supported modes (car, caravan, bike, pedestrian). This makes it straightforwardly distinct from siblings like calculate_ev_route or get_traffic_summary, even without naming them.

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 gives explicit practical guidance to 'Use find_locations first to get coordinates for place names', and clarifies supported travel modes. It does not explicitly say when to prefer calculate_ev_route over this tool, but the mode list and ANWB context give a clear usage envelope.

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

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

The annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by noting that results include coordinates and that they are meant for route planning, but it does not go deeper into result ordering, empty-result behavior, or how 'matching' is determined.

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 concise sentences with no filler. The first sentence states what is searched and where, and the second states the output value and downstream use. Every sentence 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?

With no output schema, the description still covers the essential return value (coordinates) and the downstream purpose (calculate_route). Combined with the fully documented input schema and annotations, an agent has enough context to invoke the tool correctly and interpret results. Minor details like coordinate format or handling multiple matches would improve completeness but are not critical.

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 schema already documents query, area, limit, and indexSets thoroughly. The description only implicitly relates to the query parameter by mentioning searchable entity types; it adds no extra meaning beyond the schema, so the 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?

The description uses a specific verb ('Search') and names the exact resource types: locations, addresses, streets, cities, and points of interest. It also states the geographic scope and that the tool returns coordinates, which clearly differentiates it from the route-calculation and traffic sibling tools.

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 the agent when to use this tool: to find coordinates for the calculate_route tool. It does not spell out exclusions or when NOT to use it, but the intended context is clear and the sibling tools are distinct enough that an agent can correctly select this one.

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

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

With readOnlyHint and openWorldHint annotations covering safety and world-data behavior, the description adds useful context by naming ANWB as the source, stating the data is current, and enumerating incident categories. Annotations are not contradicted.

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 compact sentences: purpose, output contents, and filtering behavior. Each sentence contributes distinct information and the most important scope ('current traffic incidents on Dutch highways') is front-loaded.

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 simple read-only tool with no required parameters, the description tells an agent what will be returned (jams, closures, roadworks, speed camera locations) and how to filter. It does not specify the exact response shape, but no output schema exists and the listed categories provide enough for invoking the tool.

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%, so the parameters are already fully documented. The description repeats the filter concepts ('Optionally filter by road and/or category') and examples like 'A1', but adds little semantic value beyond the schema.

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 opens with a specific verb and resource: 'Get current traffic incidents on Dutch highways from ANWB.' It enumerates the returned entity types (jams, closures, roadworks, speed cameras), which distinguishes it from summary/route/location siblings.

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 intended use is clear: call this when current Dutch highway incident data is needed, optionally narrowed by road and category. It does not explicitly name siblings or state when not to use them, but the context is unambiguous enough that no exclusion is needed.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds that the result is compact/aggregated, scoped to all highways, and composed of total counts rather than detailed incident records. It does not address freshness or potential limitations, but the annotations already cover the safety profile.

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?

A single, well-structured sentence delivers the purpose, scope, and output composition without any redundant filler. Information is efficiently front-loaded.

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 zero-parameter, read-only summary tool, the description is complete: it names what counts are returned, the geographic scope, and the temporal nature. No output schema exists, but the return content is described explicitly.

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?

The input schema has zero parameters, so there is no parameter documentation burden. The description reinforces that the tool takes no arguments by describing an all-highways aggregate result.

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 names a specific action ('Get') and resource ('compact summary of current traffic conditions on Dutch highways'), and enumerates the exact outputs (counts of jams, closures, roadworks, radars). This clearly separates it from sibling tools like get_traffic_incidents, which would provide more granular incident data.

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 provides clear context: use this tool when you need a high-level numeric snapshot across all Dutch highways. It does not explicitly state when not to use it or direct the agent to an alternative for detailed incident-level traffic information.

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

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

Annotations already mark the tool as read-only, so the description need not restate safety. It adds useful behavioral context by naming the source database, the output fields, and the available filters. It omits details like pagination or ordering, but for a read-only list tool this is not a critical gap.

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-load purpose and return values, then give the downstream workflow and filter options. Every sentence earns its place, and there is no redundant or filler wording.

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?

With two optional parameters and no output schema, the description provides the essential operational knowledge: what the tool lists, what fields are returned, how to use those results with calculate_ev_route, and how to filter. It is complete enough for an agent to select and invoke the tool correctly.

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%: both 'make' and 'search' already have clear descriptions and examples in the schema. The description merely restates 'filter by make (brand)' and 'search by model name,' adding no new parameter meaning beyond what the schema already provides. Baseline 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?

The description opens with a specific verb and resource: 'List available electric vehicle models from the ANWB database.' It names the exact return fields (car IDs, make, model, version, battery information) and points to calculate_ev_route as the downstream consumer, which clearly distinguishes it from the route-planning sibling tools.

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 gives explicit usage context: 'Use the car ID with calculate_ev_route to plan an EV route.' It also explains the optional filters. It does not enumerate when not to use this tool or explicitly compare it to alternatives, but the workflow guidance is clear.

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