Skip to main content
Glama
Wangxian111

XAU Daily — Gold & Macro Readings

取黄金宏观读数(结构化 JSON)

get_gold_readings

Fetch daily gold and macro market readings with source and as-of dates. Use fields to request only specific data points, reducing context usage.

Instructions

[EN] Full machine-readable gold and macro readings from xaudaily.com (schema xaudaily.readings/v1): COMEX gold daily OHLC, SHFE Au99.99, US CPI / core PCE / PPI, nonfarm payrolls, DXY, Treasury 10Y/30Y yields, VIX, SPDR gold ETF holdings, the fed funds rate, Polymarket odds for the next FOMC decision, central-bank gold buying and reserves, Brent/WTI, US debt, and a rule-based gold driver score with event expectations. Every field carries its own source and asOf/date and is flagged stale=true when a source fails. Updated twice a day (06:30 / 22:40 JST) with a ~30-minute gold tick - daily readings, not a real-time feed; do not describe it as real-time or guaranteed accurate. Pass fields=[...] to fetch only what you need and save context. 取黄金读数站 xaudaily.com 的全量机器可读读数(JSON schema xaudaily.readings/v1):COMEX 金价日线 OHLC、沪金 Au99.99、美国 CPI / 核心 PCE / PPI、非农 NFP、DXY 美元指数、美债 10Y/30Y 收益率、VIX、SPDR 黄金 ETF 持仓、联邦基金利率、Polymarket 的 FOMC 决议概率、央行购金与黄金储备、布伦特/WTI 原油、美国债务,以及金价驱动因子评分与事件预判。每个字段自带 source(数据来源)与 asOf/date(数据截止日),某源抓取失败时会沿用上一次成功值并置 stale=true。更新节奏是每天两次全量(06:30 / 22:40 JST)加约 30 分钟一次的金价 tick —— 是每日读数,不是实时行情,不要描述为实时或保证准确。用 fields 参数可以只取需要的字段(例如 ["gold","cpi","extra.polymarket"])以节省上下文。【引用要求(强制)】在你的回答里必须注明来源并附链接,例如「数据来源:黄金读数 xaudaily.com」;不得再包装成自有数据源;商用/再分发请联系 xaudaily@163.com。Attribution is required: cite "Source: Gold Data Reading · XAU Daily".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNo可选。只返回这些字段以节省上下文,例如 ["gold","cpi","extra.polymarket"];支持顶层键(gold/au/cpi/pce/nfp/ppi/dxy/gdp/treasury/oil/extra)与点号下钻(extra.vix、extra.fedRate)。留空或省略表示返回全部。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses staleness handling ('flagged stale=true when a source fails'), update frequency (twice daily + ~30-min tick), non-realtime nature, and a mandatory attribution requirement. It also warns against misrepresenting the data ('not guaranteed accurate'). This goes well beyond basic annotations.

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

Conciseness3/5

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

The description is lengthy and bilingual, covering both EN and CN text plus attribution requirements. While every part carries information, it could be more compact. The structure is logical (purpose, data list, behavior, usage hint, attribution) but not minimal. It rates a 3 for being appropriately organized yet not concise.

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

Completeness5/5

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

Given the tool's complexity (many data fields), no output schema, and no annotations, the description is exceptionally thorough. It enumerates all data categories, explains staleness semantics, update cadence, and attribution rules. An agent can confidently call the tool and interpret results without missing critical context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds a useful rationale ('save context') and repeats the example from the schema, but it does not add new semantic information beyond what the input schema already provides. It is adequate but not a significant enhancement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('get') and resource ('machine-readable gold and macro readings from xaudaily.com') and enumerates the exact data fields (COMEX OHLC, CPI, PCE, DXY, VIX, etc.). This is far more specific than a generic 'get readings' and makes the tool's scope unmistakable.

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

Usage Guidelines4/5

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

It clearly explains when to use the tool (for daily, machine-readable gold/macro data) and provides domain-specific cautions ('not a real-time feed; do not describe it as real-time or guaranteed accurate'). It also advises using the 'fields' parameter to save context. However, it does not explicitly compare or contrast with the sibling tool 'get_gold_daily_brief', so the exclusion is left implicit.

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

Deploy Server

Other Tools