slimwegdoen

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value by disclosing the shape of the answer (cost, conditions, appointment link, official source, milieustraten), which is the main behavioral unknown for a lookup tool with no output schema.

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 front-loaded sentence that leads with the core question and then lists the payload. Dense but every clause maps to actual returned content; the trailing 'Plus de milieustraten' is slightly tacked-on but still 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 must convey return content, and it does so thoroughly (collection, cost, conditions, appointment link, source, milieustraten). What is missing is only edge-case behavior, e.g. what happens for an unknown or ambiguous plaats.

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?

Only one parameter with 100% schema description coverage ('Gemeente, woonplaats of postcode in Nederland'), so the schema already does the work. The description adds nothing about accepted input forms or fallback behavior when a postcode spans municipalities, which is the baseline-3 outcome.

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?

Names a specific resource (grofvuil) scoped to a Dutch municipality and enumerates exactly what the answer contains: collection responsibility, cost, conditions, appointment link, official source, and milieustraten. It does not explicitly contrast with the siblings plekken_in_de_buurt or waar_kan_dit_heen, so it stops short of a 5.

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?

Usage is only implied: an agent can infer this is the tool for 'how does bulky waste work in municipality X'. There is no explicit when-to-use statement, no exclusion, and no pointer to the sibling tools for adjacent questions such as where to bring a specific item.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds real value beyond that: the data source (slimwegdoen.nl), the geographic scope (a location in the Netherlands), and the returned fields including whether a location offers pickup. It omits how many results come back or how 'nearest' is bounded, which is a minor gap for a lookup tool.

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 front-loaded sentence leading with the verb and resource, followed by the optional filter and return fields. No filler, though the inline kind enumeration is dense and could be left to the 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?

With only two parameters, full schema coverage, and rich annotations, the description covers what is missing structurally by naming the return fields (address, distance, pickup) in the absence of an output schema. Only the result-count/limit behavior is left unstated.

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 baseline is 3, but the description goes further by spelling out the concrete kinds behind the enum (kringloopwinkels, opkopers, repaircafés, weggeefplekken, goede doelen, milieustraten) and clarifying that 'plaats' is any Dutch place/address. It does not mention the 'bouwmateriaal' and 'alles' enum values, so the mapping is slightly incomplete.

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: it returns the nearest 'plekken' from slimwegdoen.nl around a Dutch location, optionally filtered by kind, with the data source and returned fields named. It is clear what the tool does, but it never names or contrasts the siblings (grofvuil_in_gemeente, waar_kan_dit_heen), leaving the agent to infer the boundary between searching for reuse/donation spots versus waste-disposal lookup.

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?

'Eventueel van één soort' implies how to narrow the search, so usage is implied rather than stated. There is no explicit when-to-use, when-not-to-use, or 'use X instead when…' guidance, which matters given two closely related siblings in the same waste-avoidance domain.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: the data source (slimwegdoen.nl with ~5,800 thrift shops, buyers, repair cafés, charities and waste depots) and what the answer contains (advice, two alternatives, distance, pickup availability, bulky-waste rules for that municipality). Geographic scope (Netherlands only) is also implicit but clearly stated.

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 sentences, front-loaded with the core action and the R-ladder ordering, then data source, then output contents. Dense but every sentence carries information; the parenthetical inventory count could arguably be trimmed, but it sets expectations about coverage.

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?

There is no output schema, so the description must explain return values, and it does list the concrete components of the answer. Combined with the disclosed data source and geographic scope, an agent has enough to call this correctly; only the treatment of the optional staat parameter and failure modes (no location found) are left open.

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% and the one enum parameter (staat) is documented in the schema itself, so the baseline applies. The description adds only the framing that the item is described 'in gewone woorden' and that the location is Dutch, which barely goes beyond the schema. It does not explain how staat influences the R-ladder starting point, which would have been a useful addition.

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: for one item plus one Dutch location it returns the best disposal address, ordered along the R-ladder (sell, give away, thrift, repair, recycle, waste depot). The R-ladder ordering and the 'beste adres' framing make it distinguishable from the sibling tools grofvuil_in_gemeente and plekken_in_de_buurt without opening either schema.

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?

Usage is implied by the phrasing 'voor één voorwerp en een plek in Nederland', which signals the single-item, single-location case. It never states explicitly when to prefer it over grofvuil_in_gemeente (which sounds like the municipal bulky-waste lookup this tool partly folds in), nor any exclusions. Adequate but leaves routing to inference.

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