Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gold-price-per-gram-mcp What's the 22K gold price per gram in India today?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The live gold price per gram for AI assistants, by karat and currency, with metal prices, jewelry melt value and exact gold unit conversion.
This is a Model Context Protocol (MCP) server. It reads the gold, silver, platinum and palladium spot price at call time and converts it with central-bank FX rates for about 160 currencies. It needs no API key.
Tool | What it returns |
| Gold price per gram, troy ounce, tola and kilogram for 24K, 22K, 21K, 18K, 14K, 10K and 9K in any currency, with the spot time stamp and FX date. |
| Spot price of gold, silver, platinum and palladium per troy ounce, gram and kilogram in any currency. A metal whose feed is down is reported, not fatal. |
| Melt value of a gold item from weight, unit and karat, with an optional dealer spread percent. States that retail and buyback prices differ from melt value. |
| Exact conversion between gram, kilogram, troy ounce, pennyweight, grain, avoirdupois ounce, tola, Thai baht, Vietnamese chi and luong, Hong Kong tael, Taiwan tael and China liang, with the definition and source of each unit. |
Every result has structured JSON, a one-paragraph summary, as_of, source and more (the matching page on goldgramprice.com).
Related MCP server: mcp-metals-api
Today's gold price. Spot moves every minute and a model's training data is months old.
Today's exchange rate for INR, AED, SAR, PKR, EUR, GBP and about 150 more currencies.
Exact unit constants. A troy ounce is 31.1034768 g and a grain is 64.79891 mg by definition (NIST Handbook 44). A tola is 180 grains. A Thai bullion baht is 15.244 g, not 15 g. A kitchen-scale ounce is 28.349523125 g, not a troy ounce.
Karat purity as an exact fraction (karat / 24), so 22K is 91.6667% and 14K is 58.3333%.
Paste this URL. No token, no sign-up.
https://gold-price-per-gram-mcp.lipmichal.workers.dev/mcpclaude mcp add --transport http gold-price https://gold-price-per-gram-mcp.lipmichal.workers.dev/mcpOr run it locally over stdio:
claude mcp add gold-price -- npx -y github:theluckystrike/gold-price-per-gram-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"gold-price": { "command": "npx", "args": ["-y", "github:theluckystrike/gold-price-per-gram-mcp"] }
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"gold-price": { "url": "https://gold-price-per-gram-mcp.lipmichal.workers.dev/mcp" }
}
}Add to .vscode/mcp.json:
{
"servers": {
"gold-price": { "type": "http", "url": "https://gold-price-per-gram-mcp.lipmichal.workers.dev/mcp" }
}
}Node 20 or newer is needed for the local stdio version.
"What is the 22K gold price per gram in India today?"
"How much is one tola of 24K gold in Pakistani rupees?"
"I have a 14K chain that weighs 12 grams. What is its melt value, and what might a buyer offer at a 25% spread?"
"Show gold, silver and platinum prices in euros."
"How many grams are in a Thai baht of gold, and in a Vietnamese chi?"
All keyless and free to use from a server. Full list with fetch dates in DATA_SOURCES.md.
Spot prices from gold-api.com, the same feed goldgramprice.com uses. Its terms allow commercial use and ask callers not to send several requests per second, so the hosted server caches each price for 5 minutes.
FX rates from Frankfurter, blended from the ECB and other central banks. Cached for 1 hour. Rates update once a working day.
Unit constants from NIST Handbook 44 Appendix C. Karat definition from 16 CFR 23.3.
Prices are spot (melt) values for pure metal. Jewellery in a shop costs more (making charges, design, tax) and buyers pay less (refining and margin). The tools say so in every answer.
The spot price can be up to 5 minutes old on the hosted server. FX rates are daily reference rates, not live market quotes.
Purity uses the nominal karat fraction. Real items can be slightly under (legal tolerances) or over.
Regional tael values differ (Hong Kong 37.429 g, Vietnam 37.5 g, Taiwan 37.5 g, China 50 g). Pick the one you mean.
When a price feed is down, the tool returns a clear error instead of a stale or remembered number.
Karat calculators, scrap gold, city price pages and gold price history are on goldgramprice.com.
Part of the Zovo MCP collection: https://mcp.zovo.one
npm install
npm test # builds, then runs the fixture tests against saved upstream payloads
node scripts/smoke-stdio.mjs # live stdio check, one real call per tool
npx wrangler deploy # Cloudflare Worker, Streamable HTTP at /mcpMIT
Each one is free, needs no API key and has a hosted URL you can paste into Claude or ChatGPT.
server | tools | hosted URL |
convert_ingredient, search_ingredients, scale_recipe, convert_oven_temperature |
| |
calculate_dscr, max_loan_for_target_dscr, rent_needed_for_target_dscr, compare_scenarios, amortization_summary |
| |
search_lakes, get_lake_level, get_lake_history, compare_lakes |
| |
get_minimum_wage, list_upcoming_increases, compare_states, annual_income_at_minimum_wage |
| |
calculate_overtime_deduction, calculate_tips_deduction, calculate_senior_deduction, estimate_tax_savings, explain_eligibility |
| |
calculate_take_home_pay, compare_states_take_home, salary_to_hourly, hourly_to_salary, get_federal_tax_brackets |
| |
calculate_uk_take_home, get_uk_tax_bands, compare_salaries, marginal_rate_at_income |
| |
list_federal_holidays, is_business_day, add_business_days, count_business_days, invoice_due_date |
|
The paid back-office collection (invoices, VAT, PDFs, spreadsheets) is at https://mcp.zovo.one
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.
v1.0.0calculate_jewelry_valueconvert_gold_unitsget_gold_price_per_gramget_metal_pricesScored across 4 tools
get_gold_price_per_gram and get_metal_prices overlap on gold spot prices per gram/ounce, which could cause misselection at first glance. The descriptions do differentiate them (karat-level detail in ~160 currencies vs. multi-metal in major currencies), so an agent can resolve the boundary, but it takes reading.
All four tools follow a clean verb_noun snake_case pattern: get_gold_price_per_gram, get_metal_prices, calculate_jewelry_value, convert_gold_units. No mixed conventions or vague verbs.
Four tools is a tight, well-scoped surface for a precious-metals pricing server: price lookup, multi-metal lookup, valuation, and unit conversion. Each tool has a clear, non-redundant role.
The surface covers live pricing, multi-metal spot, melt valuation, and extensive unit conversion, which is strong for a live-price domain. The main gap is historical/time-series pricing and bulk/batch valuation, but agents can work around this for present-day price queries.
Precious metals AI analyst with 12 tools — prices, portfolio, chat, receipts, and more.
60+ units, live FX, timezones, and date arithmetic for AI agents.
Loan & mortgage calculator, compound interest, ROI, crypto prices, FX conversion for AI agents.
Live & historical FX rates and currency conversion for AI agents. No API keys.
