Bullion Trading: Gold & Silver

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 description is free to add the important caveat that results are an estimate only and the binding tax appears at checkout. It also discloses that a state page link is included in the response, which is real behavioral value beyond the 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?

Three short sentences with the core capability and the estimate-only caveat front-loaded, and no filler. The lead sentence is a noun phrase rather than a verb phrase, which softens the opening slightly but costs little.

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 a full output schema, complete annotation coverage, and documented parameters, the description only needs to frame the tool's purpose and its estimate caveat, which it does. It is somewhat thin on how the optional amount/form/metal affect the answer, but nothing essential to calling it 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 description coverage is 100%, including explanatory text for form, metal, state, and amount, so the schema carries the parameter burden. The description adds only a weak hint that amount drives the estimate; it does not clarify the form/metal interaction or whether those are required for an accurate answer.

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 resource (US state sales tax on bullion) and the three things returned: whether tax applies, the threshold, and an order estimate. It is clearly distinct from all product/price siblings, though it never explicitly names any of them as alternatives.

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 content ('estimate for an order amount'), so an agent can infer this is a pre-purchase tax check. There is no explicit statement of when to call it versus siblings, no note about what happens when amount is omitted, and no exclusion cases such as non-US addresses.

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 behavior, so the safety profile is fully covered. The description adds that results include both prices, stock status, and best price per ounce, but says nothing about result limits, pagination, or what happens when filters match nothing. It neither contradicts nor substantially enriches the 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?

Two dense sentences: the first front-loads what the tool returns, the second delivers the one non-obvious parameter format rule. The URL reference is the only near-redundant element, and it usefully anchors the semantics of the picker.

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 six optional parameters, full annotation coverage, and an output schema, the definition covers nearly everything an agent needs to invoke it. The remaining gap is 'state', the only parameter with no mention in the description, which matters because it triggers shipping-rule filtering.

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 83%, so baseline is 3, but the description earns an upgrade by giving concrete size syntax examples ('1-oz', '1-10-oz', '1-kilo', '1-gram') for a parameter whose only schema constraint is a bare regex pattern. It also groups the metal/form/size/purpose/sort facets coherently, with only 'state' left unexplained 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?

States a concrete verb+resource: filter products by metal, form, size, purpose, or sort order, and discloses what each result carries (both prices, stock status, best price per ounce). It is specific enough to distinguish the faceted 'picker' from a generic product lookup, though it never names search_products as the contrasting free-text alternative.

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 'Find your bullion picker' framing and the site reference, which signals a browse-by-facet flow rather than a keyword search. There are no explicit when-to-use/when-not statements and no guidance on choosing sort orders or on how this differs from search_products, list_best_sellers, or get_deals.

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 that this is a read-only, idempotent, non-destructive lookup, and the description adds useful behavioral context about what the response contains: tradition guidance, a guide page, and suggested products with prices. It does not contradict the 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, front-loaded sentence with no wasted wording. It efficiently conveys the domain and the key return components.

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 low-complexity, single-parameter lookup with a full schema and an output schema, the description is largely complete. It explains the intent and return content, though it could more explicitly route the agent relative to sibling product-search tools.

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 documents the optional occasion parameter, including slug examples and the behavior when omitted. The description reinforces the occasion examples but adds no syntax or additional 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?

The description clearly states the tool provides gold and silver gift ideas for traditions and occasions, including the tradition guidance, guide page, and suggested products with prices. This is specific enough to distinguish it from product-search and market-data siblings.

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 description implies use for occasion-based gift discovery and gives examples such as Pidyon HaBen and Dhanteras, but it does not explicitly say when to use this versus search_products or other product-list tools. The usage context is clear but alternatives are not addressed.

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 this as a read-only, idempotent, non-open-world lookup, so the safety profile is covered. The description adds genuinely non-obvious business behavior: the exact bid formula and discount tiers per metal, that prices are posted rather than locked, and that there is a $1,000 minimum sale threshold. It does not explain whether an item appearing in results is guaranteed available or how stale the posted rates are, which keeps it 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 leading clause answers the core question immediately, and the two trailing fragments (rates-not-quotes, $1,000 minimum) each carry a distinct constraint that changes how an agent should present the result. There is no filler and nothing repeated from the schema.

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

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

An output schema exists, so return values need not be described, and annotations cover the read-only profile. The main gap is invocation behavior: all three parameters are optional and the description never says what happens with no filters (likely a full catalog of buy-back rates) or how to narrow results when a broad search matches many items. For a pricing tool used in a customer-facing sales decision, that leaves a meaningful hole.

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%, with each of metal, search and product documented in the schema, so the description need not restate them. It adds no guidance on how the three optional filters combine or which one to prefer. Baseline 3 is appropriate when the schema carries the parameter burden.

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: the per-item buy-back rates Bullion Trading LLC pays when a customer sells bullion, including the exact discount model (spot bid minus 3%/5% for gold/platinum/palladium, minus $3/$5 per oz for silver). This clearly separates it from sibling tools like get_spot_prices and get_premiums, which deal in market prices rather than what the dealer pays. It is a noun phrase rather than a verb-led statement, but the purpose is unambiguous.

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 description implies the use case (a customer asking what they would receive for selling) and flags two important conditions: rates are posted and not locked quotes, and there is a $1,000 minimum per sale. However, it never explicitly says when to prefer this over get_spot_prices or get_premiums, nor does it say what to do when the caller has no specific item in mind. Usage is inferred rather than directed.

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 still adds meaningful behavior: the data is scoped to the current day's deals page, each entry explains the deal rationale, and stock status is included alongside prices — useful context an agent could not infer from annotations alone.

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, front-loaded sentences with no filler; the core scope comes first and the payload contents follow. The trailing fragment 'Both prices and in/out of stock.' is slightly clipped but still earns its place by telling the agent what fields to expect.

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 no explanation, and both parameters are fully documented in the schema. With annotations carrying the safety profile, the description only needs to convey the deals/freshness angle and payload scope, which it does.

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%, with both 'limit' and 'metal' documented in the schema itself, so the baseline of 3 applies. The description adds no filtering semantics — it never mentions that results can be narrowed by metal or capped by limit, though 'in its format' faintly hints at format-based reasoning not tied to either 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 exact resource (products on the Bullion Trading LLC deals page) and the value-add of the response (why each item is a deal, e.g. lowest premium in its format), so an agent can tell this apart from generic tools like search_products or get_premiums. It doesn't explicitly contrast itself with siblings such as list_best_sellers, which keeps it just 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?

The word 'today' signals that this is a live, freshness-bound view, which implicitly tells an agent to use it for current bargains rather than historical lookups. However, it never states when to prefer it over search_products, list_best_sellers, or get_premiums, and provides no exclusions or prerequisites.

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 behavior, so the safety profile is covered. The description adds the shape of the payload (mood, headline, key points, linked source headlines), but because an output schema exists this largely restates structured data rather than disclosing new behavior such as coverage windows or staleness.

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 resource and scope, with the default behavior stated inline. The trailing field list is somewhat enumerative but each item conveys what the agent will receive, so little 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 single-optional-parameter, read-only tool with full annotations and an output schema, the definition covers what it returns and how the date defaults. Only marginal context — such as historical coverage limits or whether non-trading days return empty — 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% and the single optional date parameter is fully documented with its YYYY-MM-DD pattern in the schema. The description's 'for a day (default the latest)' merely echoes the schema default, adding no format or boundary detail beyond it.

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 — the precious-metals market news summary for a given day — and enumerates its contents (market mood, headline, summary, key points, source links, weekly recap). An agent can immediately tell this is a news/context retrieval tool. It does not name or contrast with any sibling, though no sibling appears to overlap 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?

Usage is only implied: the tool is for getting market news, and 'default the latest' hints at the no-argument case. There is no explicit when-to-use or when-not-to-use guidance, and no mention of how it relates to price-oriented siblings like get_spot_prices or get_price_history.

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, and non-open-world behavior, so the bar is lower. The description adds the important default behavior that omitting both parameters turns this into a listing operation, plus a sketch of the response contents.

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 front-loads the resource, then the return contents, then the invocation modes. Very little waste, though the phrase 'a sample with both prices' is slightly cryptic about which two prices are meant.

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?

A simple two-optional-parameter read tool with full annotations and an output schema, so return values need no elaboration. The description covers lookup, search, and listing modes; only minor details like no-match behavior 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?

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the either/or relationship between 'mint' and 'search' and what an empty call means. The one gap is that it does not explain how slug matching differs from the free-text search beyond the wording.

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 (mint or refiner, with concrete examples like Royal Canadian Mint and PAMP) and enumerates what is returned: country, summary, product count, and a priced sample. It is clearly distinct from siblings such as get_product or search_products.

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?

Explicitly covers the three input modes: a slug, search words, or omitting both to list mints. It does not name a competing sibling tool for the 'browse all mints' case, but the when-to-use conditions are otherwise unambiguous.

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, so the safety profile is covered. The description adds useful framing that this is verbatim authoritative text ('the store's own wording') and that shipping applies to the US only, but says nothing about response shape or how topics are combined.

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

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

A single front-loaded sentence that identifies the resource, the source of truth, and the covered topics with zero filler. The parenthetical '(US only)' earns its place as a constraint.

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?

This is a simple read-only lookup with one optional enum parameter, full annotations, and an output schema, so the description need not explain returns or pagination. Nothing an agent needs in order to select and invoke 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% and the single enum parameter is fully documented, including the 'default all' behavior, so the description need not repeat it. The enumerated topics in the description loosely mirror the enum but add no new syntax or constraint information.

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 (store policies) and enumerates the exact subject areas covered: shipping, payments, returns, minimums, pickup, and selling. It distinguishes itself from price/product siblings by being clearly policy text, though it does not explicitly contrast with get_store_info, which is the nearest neighbor.

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 topic list — an agent can infer this is the tool for policy questions — but there is no explicit 'when to use this instead of get_store_info' guidance or statement of when not to call it. The default-all behavior is left to the schema.

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, destructiveHint false and closed-world scope, so the safety profile is covered. The description adds useful behavioral context by disclosing the three data components returned (typical/lowest premium today, 2-year median, lowest-premium product), but says nothing about data freshness, update cadence, or how unsupported formats are handled. With an output schema present, this is adequate but not rich.

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 sentence with the core value proposition front-loaded ('Today's typical and lowest premium over the Ask spot') and the return components trailing. The parenthetical format list is somewhat long but earns its place by concretizing 'standard coin and bar format'.

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 tool with annotations and an output schema, the description covers what is returned well. However, it never states the behavior when the optional metal parameter is omitted, which is the one decision an agent must make when invoking 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?

Schema description coverage is 100% and the single optional 'metal' parameter is fully documented in the schema with an enum. The description does not mention the metal filter at all, so it adds no meaning beyond the schema; 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 specific resource (premium over Ask spot) and enumerates exactly what is returned: today's typical and lowest premium per standard coin/bar format, the 2-year median, and the lowest-premium product. It is clear what the tool yields, though it does not explicitly contrast itself with siblings like get_spot_prices or get_product.

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 guidance on when to call this versus get_spot_prices, get_price_history, or get_product, and no mention of prerequisites or exclusions. Usage must be inferred from the subject matter alone.

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, so the description's job is to add context — and it does: data granularity (check/wire prices for products, daily closes for metals), a hard 5-year span cap, and a default 12-month window. It leaves the both/neither selector case and any rate limits 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 front-loaded sentences, with the two modes established before the parameter instructions; every clause carries information. The nested parentheticals make it slightly dense, but 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?

An output schema exists, so return values need no explanation, and the core modes, defaults, and limits are covered. However, with zero required parameters the description never states the outcome of an empty call or of supplying both product and metal, leaving a real ambiguity for invocation.

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 the schema lacks: the default date window (last 12 months), the 5-year maximum span, and the fact that from/to only apply to the metal branch. The product identifier formats are merely restated from 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?

Names a specific verb+resource (price history) and splits it into two concrete modes: per-product check/wire price history versus per-metal daily closes. An agent can distinguish it from get_spot_prices or get_product from the text alone, though 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?

The description explains how to select a mode ('Give product, or metal with optional from/to dates') and states the default window, which is genuine invocation guidance. It does not explicitly say when to prefer this over get_spot_prices (current prices) or get_premiums, nor what happens if neither or both selectors are supplied.

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 needs no restating. The description adds genuinely new behavioral context: the buyback figure is conditional ("if we do"), so the agent knows that field may be absent, and the field inventory signals the response is a rich single-record payload. It does not mention error behavior for an unresolvable identifier.

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 sentence, front-loaded with the core action and identifier forms before the field inventory. The trailing enumeration is dense and slightly run-on, but each item helps an agent decide whether this tool returns what it needs.

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 fully documented parameter, an output schema, and complete annotations, the definition covers what an agent needs to invoke it correctly. The only gap is routing guidance against the many product-related siblings.

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 already lists id, slug, and full-URL forms with an example, so the description's mention of the same three forms adds no meaning 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 names a specific verb and resource ("Full details for one product") and the three accepted identifier forms, so an agent can distinguish it from list/search siblings. It stops short of naming a sibling outright, so sibling differentiation is implied 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 is implied by "one product by id, slug or product URL", which narrows it to single-item lookups, but there is no explicit when-to-use statement nor guidance on when to prefer search_products, find_bullion, or get_buyback_price instead. Reference to a "price-history link" hints at get_price_history but does not route the agent there.

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 real domain context beyond that: the pricing units and currency, the source (Bullion Trading LLC), and the definitions of Ask (premiums measured over) and Bid (buy-back baseline), plus the change reference point of the previous 5 pm New York close.

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 single sentence that front-loads the resource, units, currency and metal list before the Ask/Bid detail. It is dense and somewhat clause-heavy but every clause carries information an agent would need.

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-required-parameter read tool with an output schema, the description supplies units, currency, covered metals and the meaning of the two price sides, which is enough to call it correctly. The only gap is that it never mentions the optional metals filter or its default 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 description coverage is 100% and the single optional 'metals' array is fully documented with its enum values and default in the schema. The description says nothing about the filter, so it adds no parameter meaning beyond what is already structured; 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 resource and scope: current spot prices per troy ounce in USD for gold, silver, platinum and palladium, including Ask/Bid and change since the prior 5 pm New York close. 'Current' plus the daily close reference implicitly separates it from get_price_history, but no sibling is named explicitly, so it stops short of a 5.

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

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

Usage is only implied: 'Current' signals this is a live-quote lookup rather than a historical one, and the mention of Ask/Bid hints at a relationship to get_premiums and get_buyback_price. There is no explicit when-to-use or when-not-to-use statement, and the alternatives in the sibling list are never referenced.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered structurally. The description adds one genuinely useful nuance not in the structured data — that opening hours are expressed in New York time — plus the static nature of the contact data. It says nothing about freshness of the data or any auth requirement, so it is additive but thin.

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 entity and scope, with no filler or repetition. It is a noun-phrase inventory rather than prose, which reads efficiently but is slightly list-like; a short leading clause such as 'Returns' would make the action explicit.

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 description need not explain return values — yet most of the description is exactly that inventory, partially duplicating structured data. For a zero-parameter read tool this is enough to call correctly, but it leaves the routing question (vs. get_policies, get_mint_info) unanswered.

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 meaning for the description to carry; the baseline for a parameterless tool applies. Nothing in the description misdescribes the call signature.

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 (Bullion Trading LLC store info) and enumerates its contents: address on West 47th Street, phone, emails, opening hours, founding year, licensing, map link. That is far more specific than a restatement of the name. It does not explicitly differentiate itself from siblings, but its scope is narrow enough that no other listed tool plausibly overlaps.

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 or when-not-to-use statement and no mention of alternatives such as get_policies for licensing/policy questions, which is a plausible confusion point given the 'licensing' item. Usage is only implied by the enumerated contents, so an agent can infer the tool answers contact/hours/location questions but gets no routing help.

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 fully covered. The description adds that prices and stock status accompany the results, which is useful context, but says nothing about how "best-selling" is ranked (time window, ordering) or the default result count.

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 resource and scope. The second sentence partially duplicates return-value information already carried by the output schema, but it costs little and reads cleanly.

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 simple two-parameter read tool with rich annotations and an output schema, the definition covers the essentials. The only meaningful gap is the undefined ranking window behind "best-selling," which affects how the agent should interpret and present results.

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 the limit bounds/default and the metal enum documented directly in the schema. The description only echoes the optional single-metal filter, adding no meaning beyond what the schema already provides, 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+resource ("best-selling products") and vendor scope (Bullion Trading LLC), plus an optional metal filter. It is distinguishable from siblings like list_new_arrivals and get_deals, though it never names them 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?

"Optionally for one metal" hints at the filtering behavior but gives no when-to-use context, no exclusions, and no routing to alternatives such as list_new_arrivals or search_products. An agent must infer the tool's place in the catalog.

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 safety profile is covered. The description adds that results carry prices and in/out-of-stock status, but says nothing about what 'new' means (recency window), ordering, or result volume beyond the limit cap.

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 with the catalog scope front-loaded and the filter and payload content following. The fragmentary second sentence is terse but not 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?

With an output schema present and annotations covering safety, the definition covers the essentials, but for a 'new arrivals' tool the undefined recency window and ordering leave a real gap an agent would want closed.

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 both limit and metal are fully documented in the schema, and the description only echoes the optional single-metal filter. Baseline 3 applies since 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?

States a specific resource and scope: products 'newly added' to the Bullion Trading LLC catalog. An agent can tell this lists new catalog items rather than search results or best sellers, though 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?

There is no when-to-use guidance and no routing away from alternatives such as list_best_sellers, search_products, or find_bullion. The only conditional phrasing, 'optionally for one metal,' describes an optional parameter rather than a usage decision.

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, closed-world, non-destructive behavior. The description goes beyond that by disclosing the payment-method rule (check/wire from $1,000, otherwise card/PayPal at +5%) and that totals exclude shipping and tax — real behavioral context an agent couldn't infer from 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?

Front-loads the outcome (what fits the budget), then the key constraints and goal options. A single dense paragraph with no filler, though the payment-method clause is packed tightly and slightly interrupts the flow of what is returned.

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 explained, and the description still usefully names the returned fields. Mutation risk is nil and annotations cover safety; the only minor gap is that the budget's min/max is left to 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?

Schema coverage is 67% and the enums are self-explanatory, so baseline is 3. The description adds meaning for the 'goal' enum (what each goal optimizes for) but doesn't clarify the $25–$5M budget bounds, which live only in 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 ('plan a budget') and enumerates exactly what it returns: product, piece count, assumed payment method, total, and premium over spot. This clearly distinguishes it from siblings like find_bullion (product search) or get_premiums (premium lookup).

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

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

Gives clear context for when to use it: allocating a fixed USD budget toward a metal, with goal options ('lowest premium, popular coins, or gift-friendly items'). It also scopes the result ('before shipping and tax'), which tells the agent to use estimate_sales_tax separately, though that routing is implied rather than 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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is free. The description adds real domain behavior: the ratio is spot-based, reflects 'current' prices, and excludes premiums and buy-back spreads, which prevents the agent from misusing the output as a dealer quote.

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

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

A single front-loaded sentence defines the ratio first, then the optional conversion, then the spot-only caveat. No filler, and the scoping constraint lands where it is most useful.

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 read tool with an output schema and full annotation coverage, the description covers purpose, direction semantics, and pricing basis. The only minor gap is not stating the data source or refresh timing of the ratio, which is unlikely to change how the agent calls 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?

Schema description coverage is 100%, so baseline would be 3, but the description adds directionality and, crucially, implies the two parameters are alternatives ('give gold_oz ... or silver_oz ...') — a mutual-exclusivity contract the schema does not enforce (both optional, no oneOf). That is meaningful 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?

The description states a specific verb-and-resource combination: it reports the current gold/silver ratio (ounces of silver per ounce of gold at spot) and optionally converts between the two metals. The parenthetical definition of the ratio and the explicit 'spot-to-spot only' scoping make it clearly distinct from siblings like get_spot_prices, get_premiums, and get_buyback_price.

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 exactly how to use the tool in each mode: pass gold_oz to get silver ounces, or silver_oz to get gold ounces, and it warns that premiums and buy-back spreads are not included, which implicitly steers quote-related questions elsewhere. It doesn't name an explicit alternative sibling by name, 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?

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the safety profile is free. The description earns credit for adding behavior the annotations cannot: results carry two price points (check/wire and card/PayPal with a +5% surcharge) plus in/out-of-stock status, which materially shapes how an agent presents results. It stops short of noting pagination caps or result ordering defaults.

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

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

Three sentences, front-loaded with the scope, then filters/sort, then return shape; no filler. The only minor redundancy is restating the sort and metal options that already appear as schema enums, which costs a few words without adding 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?

For a 9-parameter, zero-required search tool with an output schema, the definition covers scope, filter axes and return semantics well enough to call correctly. The gaps are the unmentioned keyword 'query' parameter and pagination limits/defaults, which an agent must discover from the schema 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?

With 78% schema description coverage, the schema already documents metal, type, query, price bounds and per_page, so a 3 is the baseline. The description confirms which price basis min_price/max_price refer to (check/wire, with card at +5%), adding modest value, but it omits the free-text 'query' parameter entirely — arguably the most important parameter for a search tool — and says nothing about page/per_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?

States a specific verb (Search) plus the exact resource and its scope: the Bullion Trading LLC catalog of gold, silver, platinum and palladium coins, bars and rounds. An agent immediately knows this is a filtered catalog lookup, though the description never names the sibling it is not (e.g. find_bullion or get_product), so differentiation 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?

The middle sentence enumerates the filter and sort axes ('Filter by metal, type, price range and stock; sort by price, popularity or newest'), which implies how to use the tool but never says when to prefer it over find_bullion, list_best_sellers, list_new_arrivals or get_product. No exclusions or prerequisites are given.

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