Irish rent benchmarks and house price comps

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the free tier, an explicit rate limit (20 calls/day per client), the upstream data source, the fact that legal rules are summarized as 'information, not legal advice', and the aggregate granularity of the result. It omits any authentication or failure/empty-result behavior, which keeps it short of 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?

It is a compact block of roughly 60 words that front-loads the user-facing question and then immediately gives scope, source, limits, and disclaimer. No sentence is filler, and the practical constraints (free, rate-limited) appear before the caveat.

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 and one simple parameter, the description does the work of describing what comes back (average asking rent plus a rent-control rules summary), the data vintage, and the cost/limits. It is close to complete; only result-shaping details such as units or update lag are 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?

There is a single parameter with 100% schema description coverage, so the schema already carries the syntax and the 'Dublin 4' / 'Ardee' examples. Baseline 3 is appropriate; the description adds only the scope note that results are county-level aggregates regardless of how specific the area input is.

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+resource: it returns the latest average asking rent for an Irish county plus a summary of Irish rent-control rules, and it names the data source (CSO/RTB RIQ02). It hints at paid siblings via the 'Free:' framing but never names them, so sibling differentiation is implicit rather than explicit.

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 implied rather than stated: 'Free:' and the '(all bedrooms, all property types)' scope suggest this is the low-cost county-aggregate option and that bedroom-specific queries belong elsewhere. No sibling tool is named and no explicit when-not condition is given, so the agent must infer the routing.

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 no annotations, the description carries the full behavioral burden. It usefully discloses that the call is 'Free' — meaningful context given siblings named paid_comps and paid_rent_check — and that it enumerates all queryable areas. However, it says nothing about read-only nature, auth requirements, or rate limits, which is a real gap for a zero-annotation 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?

Three short sentences, front-loaded with the purpose question followed by what is returned and the cost. No wasted text, though the rhetorical-question opener is slightly less direct than a plain declarative would be.

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 list tool with no output schema, the description covers what is returned (counties, towns, Dublin postal districts) and that it is free. It is close to complete, with only the return shape/ordering left unstated, which is minor for an enumeration endpoint.

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 tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The description correctly does not invent or imply any inputs.

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 (lists) and resource (Irish areas: every county, town, and Dublin postal district) with the scope of the listing made explicit. The framing as the set of areas 'you can query' implicitly separates it from the rent-lookup siblings, so an agent can tell it is the discovery/index tool rather than a data-retrieval tool.

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?

'Which Irish areas have rent data?' and 'you can query' imply this should be called before a rent lookup to resolve valid area names, but no sibling is named and no explicit when/when-not condition is given. Usage is inferable rather than stated.

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 no annotations, the description carries the full burden and does so unusually well: it discloses pricing ($0.05 USDC), the exact payment protocols (x402 on Base, MPP on Tempo), that the server holds no wallet and never pays, that it returns HTTP 402 requirements plus the target URL, and that the caller must retry after paying.

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 first sentence front-loads the purpose and the rest is dense but every clause carries needed information (source, metrics, payment flow, URL). Slightly crammed into one long sentence, but no 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 paid tool with no annotations and no output schema, the description covers what is returned, the source, the payment mechanics, and the retry workflow. An agent has everything needed to attempt the call and handle the 402 response.

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 county, segment, and quarters are already documented in the schema. The description reinforces segment semantics (new vs second-hand) and the trailing-12-month framing of quarters, but adds no syntax or defaults 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 verb+resource (Irish residential sale-price comps by county) and enumerates exactly what is returned: median/p25/p75 per quarter and trailing 12 months, new vs second-hand, sourced from the PSRA Property Price Register. This is clearly distinguishable from the rent-oriented siblings (county_rent, paid_rent_check).

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 clear context for when and how to use it (paid endpoint, pay with your own x402/MPP client and retry the URL) and an exclusion ('Not a valuation'). It does not explicitly contrast with county_rent/paid_rent_check, so the routing between siblings is only 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?

With no annotations, the description carries the full burden and does it well: it discloses the price ($0.03 USDC), that the call returns HTTP 402 payment requirements, the two payment protocols (x402 on Base, MPP on Tempo), that the server holds no wallet and never pays, and the exact URL to retry. This is unusually complete behavioral disclosure for a paid 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?

It is front-loaded with the core question and packs a lot of value, but the closing payment sentence is wordy and partially restates the URL that appeared earlier. Dense but mostly earning 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?

No output schema and no annotations, yet the description covers the returned values (index, 4/12-quarter changes, rank), the data source (Eurostat prc_hpi_q, CC BY 4.0), the payment flow, and a disclaimer. Nothing an agent needs to call 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 coverage is 100%, so both parameters are already documented (metric enum-ish values and the ISO 3166-1 alpha-2 country code). The description hints at which metrics exist via the output description but adds no syntax or format guidance 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 resource (latest quarterly house price index at 2015=100, plus 4- and 12-quarter % change and EU rank) and a specific scope (an EU country). The domain is clearly distinct from the rent/comps siblings, so an agent can separate it 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?

It explains the mechanics of use (this is a paid tool; pay with your own x402/MPP client and retry the URL), which is genuinely useful context. But it never states when to prefer this over alternatives or what the prerequisite state must be before calling; usage is implied rather than guided.

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 no annotations present, the description carries the full burden and does so well: it discloses the paid cost ($0.01 USDC), that the server holds no wallet and never pays, that it returns HTTP 402 requirements (x402 on Base, MPP on Tempo), and the exact URL to retry. This is exactly the auth/payment behavior an agent needs before invoking.

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-loaded with the core question and result contents before the payment mechanics. It is somewhat dense with parenthetical detail (x402 on Base, MPP on Tempo), but every sentence carries operational information.

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, and the description compensates by enumerating the components of the paid result plus the 402/retry flow. It does not describe the response's shape or units, but for an agent's selection and invocation decision 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 100%, so the baseline is 3, but the description adds meaning by tying the computation to LTI/LTV Central Bank checks and Help to Buy eligibility, which signals how income, deposit, mortgage and buyer_type are actually used. It still adds no format or unit guidance 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?

Opens with a concrete question and enumerates exactly what the paid result contains (stamp duty, Help to Buy estimate, LPT, legal/registration fees, LTI/LTV checks). This distinguishes it cleanly from siblings like paid_comps, paid_rent_check and paid_eu_house_prices, which cover different resources.

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 context of use is unambiguous ('cost to buy a home in Ireland') and the payment prerequisite is spelled out, including how to pay and retry. It never names a sibling alternative or states when-not to use it, so it falls short of a 5.

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 no annotations, the description carries the full burden and does well: it discloses the $0.02 cost, that the server holds no wallet and never pays, the HTTP 402 response shape, and the two payment protocols (x402 on Base, MPP on Tempo). It stops short of describing what the paid data payload contains beyond the trend/field hints.

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 rhetorical opening question is mildly wasteful but quickly grounds the use case, and the payment mechanics follow in tight sentences. The critical constraint (no wallet, returns 402) is front-loaded before the URL, so the structure works.

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 and no annotations, the description does the heavy lifting on the payment contract, which is the hard part of invoking this tool. It is only slightly incomplete in not sketching the rent data returned after payment.

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 area, beds, and type with examples and value lists. The description restates the same concepts (town/postal district, bedroom/type filters) without adding syntax or format 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?

The description states a specific resource (average rent for a town or Dublin postal district) with filters (bedroom/type) and trends (4- and 12-quarter), so the verb+resource are clear. It does not differentiate itself from the siblings county_rent or paid_comps, leaving the agent to infer the boundary, which holds it 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?

It gives a clear usage sequence for the payment flow (get 402 requirements, pay with your own x402/MPP client, retry the URL), which is real guidance. However, it never says when to prefer this paid tool over the free-looking siblings county_rent or list_areas, so selection guidance is only 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?

With no annotations, the description carries the full burden and does so unusually well: it discloses the $0.03 USDC cost, that the server holds no wallet and never pays, that it returns HTTP 402 payment requirements (x402 on Base, MPP on Tempo), and the exact retry URL. It adds stale flags as a data caveat. It omits pagination/response-shape details, keeping it just under 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 sentences: a hook question, the data description, and the payment mechanics — each earns its place with no filler. The payment sentence is dense but necessary given the no-annotations, paid-invocation context. Front-loading is adequate, though the hook question precedes the concrete deliverable.

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 paid tool with no output schema and no annotations, the description covers what data is returned, its source, the paid nature, the payment protocols, and the retry URL — enough to invoke it without guessing. Only finer return-format details (row structure, ordering guarantees implied by sort) are absent.

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 no enums are declared, so the schema already documents n, beds, sort, and type with defaults and value lists. The description adds no parameter-level meaning beyond that, which is the baseline 3 when the schema does the heavy lifting.

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 question framing and states the deliverable: a county ranking by latest average rent plus 4- and 12-quarter % change, with the data source (CSO/RTB RIQ02). This is a clear verb+resource. It does not, however, explicitly distinguish itself from siblings like county_rent or paid_rent_check, 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?

It conveys the key usage condition that this is a paid call and requires an external x402/MPP client, then explains the pay-and-retry workflow. However, it never says when to prefer this over county_rent or paid_rent_check, nor any when-not conditions, so usage selection versus alternatives is left 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?

No annotations are supplied, so the description carries the full burden, and it does disclose real operational traits: it is free, capped at 20 calls/day per client, informational only ('not legal advice'), and scoped to a single jurisdiction. It does not describe response shape or pagination, but for a free static-information tool that gap is minor.

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-loaded with the question it answers, then the payload, then the scope/limit caveats in roughly priority order. It is dense and slightly list-heavy, but every clause (rate bands, VAT note, source/date, rate cap, disclaimer) adds distinct value.

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 the return content, and it does enumerate the bands, VAT note, and source/date metadata. The main omission is return format (structured fields vs. prose), but the core informational contract is complete for a zero-param 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?

Zero parameters, so the baseline is 4; the empty object schema means there is nothing further to document. The description correctly implies a parameterless lookup rather than hinting at hidden inputs.

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 the specific resource (Irish residential stamp duty rates) and enumerates exactly what is returned: the rate bands, the VAT note for new builds, plus source and date. It also explicitly distinguishes itself from the sibling paid_purchase_cost, so an agent can route without opening a 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?

Names the condition that selects the alternative ('Does not calculate for a price; the paid purchase-cost tool ($0.01) does'), which is clear routing guidance. It does not spell out a positive 'use this when you need the statutory bands for a lookup' trigger, but the first sentence implies it well enough.

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