Essentially Amsterdam

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the provenance (police open data), the comparison window (latest year against the year before), the normalization and ranking, and the default result size. It does not say what happens on an unrecognized neighbourhood or whether matching is exact or fuzzy, which keeps it below 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?

A single tight sentence with the subject and geography front-loaded, followed by the comparison window, unit, ranking, default behavior, and an example — every clause contributes information an agent would otherwise have to guess.

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 one-optional-parameter lookup with no output schema and rich annotations, the description covers provenance, units, ranking, default output, and an example. Only edge behavior (unknown neighbourhood names, how district-level values relate to neighbourhood rollups) 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 description coverage is 100% and the single parameter already documents optionality, examples, and accepts both neighbourhoods and districts. The description reinforces the example and adds the no-input default, which is useful but largely duplicative of structured data, so the baseline of 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?

The description names a concrete resource and metric — bicycle and moped thefts per Amsterdam neighbourhood, from police open data — plus the unit (per 1,000 residents) and the ranking. It is immediately distinguishable from every sibling tool (conferences, jobs, markets_today, etc.), with no ambiguity about what is returned.

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 states the default invocation path explicitly ("no input gives the top 10") and supplies a worked example (neighbourhood='Oude Pijp'), so an agent knows a zero-argument call is valid. What's missing is any explicit exclusion or note on when a caller should instead query a different tool, though the sibling list offers no real alternative for this data.

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 genuine behavior beyond them: a hard cap of 10 results, soonest-first ordering, and the fact each date is verified on the conference's own page, plus what each record carries (venue, field, links).

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?

One dense sentence plus a short example, front-loaded with the resource and scope. The example duplicates the schema's YYYY-MM pattern, so it is slightly redundant rather than wasteful.

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 two-optional-parameter lookup with no output schema, the description covers result size, ordering, return contents and data provenance. It does not say how empty results or a month with no conferences are reported, which is a minor gap given the tool's simplicity.

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 enum for 'field' is fully documented, so the schema carries parameter meaning. The description only echoes the month format with an example ('2026-12'), which the schema's pattern and description already cover, and says nothing about the field filter.

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-less but precise resource and scope: upcoming Amsterdam conferences, with the result cap and ordering. An agent can tell this is a local-events lookup, though the description never names a sibling like whats_on, so differentiation is left to inference.

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 'Upcoming' and the note that the default window starts from today, which tells the agent this is a forward-looking listing. There is no explicit when-to-use versus whats_on or guide_search, and no statement about what happens for past months or empty results.

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, closed-world and non-destructive behavior, so the safety profile is covered. The description adds value beyond that by stating the result cap ('up to 10 listings') and the returned fields (category, area, link), which matters because there is 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?

Two short sentences, front-loaded with the verb and scope, then a concrete example. The example largely duplicates the schema's own example string, so one clause is redundant, but nothing is bloated.

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 search tool with no output schema, the description supplies the essentials: what is searched, what comes back, and how many results. The only meaningful gap is the absence of routing guidance versus guide_search.

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 parameter already carries examples ('yoga', 'bakery Jordaan'), so the schema does the heavy lifting. The description restates the same example and adds the notion of combining name, type and area in one string, which is a modest but real clarification.

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 gives a specific verb and resource ('Search local businesses in our Amsterdam directory') plus the search dimensions (name, type, area), which separates it from siblings like markets_today or jobs. It does not, however, explicitly contrast itself with the closest sibling, guide_search, which an agent might reasonably confuse with a business directory.

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 rather than stated: the agent can infer this is the tool for finding Amsterdam businesses, and the example 'bakery Jordaan' shows a combined name+area query. There is no explicit when-not guidance or named alternative such as guide_search for editorial content.

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 establish readOnly, idempotent, non-destructive and closed-world behaviour, so the bar is lower. The description still adds useful context the annotations don't carry: the result shape (up to 10 pages, each with a summary and a link) and the fact that both English and Dutch sources are searched, which matters since no output schema exists.

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?

One tightly packed sentence with the topic, languages and result shape front-loaded, followed by a short example. The example largely repeats the one in the schema, which is the only 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?

For a one-parameter read-only lookup tool this covers the essentials: what corpus is searched, which languages, how many results, and what each result contains. Only edge behaviour (zero results, mixed-language results) is unaddressed, which is minor given the annotations and the simplicity of 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?

With one parameter at 100% schema description coverage, the schema already defines query including its length limits and gives examples. The description's main addition is that the query can be a natural-language question phrased in English or Dutch, plus its own near-duplicate example, so the marginal value is modest.

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 and names the resource precisely: guides, free tools or best-of lists about living in or visiting Amsterdam, in English or Dutch. It returns 'up to 10 pages with summary and link'. It never names a sibling, so the distinction from directory_search or recent_news is inferred rather than stated.

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 context is clear: it is for questions about living in or visiting Amsterdam, illustrated with a concrete example query ('how do I get a BSN'). It gives no exclusions and doesn't mention when to prefer directory_search or whats_on instead, so an agent must infer the boundary from the topic 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 this a safe, idempotent read of a closed dataset, so the description's value is in result behavior – and it delivers: a hard cap of 10 items, the returned fields (company, area, salary only when published, link), and the source board. It omits how far back 'newest' reaches and the ordering/tie-breaking, which is the only meaningful 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?

Two compact sentences with zero filler: the result scope and cap come first, the returned fields second, and the example last. Nothing is redundant with the title.

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 one optional parameter, no output schema, and full safety annotation coverage, the description supplies exactly what is missing – the return shape and the 10-item limit. Only the recency window behind 'newest' and whether results can be empty are left unstated, which is a minor deficiency.

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 schema already explains that the keyword matches title, company, area or ad. The description's single added contribution is a concrete example value ('data engineer'), which is mildly useful but does not extend the semantics beyond the schema. 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?

The description states a specific verb and resource ('newest English-language jobs in the Amsterdam area'), names the data source ('our job board'), and bounds the result ('up to 10'). An agent can distinguish this immediately from siblings like recent_news, whats_on, or net_salary without opening the 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 content ('newest jobs in Amsterdam') and an example query is given, but there is no explicit when-to-use/when-not guidance and no named alternative for related queries (e.g. salary questions routed to net_salary). 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.

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the bar is lower. The description adds value by disclosing the shape of the result (opening hours plus a link to the market guide), which matters since there is 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?

Two tight sentences with the resource and default stated up front and the example tacked on at the end. No filler, though the example is somewhat redundant with the schema pattern.

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 optional-parameter read tool with no output schema, the description covers scope, default behavior, and return contents. Only the absence of alternative-routing guidance keeps it from full marks.

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 date parameter already documents the YYYY-MM-DD pattern, Amsterdam time, and today default. The description largely restates this, adding only a worked example, so 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 names a specific resource and scope: street and food markets in Amsterdam, plus what is returned (hours and a guide link). It doesn't explicitly contrast itself with siblings like whats_on or directory_search, keeping it just below 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 implied by 'open on a day (default today)' plus a concrete example date, so an agent can infer the single-date lookup pattern. There is no explicit when-to-use vs. when-not guidance or pointer to an alternative tool.

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 a safe, idempotent read against a closed-world directory, so the description only needs to add result behavior. It does so by stating the midpoint calculation, venue types, directory source, and cap of 10 results with links. It still omits geocoding/error behavior and the exact response shape, keeping it below the top score.

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 compact sentences front-load the purpose and then supply one useful example; no sentence is filler. The inline example earns its place by showing accepted postcode/address forms.

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 four-parameter read-only lookup with no output schema, the description covers the computation, input scope, venue filter, and return limit. It leaves output field details to inference, but the core contract an agent needs to invoke it is present.

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 address_a, address_b, address_c, and kind documented inline. The description reinforces the address/postcode format with an example and clarifies that address_c makes the input two-or-three locations, but adds little parameter meaning 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?

States a specific action: computes the halfway point between two or three Amsterdam addresses/postcodes and returns nearby cafes, restaurants, and bars. The Amsterdam scope, directory source, and up-to-10 result limit distinguish it from a generic directory search.

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 purpose and inline example make the meeting-planning use case clear, and 'two or three' signals when address_c applies. It does not explicitly say when to prefer this over siblings such as nearest or directory_search, so guidance stops short of full alternatives.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes further by naming the underlying dataset size and enumerating the three return values. With no output schema present, that return-value disclosure is genuinely useful; only the handling of unknown museum names is left unstated.

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 the core question the tool answers, then the data source and outputs, then a compact example. Nothing is redundant or padded.

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 small read-only calculator with full schema coverage and no output schema, the description supplies the missing piece: what the result contains. It falls slightly short by not indicating that age and visit frequency change the verdict or what an unrecognized museum name produces.

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 all three parameters are already documented, and the description adds little beyond restating the museum-array shape with a duplicate example. The mention of 32 museums implicitly reinforces the maxItems cap, but the age and visits_per_year parameters go unmentioned in the description.

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 states a specific computation (whether a Museumkaart pays off), the domain it applies to (Amsterdam museums), the data behind it (ticket prices for 32 museums) and the outputs it produces (ticket total, card price, saving). No sibling tool does anything comparable, so an agent can route to it unambiguously.

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 context is clear: it is for someone planning museum visits who wants a break-even verdict, and the 32-museum price list implicitly bounds which museums are valid inputs. There is no explicit when-not guidance (e.g. what happens for museums outside the dataset), but with no overlapping siblings there is little alternative to disambiguate against.

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 them: the data provenance (city open data), the result ceiling of 10, and the shape of the returned payload (distance plus opening times or equipment). It omits edge behaviour such as empty results or invalid locations, keeping it just 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?

One dense, front-loaded sentence covering resource, scope, result cap and return contents, followed by a compact invocation example. No filler, no restatement of the title, and the most decision-relevant information comes first.

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 fully documented parameters and no output schema, the description must carry the return-value burden, and it largely does (distance, opening times or equipment, max 10 items). What remains unstated is failure behaviour and whether results are sorted by proximity, a minor gap for a tool this simple.

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 schema already enumerates 'kind' and gives the exact 'near' examples ('Jordaan', '1017', 'Dam 1') that the description repeats. The only added meaning is the inline example pairing kind='toilet' with near='Jordaan', which is useful but mostly duplicative, 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?

The description names a specific verb and resource ('nearest public toilets or playgrounds'), scopes it geographically ('to Amsterdam neighbourhood, postcode or address'), and states the data source ('city open data'). It also pins down the result cap ('up to 10'), which lets an agent distinguish this from any generic search sibling.

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 domain rather than stated: the tool is self-evidently for finding nearby facilities in Amsterdam, and no sibling tool overlaps it. There is no explicit when-not-to-use guidance or prerequisite statement (e.g. what happens with an out-of-city address), so it sits at the implied-usage level.

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 establish readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the calculation source (Belastingdienst tables), the 2026 tax year, and the shape of the result (monthly and annual net plus a tax breakdown). It stops short of stating assumptions such as pension contributions or other deductions being excluded.

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?

Effectively one dense sentence plus a compact example, both front-loaded with jurisdiction and capability before the example. The phrase 'as on our net salary calculator' is faintly promotional and adds little a calling agent can act on, but the definition is otherwise free of padding.

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 five parameters, full schema coverage and no output schema, the description does the one job structured data cannot: it tells the agent what comes back (monthly and annual net plus a tax breakdown) and which official tables underpin it. What remains unstated is the scope boundary of the calculation — which deductions and allowances are excluded — which an agent quoting a result to a user could reasonably want.

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 every parameter — including the enum on period and the interaction between ruling_30 and under_30_with_masters — is already documented in structured fields. The description's only added value is a concrete parameter combination in the example (gross=60000, period='yearly', ruling_30=true), which is marginal over the schema's own 'e.g. 60000 a year'.

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 ('gross-to-net pay'), pins the jurisdiction and tax year (Dutch, 2026, Belastingdienst tables), and names the optional 30% ruling variant. The return content ('net per month and year plus the tax breakdown') further disambiguates it from every sibling, none of which touch payroll.

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 domain ('Dutch ... 2026') implies when the tool applies, and the worked example shows a valid invocation, but there is no explicit when-to-use/when-not-to-use statement — e.g. that it does not cover non-Dutch income, other income years, or employer-side costs. No alternative tool is named, though the sibling list contains none that overlap.

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 behavior, so the description's job is lighter. It still adds real value by disclosing the result cap (up to 10) and the returned fields (headline, date, summary, link), plus the upstream source domain — details not present in 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?

One compact sentence plus a short example; the source and result shape are front-loaded and nothing is wasted.

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 correctly supplies the return shape and result limit, which is what an agent needs. The only gap is the absence of any hint about what happens when the keyword matches nothing — a minor omission for a simple one-optional-param read 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% and the single optional 'query' param is already documented with examples in the schema. The description restates the optional-keyword semantics and repeats an example ('Schiphol'), adding little beyond the structured field, so 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 resource and source: newest Amsterdam news from essentiallyamsterdam.com, with optional keyword filtering. It is clearly distinguishable from sibling tools like whats_on or conferences by the news framing, though it never names an alternative explicitly.

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?

Use is implied by 'newest Amsterdam news... optionally by keyword' and reinforced with a worked example (query='Schiphol'), but there is no explicit when-to-use/when-not guidance or comparison against the sibling event/search tools.

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, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds that defaults mirror the calculator page rather than zero/null and enumerates the returned fields, which is useful since there is no output schema; however, it gives no detail on units, rounding, or how sector thresholds are applied.

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 what the tool computes before the defaults caveat and the example. The phrase 'as on our rent points calculator' is slightly redundant with the title, but nothing else is wasted.

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 20-parameter, all-optional calculator with a fully documented schema and no output schema, the description covers the two things the schema cannot: default behavior on omission and the shape of the returned result. Missing only minor operational detail such as the currency/period of the maximum rent.

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 per-parameter definitions are already carried by the schema and a baseline of 3 applies. The description goes beyond that by clarifying that all 20 parameters are optional and that omission means page-example defaults, and it supplies a concrete nested-array example (rooms=[{area_m2:24},{area_m2:11}]) that illustrates the object shape.

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 the specific domain artifact (Dutch rent points / WWS for independent homes) and states what is produced: total, sector, maximum legal basic rent, and points per category. The verb is only implicit ('calculate'), but the resource and output are unambiguous, and no sibling tool in the list overlaps with this domain.

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 the agent that every input is optional and that omitted inputs fall back to the page-example defaults, which is real usage guidance for a 20-parameter tool with zero required params. It does not say when a caller should prefer this over other approaches or what preconditions exist (e.g., only for independent homes, not rooms), leaving scope only partially implied.

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 description's added value is in disclosure of result behavior: at most 10 items, ranked 'best first', and each carrying time, venue and link. It does not discuss empty-result behavior or how 'best' is computed, which keeps it from 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?

Two sentences: the first front-loads scope, result cap and ordering plus returned fields; the second is a compact usage example. No sentence is redundant or restates the title.

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 two-parameter, zero-required read tool with rich annotations and a fully documented schema, the description supplies everything an agent needs: time window, result count, ordering, and returned fields. No output schema exists, and the field list in the description compensates for that.

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%, including per-value enum explanations and the YYYY-MM-DD pattern, so the schema already carries parameter meaning. The description only reinforces this with the sample call date='2026-11-07', category='music', adding marginal semantics beyond the structured fields.

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 resource (events in Amsterdam) with the exact scope: one day, today through six days ahead, drawn from the What's On calendar. It also distinguishes itself from same-city siblings like markets_today and conferences by naming the calendar and the returned fields (time, venue, link).

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 usable window ('today to six days ahead') and the optional category filter give clear conditions for calling it, and the example shows the intended date format. It stops short of explicitly routing the agent away from overlapping siblings such as conferences or markets_today, so no true exclusion guidance is present.

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