ExactMelt

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the description's job is to add context, and it does: live website quotes are included, an optional buyer-offer comparison exists, and a prefilled PDF-report link is produced. It does not explain quote freshness, caching, or failure behavior, which would push it higher.

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 with the core purpose front-loaded and no filler. It is packed tightly enough that the input list and the feature list run together, but no sentence 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?

An output schema exists, so return values need not be described, and the annotations carry the safety profile. However, the most critical unknown — what string to pass as 'coin' (name, slug, catalog ID?) — is unaddressed in both schema and description, and spot/fees are undefined.

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 0% across 7 parameters, so the description must compensate. It covers coin, quantity/rolls (including the mutually-exclusive pairing implied by 'quantity or standard rolls'), and measuredGrams, plus hints at offer, but leaves spot and fees completely unexplained — a meaningful gap for a pricing tool.

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: computes melt value and fine-metal content from a native coin issue plus quantity/rolls/measured grams. The input basis ('native coin issue') implicitly separates it from the generic calculate_melt_value and calculate_penny_nickel siblings, but no sibling is named 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?

Usage is only implied by the listed inputs; there is no statement of when to pick this over calculate_melt_value, calculate_penny_nickel, or find_coins. Nothing warns about prerequisites (e.g., that the coin must be a recognized native issue) or what happens when the coin is unknown.

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 useful behavior beyond that – that quote-based pricing plus discount/premium/fees are folded into the result and that a prefilled PDF report link is produced – but says nothing about quote staleness, rounding, or how direction affects the calculation, which matters for a pricing 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?

Two compact sentences with the core computation front-loaded and the output artifact last. The 'Gold-to-silver or silver-to-gold' phrasing is slightly redundant given the direction enum, 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?

An output schema exists, so the PDF link mention is a bonus rather than a necessity. However, for an 8-parameter financial calculation with zero schema documentation, the description fails to resolve the critical ambiguity of what direction='gold' vs 'silver' means and when the optional gold/silver fields should be provided.

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 0% across 8 parameters, so the description must carry the load, yet it only names discount, premium and fees without explaining their units or effect. The two enums – direction ('gold'/'silver') and unit ('g','dwt','ozt', etc.) – and the optional gold/silver numeric inputs are left entirely unexplained, leaving the agent guessing what values to supply.

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 computation (gold↔silver exchange weight) and names the inputs it accounts for (quotes, discount, premium, fees). It is distinguishable from calculate_melt_value and calculate_coin_value by resource, though it never explicitly contrasts itself with them.

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

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

There is no statement of when to pick this over calculate_melt_value or calculate_coin_value, no prerequisites, and no note on data freshness despite 'current website quotes' implying live pricing. Usage must be inferred entirely from the title and the phrase 'at current website quotes'.

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, so the bar is lower, and the description still adds real behavioral context: it emits fine content and unit rates, a prefilled PDF-report link, and can incorporate what it calls 'current website quotes'. Note the mild tension: live website quotes sit oddly against openWorldHint=false, though this reads as bundled data rather than a true contradiction.

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 tight sentences, front-loaded with the computation and followed by the extras (quotes, PDF link, custom spot, mixed lots). No filler, though 'unit rates' and 'Includes current website quotes' are slightly ambiguous as written.

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?

An output schema exists, so return values needn't be described, and the description does signal breadth (single items, mixed lots, offer comparison, PDF report). For a 12-parameter tool with a oneOf lot structure and near-zero schema documentation, however, it leaves too much inference for correct invocation of the karat/fineness, gold-filled, and dental paths.

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 only 8% (just assayBasis and measuredGrams), so the description must carry parameter meaning, and it largely does not. It names metal/purity/weight/construction, custom spot, and mixed lots, but leaves the consequential semantics unexplained: when to use basis=karat vs fineness, how purity is interpreted under each, what layerDenominator does for gold-filled items, how fees/offer are applied, and which unit values are accepted.

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 opening clause names a specific verb+resource (melt value, fine content, unit rates, buyer-offer comparison) and the inputs that drive it (metal, purity, weight, construction). It is clearly distinct from calculate_exchange or find_coins, but it never names the closest sibling calculate_coin_value, and the schema's coin-lot variant blurs that boundary further.

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: mention of an 'optional buyer-offer comparison' and 'custom spot prices' hints at when to supply those inputs, but there is no explicit when-to-use statement, no prerequisites, and no routing guidance versus calculate_coin_value or calculate_penny_nickel.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the description adds real value by disclosing that prices are caller-supplied rather than fetched, and that results include constituent weights, face value, and a prefilled PDF-report link. It still does not describe units handling for measuredGrams versus count or validation failures.

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 dense sentence that front-loads the action and resource, then the input modes, then the pricing convention, then the outputs. No filler, though the packing makes the output clause feel tacked on.

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 seven parameters, a conditional oneOf schema, and zero schema description coverage, the definition leaves the most error-prone part — which parameters are legal for 'penny' versus 'nickel' — entirely undocumented. The existing output schema means return values need not be explained, but the input contract is still incomplete.

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 0%, so the description must carry the burden, and it only glosses 'count or measured total grams' and 'base-metal prices in USD per ordinary pound'. It never explains the critical oneOf branch: pennies require alloy+zinc and forbid nickel, nickels require nickel and forbid alloy/zinc, nor what the alloy enum values brass/zinc mean.

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 (metal value of penny/nickel alloy coins) and pins the input modes (count or measured grams) plus the pricing basis (manual base-metal prices in USD/lb). An agent can distinguish it from calculate_melt_value or calculate_coin_value by the coin-specific scope, though no sibling is named.

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 by the phrase 'from count or measured total grams', which suggests the two input modes, and by 'explicit manual base-metal prices', which hints this is not a live-price lookup. Nothing states when to prefer this over calculate_melt_value or calculate_coin_value, and there are no conditions or 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 establish readOnly, idempotent, non-destructive, closed-world semantics, so the safety profile is covered. The description adds that melt value is current (implying live/refreshed data) and enumerates the per-coin payload, but says nothing about result ordering, page limits, or how the cursor behaves.

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 with no filler, and the payload is front-loaded before the filter clause. It is efficient, though the brevity is partly achieved by omitting parameters that matter.

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?

An output schema covers the return shape, which lowers the burden, but this is a paginated search tool whose cursor/pageSize mechanics are undocumented and whose relationship to get_coin is unstated. For a 4-parameter finder with a sibling that overlaps, the description leaves real gaps.

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 0%, so the description must carry the load, yet it only alludes to two of the four parameters (query via 'name', metal via 'metal'). cursor and pageSize are never explained, leaving the agent to infer pagination behavior from bare min/max bounds.

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 (precious-metal coin presets) and its payload (issue years, images, metal specs, melt value), plus the filter dimension (name or metal), so the agent knows what set it returns. It stops short of naming the verb form and never distinguishes itself from the sibling get_coin, which likely retrieves a single coin.

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 at all: no statement that this is the browse/search path versus get_coin for a single record, and no mention of when to filter by metal versus query. The 'filtered by name or metal' clause implies a search mode but offers no selection criteria or 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the response embeds a melt calculation priced at the 'current website quote', so the agent knows the returned value is quote-dependent and time-sensitive rather than static. It stops short of covering not-found/error behavior.

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 with no wasted words, but it is not front-loaded with an action verb, so the reader parses it as an entity definition before realizing it is a retrieval tool. Conciseness is fine; structure could be improved by leading with 'Retrieve a coin by ID...'.

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 annotations covering safety and an output schema covering the return shape, the description need not explain returned fields — though it partially does. The critical gap is the undocumented required `id` input and any failure mode, leaving an agent unable to confidently construct a call from the description alone.

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 schema has 0% description coverage on the single required `id` parameter, so the description carries the full burden and fails: it never mentions an identifier, what form it takes, or where to obtain it. It only weakly implies a single specific coin is returned.

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 is a noun phrase describing the resource ('A native precious-metal coin preset with issue years, image, specifications...') rather than a verb stating the operation, so the agent must infer that this retrieves a single coin. It does convey the resource scope (one coin, not a list), but it never distinguishes itself from siblings like find_coins or calculate_coin_value.

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 statement of when to use this tool versus find_coins (which presumably locates coins) or the calculate_* siblings. The mention of 'a quantity-one melt calculation' hints that a separate melt call may be unnecessary, but this is inference rather than guidance, and no prerequisites or exclusions are given.

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