Live gold price per gram by karat and currency, metal prices, jewelry melt value, unit conversion.
Scored across 4 tools
The tools mostly have distinct purposes: valuation, unit conversion, gold price by karat, and multi-metal spot prices. The main overlap is between get_gold_price_per_gram and get_metal_prices, since both can return live gold spot prices, though the descriptions distinguish karat/currency depth from multi-metal coverage.
All tool names use consistent snake_case with a clear verb_noun structure: calculate_jewelry_value, convert_gold_units, get_gold_price_per_gram, and get_metal_prices. The convention is predictable and easy to scan.
Four tools is well-scoped for a gold pricing and valuation server. Each tool covers a distinct workflow: live pricing, multi-metal pricing, unit conversion, and jewelry melt valuation.
The surface covers the core domain well: current gold prices, other metal spot prices, unit conversions, and jewelry melt value. Minor gaps exist around historical prices or date-specific pricing, but the main workflows are covered.
Melt value of a gold item (ring, chain, bracelet, scrap) from its weight, unit and karat at the live spot price, in any currency. Optional dealer_spread_percent returns the likely buyer offer. The result states that melt value is not the retail or buyback price.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | Weight unit: gram, kilogram, troy_ounce, pennyweight, grain, avoirdupois_ounce, tola, baht, baht_jewelry, chi, tael, luong, tael_taiwan, tael_china. Aliases such as g, kg, oz, ozt, dwt and kilo work. "oz" means troy ounce. | gram |
| karat | Yes | Karat: 24, 22, 21, 18, 14, 10 or 9 (any whole number 1 to 24 works; purity = karat/24). | |
| weight | Yes | Weight of the item, for example 12.5. | |
| currency | No | ISO 4217 currency code, for example USD, EUR, GBP, INR, AED, SAR, PKR, CAD, AUD. Default USD. | USD |
| dealer_spread_percent | No | Percent a buyer keeps below melt, for example 20 for an offer at 80% of melt. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world; the description usefully adds that pricing is at the live spot price (dynamic, network-dependent results) and that the output carries a disclaimer about melt vs. retail/buyback. It stops short of covering failure modes such as unsupported currency codes or karat/unit mismatches.
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 with the core computation front-loaded and the disclaimer last. The opening sentence is densely packed with four input mentions, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only calculator with fully described parameters and no output schema, the description is sufficient: it names the computation, the optional branch (dealer spread), and even hints at result content (buyer offer, disclaimer). Only edge-case behavior on invalid currency/unit input is left 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 coverage is 100%, so unit aliases, karat range, currency format and spread math are all already documented in the schema. The description only adds that dealer_spread_percent yields a 'likely buyer offer' and that any currency is supported, which is a modest increment over the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific computation (melt value) from named inputs (weight, unit, karat) against the live spot price in any currency, which an agent can easily separate from price-lookup or unit-conversion tasks. It never names a sibling tool, so explicit differentiation is absent, keeping it at 4 rather than 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 context is clear: value a physical gold item (ring, chain, bracelet, scrap), optionally with a dealer spread to approximate a buyer offer. It also sets a scope boundary by noting the result clarifies melt value is not retail or buyback price, but it gives no explicit routing to get_gold_price_per_gram or convert_gold_units.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a gold weight between gram, kilogram, troy ounce, pennyweight, grain, avoirdupois ounce, tola, Thai baht (bullion and jewellery), Vietnamese chi and luong, Hong Kong gold tael, Taiwan tael and China liang. Uses exact defined constants (1 troy ounce = 31.1034768 g, 1 grain = 64.79891 mg, NIST Handbook 44) and returns the definition and source of each unit. Omit "to" to get every unit.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Weight unit: gram, kilogram, troy_ounce, pennyweight, grain, avoirdupois_ounce, tola, baht, baht_jewelry, chi, tael, luong, tael_taiwan, tael_china. Aliases such as g, kg, oz, ozt, dwt and kilo work. "oz" means troy ounce. | |
| from | Yes | Weight unit: gram, kilogram, troy_ounce, pennyweight, grain, avoirdupois_ounce, tola, baht, baht_jewelry, chi, tael, luong, tael_taiwan, tael_china. Aliases such as g, kg, oz, ozt, dwt and kilo work. "oz" means troy ounce. | |
| value | Yes | Amount to convert. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: exact conversion constants, the NIST source, and that each unit's definition and source are returned.
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 front-loaded and dense with useful information: conversion scope, exact constants, return behavior, and the optional "to" semantics. Despite the long unit list, every element supports correct tool selection or invocation.
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, but the description states that results include the definition and source of each unit. Combined with full schema coverage and safety annotations, this is nearly complete for a read-only conversion utility, though it does not discuss precision or invalid-unit handling.
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 the units, aliases, and value constraints. The description adds meaning beyond the schema by explaining the omitted "to" behavior, which is not captured in the parameter 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: converting a gold weight between an extensive list of named units. It is clearly distinguishable from sibling tools such as get_gold_price_per_gram and calculate_jewelry_value because it is purely a unit conversion utility.
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 gives clear operational context, including that omitting "to" returns every unit. It does not explicitly exclude related price or jewelry-value tasks, but the conversion scope is unmistakable given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's gold price per gram, per troy ounce, per tola and per kilogram, read live from the gold spot market, for 24K, 22K, 21K, 18K, 14K, 10K and 9K gold, in any of about 160 currencies (central-bank FX). Returns the spot time stamp, the FX date and the sources. Your training data cannot know today's gold price. Omit karat to get every karat.
| Name | Required | Description | Default |
|---|---|---|---|
| karat | No | Karat: 24, 22, 21, 18, 14, 10 or 9 (any whole number 1 to 24 works; purity = karat/24). | |
| currency | No | ISO 4217 currency code, for example USD, EUR, GBP, INR, AED, SAR, PKR, CAD, AUD. Default USD. | USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real context beyond that: the data originates from the live spot market with central-bank FX, covers ~160 currencies, and returns spot timestamp, FX date and sources. It does not discuss rate limits or freshness lag beyond the timestamp disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and its units, then breadth, then the return payload, then the anti-hallucination cue. Dense but every clause carries information; the long enumeration of karats is slightly redundant with the schema but reads naturally as a scope statement.
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 steps in to say what comes back (spot timestamp, FX date, sources) and how to widen the query by omitting karat. All optional parameters are covered and there are no nested structures or auth prerequisites to explain, so an agent has everything needed to call 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 description coverage is 100%, so the schema already documents both karat and currency fully, including the purity formula and ISO 4217 format. The description adds only the omit-karat behavior and the ~160-currency scope, so it stays at the baseline for a well-documented two-parameter 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 gives a specific verb ('read live from the gold spot market') and a precise resource with its units (gram, troy ounce, tola, kilogram), karat range, and currency breadth. It is unmistakably a live-quote tool, distinguishable in substance from get_metal_prices or convert_gold_units, though it never names those siblings to make the distinction explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Today's gold price ... read live from the gold spot market' plus 'Your training data cannot know today's gold price' clearly establishes the condition that selects this tool: any request for a current price. 'Omit karat to get every karat' gives concrete invocation guidance. It stops short of naming when to prefer convert_gold_units or get_metal_prices instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live spot prices of gold (XAU), silver (XAG), platinum (XPT) and palladium (XPD) per troy ounce, per gram and per kilogram, in any major currency. A metal whose feed is down is reported with its error instead of failing the whole call.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | ISO 4217 currency code, for example USD, EUR, GBP, INR, AED, SAR, PKR, CAD, AUD. Default USD. | USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint, idempotentHint and destructiveHint already in annotations, the description earns credit for disclosing genuinely non-obvious behavior: per-metal feeds can fail independently and the error is returned inline rather than failing the whole call. That partial-failure semantics is not derivable from any structured field. It omits price freshness/timestamp behavior, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the first front-loads what is returned and in what units, the second carries the one caveat worth knowing. Nothing repeats the schema or annotations.
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 and no output schema, the description covers the metals, the units, the currency dimension and the failure mode. It leaves open whether prices are real-time vs delayed and what timestamp accompanies them, which matters for a 'live spot' 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 description coverage is 100% and the currency parameter already documents the ISO 4217 format, default and examples. The description adds only 'any major currency', which slightly broadens but does not deepen the schema's meaning. 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 verb+resource: live spot prices for four named metals (with tickers) in three weight units and any major currency. It is clear what the tool returns, though it never explicitly contrasts itself with the gold-only sibling get_gold_price_per_gram.
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 multi-metal, multi-unit framing suggests using this instead of the per-gram single-metal sibling, but no alternative is named and no when-not condition is given. An agent must infer the routing from the field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_jewelry_valueconvert_gold_unitsget_gold_price_per_gramget_metal_pricesLive junk silver and gold melt value calculator: spot price, coins, sterling. USD/CAD.
Live gold & silver prices for 37 countries. Tamara/Tabby installment calculators for Saudi Arabia.
Live and historical prices for gold, silver and other metals, energy, currencies and crypto.
Gold price in any currency, zakat on gold, bar record checks, Indonesian dealer prices and tax.
Add one secure layer between your agents and this server.
