Liffey Metals

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

Annotations already declare this a safe, idempotent, closed-world read, so the bar is lower; the description still adds real value by disclosing the returned fields (rate per gram, total, spot quote time) and the crucial caveat that the figure is non-binding until weighing and XRF testing. It does not mention rate refresh cadence or quote staleness beyond 'today's published rate'.

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 dense sentences, front-loaded with purpose, then input format, then return shape and caveat. No filler; each sentence carries information the agent cannot get elsewhere.

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 present, the description carries the return-value burden and discharges it by naming the rate per gram, total and spot quote time. Combined with full parameter coverage and the estimate-vs-final caveat, an agent has everything needed to call and interpret this 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 baseline is 3, but the description genuinely extends the schema: it enumerates purity forms across carats (9–24), hallmark numbers (375, 585, 750, 916, 999, 925, 958, 800) and words (sterling, fine, bullion) well beyond the schema's few examples, and clarifies that weight_grams is the item as placed on the scale.

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 ('what we would pay for a given weight of gold, silver or platinum') and scopes it to today's published rate, so the agent knows it produces a live quote rather than a stored price. It does not, however, distinguish itself from siblings like get_buy_price or get_sell_price, leaving the boundary 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 rather than stated: the tool estimates a payout for a weight the customer already has, and the closing note that 'the final figure follows weighing and XRF testing' signals this is a pre-transaction estimate. No explicit when-to-use, when-not-to-use, or named alternative (get_buy_price) is provided.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful data-quality context: WhatsApp is preferred, reply time is included, trust signals come with where to verify them, and the Google rating may be null until reviews exist and must never be fabricated. It does not discuss freshness or caching, but adds meaningful behavioral detail beyond 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 a single dense sentence whose clauses all map to returned content, so it earns its length. However, it is a run-on list rather than a front-loaded 'Returns...' statement, making it slightly harder to scan.

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 carry the return-value burden, and it thoroughly lists the business details plus the null/fabrication caveat for the Google rating. For a zero-parameter read-only business-info tool, this is complete enough to call 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?

The tool has zero parameters and 100% schema description coverage, so the baseline is 4. The description does not need to explain parameter semantics because there are no 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?

The description enumerates the exact business facts the tool returns: founder, contact details, enquiry hours, location, service area, services, trust signals, citation pages, and Google rating. This makes the resource clear, but it never states the operation in a verb phrase or explicitly differentiates itself from siblings such as get_faq and list_services, despite overlapping on 'services'.

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?

There is no guidance on when to use this tool versus alternatives like get_faq, get_guides, or list_services. The intended usage is only implied by the content list, with no exclusions or routing conditions.

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), so the bar is lower. The description usefully adds that the response includes spotAsOf, the basis and deductions in plain English, and that county unlocks a postal arrangement page — genuine return-shape context — but says nothing about freshness, caching, or failure modes for an unlisted carat.

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 with the core definition front-loaded and no filler; the county and carat instructions follow in a logical order. Slightly packed ('one metal and carat or fineness') but nothing 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 compensates by naming the returned figures (spotAsOf, basis, deductions) and the county-dependent extra content. Coverage of all three inputs plus the return shape makes it sufficient for correct invocation, though pricing freshness and error behavior remain unaddressed.

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 all three parameters, including the 'omit for every grade' rule and the county slug examples. The description restates those same points without adding new syntax, formats, or defaults, 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 verb and resource: the net price Liffey Metals pays today in euro per gram, scoped to 'one metal and carat or fineness'. The singular scope implicitly separates it from the plural sibling get_buy_prices, but the description never names that sibling, 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?

Offers parameter-level guidance ('give the seller's county to add that county's postal arrangement and page'; 'omit carat for every grade'), which implies how to use it, but gives no when-to-use-this-vs-alternatives routing despite siblings get_buy_prices, get_sell_price and estimate_payout being obvious candidates.

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 and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the figures are 'today's' net prices, they include the spot quote time (freshness semantics), and no fees are deducted (so the agent knows these are gross-of-fee figures).

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?

Purpose, unit, freshness and fee treatment are front-loaded in the first clause, and the one long enumeration of the twelve categories is admittedly bulky but justified: with no output schema it tells the agent the exact coverage of the response.

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 carry the return-value burden, and it does: euro per gram per named item plus the spot quote time. The main omission is any statement of how this differs from the singular get_buy_price sibling.

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 per the rubric the baseline is 4. The description confirms there is no filtering dimension (all categories returned together), which is consistent with the empty 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 states a specific verb and resource (net buy prices Liffey Metals pays today, in euro per gram) and enumerates the exact material coverage, so an agent knows precisely what data comes back. It does not, however, distinguish itself from the near-identically named sibling get_buy_price, leaving the singular/plural split unexplained.

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?

There is no when-to-use guidance and no routing versus get_buy_price or get_sell_price, which are the obvious alternatives in this toolset. The reference to https://liffeymetals.com/prices identifies the data source but not the conditions under which this tool beats its siblings.

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, closed-world, so safety is covered. The description adds that answers are 'short' and 'factual' and describes the filter matching behavior, which is useful context, but omits return shape, pagination, and how many FAQs exist.

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-loaded with what the tool returns. The long topic enumeration is dense but earns its place by telling the agent what's covered; could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should sketch the return format, but it only says 'short, factual answers'. For a 1-param read-only tool this is close to adequate, but the absence of return-shape language leaves a gap.

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 'topic' param is already documented with examples in the schema. The description restates the filter behavior ('optional topic filter matches words in the question') but adds marginal value beyond the schema's own 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?

States a specific resource (short factual FAQ answers) with scoped subject matter (selling gold, silver or jewellery in Ireland) and enumerates topics covered. Distinguishes it from how_to_sell and get_guides by scope, though it doesn't explicitly name a sibling to contrast against.

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?

Context is implied by the description ('answers to the questions people ask before selling'), which signals pre-sale informational use. But no explicit when-to-use vs get_guides/how_selling_works, and no exclusions or alternatives named.

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-open-world, non-destructive, so safety behavior is covered. The description adds genuinely new context beyond annotations: the shape of each returned item (what the guide answers plus its URL). It does not mention result counts, ordering, or what an empty topic-filter match returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loads the resource definition and return shape, then adds the filtering note. The long topic enumeration is dense but earns its place by telling the agent what questions this corpus can answer; a slightly tighter grouping of topics would be cleaner.

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 no-argument, read-only retrieval tool with full annotation coverage, the definition supplies the corpus scope, the returned fields, and the optional filter. With no output schema, it carries the return-value burden itself and does so adequately, though it omits ordering/pagination behavior.

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 lone optional 'topic' param is fully documented in the schema, including examples and constraints. The description only restates that the words are optional and filter the list (and repeats example values already in the schema), 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?

States a specific resource (published guides and fact sheets) and enumerates the exact topic coverage (selling gold, XRF testing, hallmarks, tax, refining, etc.), which lets an agent infer this is the long-form reference content rather than pricing or FAQ. It never names a sibling tool explicitly, so it lacks the direct differentiation that would earn 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?

'Optional topic words filter the list' implies how to narrow results, and the topic enumeration hints at when this tool is relevant (background/reference questions). However, there is no explicit statement of when to choose this over get_faq or how_selling_works, nor any exclusions.

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 read-only, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds meaningful domain context beyond annotations, including conditional outcomes (free insured pack in the Republic vs. own tracked post to Dublin from Northern Ireland) and details like return postage deduction waivers.

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 front-loads the core purpose ('How the free insured postal pack works') and then enumerates covered topics efficiently. The first sentence is dense with a long list, but every item appears relevant and the second sentence cleanly covers the optional county parameter.

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 information tool with no output schema, the description sufficiently explains what content the tool returns: request process, transit coverage, free-return terms, offer validity, deduction rules, and county-specific variations. It could be slightly more explicit about the default response when no county is given, but overall the agent has enough to invoke it 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 coverage is 100%, so the baseline is 3, but the description adds real meaning about the county parameter: it yields that county's specific arrangement and illustrates the variation between Republic and Northern Ireland. That goes beyond the schema's neutral 'adds that county's postal arrangement and page.'

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 identifies the tool as returning explanatory information about the free insured postal pack, listing specific covered topics (transit coverage, return terms, validity, deductions, payment/ID). It distinguishes the resource well but does not explicitly contrast itself with the action-oriented sibling request_postal_pack.

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: an agent can infer to call this when users ask how the postal pack works or about a county's arrangement. The description gives guidance on when to supply the county parameter but never states when not to use this tool or names request_postal_pack as the alternative for actually requesting a pack.

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 read-only, idempotent, non-destructive behavior. Beyond that, the description adds genuine behavioral context an agent would otherwise lack: prices are VAT inclusive, denominated in euro per gram or per piece, include a spot quote time for spot-linked products, and indicate stock status. Only missing is any note on caching/refresh cadence for the 'today' pricing.

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 dense sentences that front-load the value proposition and then the calling convention, with no filler. The first sentence is long and carries several read-only facts at once, but every clause 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 carries the burden of describing returns and does so: currency, per-gram vs per-piece units, VAT inclusion, spot quote time, and in-stock status. Combined with the parameter guidance and the website parity note, an agent has everything needed to call and interpret the result.

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 parameter is fully documented with examples in the schema itself, so the baseline is 3. The description restates the same slug-or-name and omit-for-all semantics, adding no new syntax or format detail 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 gives a specific verb-and-resource statement: what Liffey Metals 'charges today' for casting grain, coins and bars, with currency and unit of measure. It implicitly separates itself from get_buy_price by framing the figures as what the vendor charges rather than pays, but it never names that sibling, so an agent must infer the distinction.

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 clearly explains the filtering dimension ('give a product slug ... for one product; omit for every product'), which tells the agent how to call it in both the filtered and unfiltered modes. However, it gives no guidance on when to choose this over the closely named sibling get_buy_price or get_buy_prices, leaving the most error-prone routing decision 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 this a safe, read-only, idempotent, non-open-world content lookup, so the burden is light. The description adds real value by disclosing exactly what the guide covers (insured pack request, XRF testing on camera, itemised offer, bank transfer, free returns, ID requirements, return postage rule), letting the agent predict the answer scope.

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 sentence, front-loaded with the core purpose, then a compact colon-delimited coverage list. Every clause earns its place, though the enumeration is dense and could be trimmed slightly.

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 params and no output schema, so the description only needs to convey what knowledge it returns, which it does thoroughly. The remaining gap is sibling differentiation against how_to_sell, which is a routing concern rather than a completeness one.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The listed topic headings serve as implicit content selectors even though no input exists.

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 topic with a clear verb-ish framing ('The postal selling process step by step') and enumerates the covered subject matter. It is clear what the tool returns, but it never distinguishes itself from the very similar sibling how_to_sell, so the agent must guess between the two.

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 that needs to explain the postal selling journey would pick it, but there is no explicit when-to-use statement, no exclusion, and no routing to how_to_sell, get_guides, or get_faq which overlap in 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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive behaviour, so the safety profile is covered. What the description adds is a content-shape disclosure — it tells the agent the response is a step-by-step walkthrough whose steps describe 'what to do and what to look for', followed by postal-process and guide sections. With no output schema present, that is genuinely useful behavioural context.

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 what the tool delivers and then the internal ordering of the content. Nothing is wasted, though the closing phrase 'the guide to read' is slightly vague about what that section actually is.

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, read-only content-retrieval tool with no output schema, the description gives the agent enough: what the document is, how it is organised, and which metals it supports. It lacks only guidance on when to prefer this over the sibling guide endpoints.

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 single enum parameter is fully documented in the schema (100% coverage, with the 'Lowercase' formatting note). The description repeats the gold/silver/platinum values but adds no new semantics such as what differs between metals or whether the guide varies by choice. Baseline 3 is correct when the schema carries the parameter.

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 resource (the seller's checklist/steps for gold, silver or platinum) and enumerates its contents — weigh, photograph, quote, confirm, send. That is far more specific than a tautology. It stops short of distinguishing itself from close siblings like how_selling_works and get_guides, which an agent would plausibly confuse it with.

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?

There is no explicit when-to-use statement and no routing away from alternatives, even though the sibling list contains obvious overlaps (how_selling_works, get_guides, get_postal_pack_info, estimate_payout). The only implicit signal is 'the guide to read', which is not a selection criterion.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully declared. The description adds real domain constraints beyond that (uniform pricing, GB exclusion, per-region postal models), which is useful, but it says nothing about pagination, return volume, or result ordering.

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 whole description is a single sprawling run-on sentence stuffed with parenthetical postal-policy detail. The core fact (list of counties and EU states with URLs) is buried mid-sentence rather than front-loaded, making it hard for an agent to parse quickly.

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 carries the job of explaining return values, and it does enumerate the returned fields and their meaning. Usage routing is the main omission, but the listing content itself is adequately described.

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 'country' enum is fully documented in the schema. The description's '(IE or NI)' refers to returned data rather than the filter, so it adds no meaning beyond the schema; 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 does state a concrete resource and enumerates the returned fields (country, province, postal model, arrangement, page URL) plus EU member states, so an agent can tell what this lists. It never names a sibling or draws an explicit boundary, but the scope ('counties' and 'EU states we buy from') is specific enough to separate it from pricing/FAQ 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?

There is no when-to-use statement and no alternative named among the 12 sibling tools. The only guidance is a negative constraint ('Great Britain is not served'), which tells the agent about coverage but not when this tool is the right call versus get_postal_pack_info or get_faq.

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 non-open-world, so the safety profile is covered. The description adds real behavioral content beyond that: each entry carries a one-line factual description and its URL, and it discloses a coverage caveat — 'Unlisted services are live pages that are not in the navigation' — which tells the agent the list may not be exhaustive.

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 scope statement and then the return shape. The long enumeration of service categories is informative rather than filler, though it makes the first sentence dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the burden of describing the return value and does so adequately (one-line description plus URL per service). Combined with the caveat about unlisted pages and the zero-parameter schema, an agent has enough to call and interpret it.

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 nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument, whole-catalog call.

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 ('Every service Liffey Metals offers') and enumerates the domain content (buying metals, selling by post, refining, XRF testing, valuations, etc.), which separates it from price/guide siblings like get_buy_price or get_guides. It is clear what the tool returns, though it never explicitly names a sibling it differs from.

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 discovery/catalog call for service pages, but there is no explicit 'use this when' or 'use X instead' guidance. With 12 siblings covering prices, guides, FAQs and postal packs, an explicit routing sentence would have been valuable.

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 only tell the agent this is a non-read-only, non-destructive, non-idempotent write, with no open-world access. The description adds substantial value on top: it warns 'This is the real order: the request is created when you call it', describes the receipt email and single-use cancel link, the conditional routing outcome, and that 'Errors name the field to fix.' No rate limits or failure modes are covered, so it stops 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?

The opening sentence front-loads purpose and return value, and the crucial 'this is the real order' warning follows immediately. It is long (~250 words) and the 'Before calling' checklist partly restates required fields already documented in the schema, but for a 16-parameter write tool with legal/consent implications the density is largely earned.

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 16 parameters and no output schema, the description does what structured fields cannot: it sequences the call after get_postal_pack_info, enumerates prerequisites, explains the routing decision and its WhatsApp/in-person alternatives, covers consent and the terms statement, and notes the error contract. Nothing an agent needs to invoke this 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 the baseline is 3, but the description supplies cross-parameter routing logic the schema does not fully spell out: gold within postal limits is posted directly, while silver/mixed/bullion/over-2,000-euro lots go to WhatsApp, and under 300 euro produces no pack. It also instructs the agent to read the accepts_terms statement to the person, adding procedural meaning to that field.

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 ('Orders a free insured postal pack for a person at a Republic of Ireland address') and the concrete return value (the Bosca number). It is immediately distinguishable from the sibling get_postal_pack_info, which the description explicitly frames as the explanation-only step to run beforehand.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit prerequisite checklist (name, address with Eircode, email, phone, metal type, description, value, consent) and names the sibling to call first ('Explain the process first (get_postal_pack_info)'). It also routes the agent to alternatives: WhatsApp for silver/mixed/bullion/over-2,000-euro lots, in-person Dublin appointment for lots over 1,000 euro, and states when no pack is issued at all (under 300 euro).

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