Four market-statistics tools + a free qd_ key by email: 1 anonymous look, then 10 calls/UTC day.
Scored across 5 tools
Each tool maps to a distinct analytical domain—Brooks price-action structure, dealer gamma exposure, options max pain, Weis Wave volume-price structure, and API key provisioning. Even gamma and max pain, which both relate to options, are clearly separated by purpose: estimated dealer hedging versus pure open-interest arithmetic.
All tools share the quantdata_ prefix and use snake_case, which gives some consistency. However, the set mixes bare nouns (gamma), proper-name noun phrases (brooks_events, weis_wave), and one verb phrase (request_free_api_key), so there is no uniform verb_noun pattern across the tool surface.
Five tools is well-scoped for a specialized quant-data server: four distinct market-data readers plus one API-key provisioning tool. Each tool earns its place, and none feel redundant or excessive.
The surface covers the advertised data products and the required API-key flow, so an agent can successfully complete the core workflows. Minor gaps exist—such as no general quote/bar retrieval or instrument metadata lookup—but the tool descriptions provide enough guidance to work around them.
Classical Brooks price-action events detected in the current trading window — the day's first range breakout, breakout follow-through, closes in the top or bottom third of an established range, long-lived-range breakouts, climactic spikes — each paired with the outcome rate measured for that exact definition in that exact window (pre-registered, ES 5-minute bars 2010-2026). Range breakouts also carry a calibrated per-event estimate of the probability the breakout closes back through its level within 10 bars (validated zero-shot on NQ 2023+: AUC 0.646, calibration error 5.1%, n=2,637). Answers 'what just happened structurally, and how did events like it resolve historically'. Works around the clock on 24-hour instruments, including the Asia-close-to-US-open gap window. Some measured rates contradict the classical claims; quote the measured numbers, not the folklore. Every read also carries two blocks that answer different questions and must not be mixed: day_type is the five-class day-type distribution, from the model trained for the current window. In the regular day session it is mode=day_session, with published accuracy: 66% top-1 over a complete session and 53.5% at the 90-minute mark, against a 37% majority-class baseline. In the Asian window it is mode=asia_session — trained natively on Asian windows, pre-registered, confirmed zero-shot on NQ — whose accuracy figures live in the response's own accuracy field and use their own label taxonomy: never quote the day-session figures for an asia read or vice versa. The gap window has no validated model and returns available=false there. shape is plain arithmetic over the bars already printed (where price closed inside its own range, how much of the travel was one-way, deepest pullback) — no model, no accuracy claim, available in every window including the gap. Report day_type as a distribution with its baseline; report shape as measurement, never as a forecast. day_type.analysis is the block to lead with (day-session reads only; the asia_session read carries no analysis layer) — it answers 'should today's read be trusted at all' before it answers 'what is today'. It carries: confidence (the model's own conviction crossed with how consistently the most similar past sessions resolved — both high has been right 95% of the time, both low only 41%, against a 66% baseline; say which bucket today falls in and stop treating a low-confidence read as a call); live_now (patterns mechanically confirmed on today's bars so far — e.g. 'broke yesterday's low then reclaimed it = bear trap confirmed' — this is what actually happened, trust it over any statistical checklist); what_to_watch (patterns over-represented on this day type, each with a status_today of yes/no/forming/unknown and a concrete way to verify it intraday; use the ordering, not the raw lift decimals); and summary / summary_zh, a one-line verdict written to be relayed verbatim — if you pass along only one sentence, pass that one. Descriptive statistics — not a recommendation. Check window_is_live before calling a read 'now'.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GC=F (COMEX futures) or GLD (the ETF) — not GOLD, which is a US-listed equity (Gold.com, Inc.). Spot gold itself has no feed here; a request for XAUUSD answers with the XAUT-USD token reading and says so. XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — relay its notes when you use it. | |
| window | No | Omit to follow whichever window has the freshest bars — usually what the user means by 'now'. 'rth' is the US day session; 'gap' is 16:00-21:30 Beijing, the stretch between the Asian close and the US open; 'asia' is 09:00-16:00 Beijing. gap and asia exist for 24-hour instruments (futures, FX, crypto) only. Every window carries its own pre-registered reference rates — the response pairs each event with the rates measured for the window it fired in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, so the description's job is to add operational context. It discloses pre-registration, local measured rates that may contradict folklore, the separate day_type and shape blocks, the missing model in the gap window, the confidence-bucket behavior, and the instruction to lead with day_type.analysis. This is rich, non-contradictory disclosure far 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?
The description is long but high-density: every sentence carries a distinct fact or caution. The bolded lead block and clear separation of day_type/shape/analysis improve scannability. However, the inline, paragraph-style formatting makes it harder to navigate than bulleted sections would be, and a few warnings (e.g., 'do not mix') are repeated in multiple forms.
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 must explain return values, and it does so thoroughly. It covers the day_type and shape blocks, the fields inside analysis (confidence, live_now, what_to_watch, summary), the asia-specific accuracy field, the available=false case for the gap window, and the proper way to relay the summary. This is complete for a complex 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 coverage is 100%, but the description adds substantial meaning beyond the schema. For the symbol parameter it explains resolution pitfalls (GOLD is an equity, gold is GC=F or GLD, XAUT-USD substitution for spot gold) and for the window parameter it explains which instruments support gap and asia and how each window's rates are pre-registered. This is not mere repetition; it is essential disambiguation.
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 detects classical Brooks price-action events in the current trading window and pairs each with historical outcome rates. It answers a specific question—'what just happened structurally, and how did events like it resolve historically'—and is obviously distinct from sibling tools like gamma, max_pain, and weis_wave.
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 provides clear usage context: it works around the clock on 24-hour instruments, explains the rth/gap/asia window semantics, and tells when a window returns unavailable. It even warns against mixing accuracy figures between day-session and asia-session reads. However, it never explicitly names sibling tools as alternatives or says 'when not to use this tool,' so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimated dealer gamma exposure (GEX) for a US listed stock or ETF: net and gross GEX, the zero gamma (flip) level and the heaviest strikes. Unlike max pain this is a Black-Scholes ESTIMATE — zero rate, zero dividend, implied volatility solved from end-of-day quotes, and the convention that dealers are long every call and short every put. Keep that framing when reporting it. A null flip is not an error: check flip_status — 'no_sign_change_within_10pct' means net gamma keeps one sign across the whole traded range, which is a state worth reporting. US listed stocks and ETFs only, with a liquid chain: cash-settled index options (SPX, NDX, RUT, VIX) return an error — use SPY, QQQ, IWM instead. Reads the prior session's settled open interest and cannot update intraday whatever the clock says, so report as_of and spot_date with the number.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | US listed stock or ETF ticker, e.g. NVDA or SPY. | |
| by_strike | No | Include the strike-level gamma profile. Large; only request it when the user wants strike detail. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses critical behavioral details: the Black-Scholes estimation assumptions (zero rate, zero dividend, implied volatility from EOD), the dealer convention (long calls, short puts), the null flip handling (flip_status values and their meaning), and data freshness ('Reads the prior session's settled open interest'). This goes far beyond 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 dense and every sentence adds distinct value, but it is somewhat lengthy for a single tool. It is front-loaded with the core purpose and then unfolds limitations and usage nuance. No waste, but the length itself slightly reduces conciseness.
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?
Despite lacking an output schema, the description covers the key output concepts (net/gross GEX, flip status, as_of/spot_date), error conditions, and limitations. It is comprehensive for a tool of moderate complexity, giving the agent sufficient context to set expectations and invoke 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?
The input schema already documents both parameters (symbol and by_strike) with clear descriptions, achieving 100% coverage. The description adds extra value by explaining the by_strike parameter's size implications ('Large; only request it when the user wants strike detail') and reinforcing the symbol scope ('US listed stocks and ETFs only'). This is a meaningful enhancement over schema alone, though not exhaustive.
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 uses a specific verb phrase ('Estimated dealer gamma exposure') and clearly defines the resource ('US listed stock or ETF') with concrete outputs (net/gross GEX, zero gamma flip level, heaviest strikes). It explicitly contrasts itself with sibling tool max pain, making differentiation 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 provides explicit usage boundaries: 'Unlike max pain this is a Black-Scholes ESTIMATE', states exclusions ('cash-settled index options (SPX, NDX, RUT, VIX) return an error — use SPY, QQQ, IWM instead'), and warns about intraday limitations ('cannot update intraday'). It also advises when to request by_strike ('only request it when the user wants strike detail').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Options max pain per expiration, computed from open interest alone: the strike at which option buyers lose the most in aggregate if the underlying settled there. Pure arithmetic — no pricing model, no volatility assumption, so anyone with the same chain gets the same number. Also returns put/call ratio and the heaviest call and put open-interest strikes. Returns every expiration inside 45 days rather than picking one, because the figure is per-expiration and the near- and far-dated values routinely disagree. US listed stocks and ETFs only: cash-settled index options (SPX, NDX, RUT, VIX) return an error — use SPY, QQQ, IWM. Open interest settles overnight, so this describes the prior session's positioning; report as_of and spot_date alongside the number.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | US listed stock or ETF ticker, e.g. NVDA or SPY. | |
| distribution | No | Include the full open-interest distribution by strike. Large; only request it when the user wants strike detail. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the readOnly/openWorld annotations: reproducibility due to 'pure arithmetic', deterministic results ('anyone with the same chain gets the same number'), error conditions for cash-settled indices, and the fact that results describe prior-session positioning. This adds significant value over the bare 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 dense paragraph, but every sentence adds value: it defines the metric, explains the computational invariant, lists additional return fields, justifies the 45-day window, enforces the universe restriction, and notes data timing. No fluff or redundancy; sentence order is logical and front-loaded with the core purpose.
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?
Given the moderate complexity and absence of an output schema, the description provides sufficient context: it names return components (put/call ratio, heaviest strikes, as_of, spot_date), explains per-expiration semantics, states the 45-day horizon, and covers error cases. This is fully actionable for an agent without further structure.
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 both parameters have clear descriptions in the schema (symbol and distribution). The tool description adds no new parameter-level details beyond the schema, e.g., it does not explain that the distribution parameter corresponds to the distributionally heavy output mentioned. Thus, 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?
The description clearly states the tool computes 'Options max pain per expiration' with a specific method (from open interest alone), and distinguishes itself from siblings like quantdata_gamma and quantdata_weis_wave by emphasizing it uses no pricing model or volatility assumption. It also specifies unique outputs (put/call ratio, heaviest strikes) and a specific scope (US stocks/ETFs), making it 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 provides explicit usage guidelines: 'Returns every expiration inside 45 days rather than picking one' and 'US listed stocks and ETFs only', with direct alternatives for excluded assets ('use SPY, QQQ, IWM'). It also gives behavioral context about data freshness ('open interest settles overnight'), helping the agent decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a free qd_ API key for an email address. No account, card, payment or GUI is required. The key covers all four market-data tools, sharing 10 successful calls per UTC day, and expires after 30 days. Ask the user for their email address first, then call this tool: the key is returned here so you can use it immediately in the X-API-Key header, and a copy is emailed to that address. Do not invent an address — the owner is told an assistant requested it and can have it disabled. This tool never returns a key that already belonged to that address; it issues one for this purpose only.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The user's own email address. Ask them for it; do not guess. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: annotations include idempotentHint=true, but the description says the tool 'never returns a key that already belonged to that address; it issues one for this purpose only.' This implies each call mints a new key rather than returning an existing result, so repeated calls with the same email would create new keys—contradicting idempotency. Apart from that, the description does disclose useful behavior such as emailing the key, owner notification, and the 30-day expiration.
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 tightly written and front-loaded with the core action, then followed by constraints, workflow, and safety guidance. Every sentence adds useful information and there is no redundant fluff.
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 tool with no output schema, the description covers the workflow, user consent, quota, expiration, and the resulting key's use in the X-API-Key header. It is nearly complete, but the tension with the idempotentHint annotation leaves some ambiguity about what happens if the same email is submitted repeatedly.
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 baseline is 3 because the schema already documents the email parameter. The description adds meaningful behavioral semantics beyond the schema: ask the user for their email, do not guess, and the key will be sent to that address, which helps the agent use the parameter correctly.
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: getting a free qd_ API key for an email address. It also distinguishes itself from the sibling market-data tools by explaining that the key covers all four of them, so an agent can clearly route a 'get a free key' request here rather than to a data tool.
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 an explicit workflow: ask the user for their email first, then call the tool. It also gives clear prohibitions ('Do not invent an address') and practical context about no account/card/payment being required, making it obvious when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weis Wave volume-price structure: price grouped into waves with volume summed per wave, plus which of five classical volume-price events have fired. Each event carries the win rate measured for it on sixteen years of S&P 500 futures data, including the two that came out REVERSED against the tradition. Answers 'is there volume behind this move'. Quote the measured reference numbers rather than the folklore. Spot FX has no volume at all — use CME currency futures (6E=F) instead. GC=F carries exchange volume and is the gold instrument here. A spot-gold request (XAUUSD) answers with the XAUT-USD token reading plus a note — that is the Tether Gold token's order book, a different instrument. Use session='full' to match the published reference-rate window, or the default 'rth' for a regular-session-only read.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GC=F (COMEX futures) or GLD (the ETF) — not GOLD, which is a US-listed equity (Gold.com, Inc.). Spot gold itself has no feed here; a request for XAUUSD answers with the XAUT-USD token reading and says so. XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — relay its notes when you use it. | |
| session | No | Omit for the US regular session. Use 'full' when comparing returned Weis events with the published reference win rates: those rates were measured on the whole bar stream, including pre/post-market. 'full' requires genuine extended-hours volume and can return 422 NO_EXTENDED_VOLUME; obey retryable, then use 'rth' if the source cannot provide it. 'asia' is accepted for 24-hour instruments only and is explicitly unvalidated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world hints. The description adds context about measured win rates on 16 years of data, including reversed events, and warns about instrument nuances, which aids interpretation. It does not detail the exact output structure, but the read-only nature is clear.
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 dense but front-loaded with the core functionality, followed by important instrument and session caveats. Every sentence adds value, though it is a single large paragraph that could benefit from bullet points for readability. It's appropriately sized for the tool's complexity.
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?
Without an output schema, the description gives a good sense of what is returned (waves, volume, events, win rates). It also covers key edge cases like XAUUSD and session-specific behavior. Minor gaps remain around exact return format, but overall it is complete enough for an agent.
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 descriptions already cover both parameters thoroughly (100% coverage), so baseline is 3. The description adds value by explaining the rationale for instrument choice (e.g., FX futures instead of spot) and the session 'full' behavior, which is not fully in the schema. This elevates the score above baseline.
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 what the tool does: groups price into waves with summed volume and identifies five classical volume-price events with measured win rates. It answers a specific question ('is there volume behind this move') and distinguishes itself from siblings by focusing on Weis Wave structure and reference data.
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?
Provides explicit instrument selection guidance: spot FX has no volume so use CME futures (6E=F), GC=F is the gold instrument, and XAUUSD returns a different instrument (XAUT-USD) with a note. Also explains session parameter usage ('full' matches published reference window, default 'rth') and error handling (422) in the schema, offering clear when-to-use and alternative handling.
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.
quantdata_request_free_api_key2 fields changedInput schema / properties / email / descriptionPrevious value: -"Inbox that should receive the qd_ key."New value: +"The user's own email address. Ask them for it; do not guess."Input schema / properties / marketing_opt_inRemoved value: -{
- "default": false,
- "description": "Optional separate consent for product-update emails.",
- "type": "boolean"
-}quantdata_brooks_events1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GC=F (COMEX futures) or GLD (the ETF) — not GOLD, which is a US-listed equity (Gold.com, Inc.). Spot gold (XAUUSD) is not covered. XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — send it only when the user asked for tokenised gold."New value: +"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GC=F (COMEX futures) or GLD (the ETF) — not GOLD, which is a US-listed equity (Gold.com, Inc.). Spot gold itself has no feed here; a request for XAUUSD answers with the XAUT-USD token reading and says so. XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — relay its notes when you use it."quantdata_weis_wave1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GC=F (COMEX futures) or GLD (the ETF) — not GOLD, which is a US-listed equity (Gold.com, Inc.). Spot gold (XAUUSD) is not covered. XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — send it only when the user asked for tokenised gold."New value: +"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GC=F (COMEX futures) or GLD (the ETF) — not GOLD, which is a US-listed equity (Gold.com, Inc.). Spot gold itself has no feed here; a request for XAUUSD answers with the XAUT-USD token reading and says so. XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — relay its notes when you use it."quantdata_brooks_events1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Spot gold as XAUUSD. Resolve names to tickers first: gold is XAUUSD (spot), GLD (ETF) or GC=F (futures) — not GOLD, which is a US-listed equity (Gold.com, Inc.). XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — send it only when the user asked for tokenised gold."New value: +"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GC=F (COMEX futures) or GLD (the ETF) — not GOLD, which is a US-listed equity (Gold.com, Inc.). Spot gold (XAUUSD) is not covered. XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — send it only when the user asked for tokenised gold."quantdata_weis_wave1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Spot gold as XAUUSD. Resolve names to tickers first: gold is XAUUSD (spot), GLD (ETF) or GC=F (futures) — not GOLD, which is a US-listed equity (Gold.com, Inc.). XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — send it only when the user asked for tokenised gold."New value: +"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GC=F (COMEX futures) or GLD (the ETF) — not GOLD, which is a US-listed equity (Gold.com, Inc.). Spot gold (XAUUSD) is not covered. XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — send it only when the user asked for tokenised gold."quantdata_brooks_events1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Spot gold as XAUUSD. Resolve names to tickers first: gold is XAUUSD (spot), GLD (ETF) or GC=F (futures) — not GOLD, which is a US-listed equity (Gold.com, Inc.)."New value: +"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Spot gold as XAUUSD. Resolve names to tickers first: gold is XAUUSD (spot), GLD (ETF) or GC=F (futures) — not GOLD, which is a US-listed equity (Gold.com, Inc.). XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — send it only when the user asked for tokenised gold."quantdata_weis_wave1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Spot gold as XAUUSD. Resolve names to tickers first: gold is XAUUSD (spot), GLD (ETF) or GC=F (futures) — not GOLD, which is a US-listed equity (Gold.com, Inc.)."New value: +"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Spot gold as XAUUSD. Resolve names to tickers first: gold is XAUUSD (spot), GLD (ETF) or GC=F (futures) — not GOLD, which is a US-listed equity (Gold.com, Inc.). XAUT-USD is the Tether Gold token's order book, a different instrument from spot gold — send it only when the user asked for tokenised gold."quantdata_brooks_events1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GLD or GC=F, not GOLD — GOLD is Barrick, the mining company."New value: +"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Spot gold as XAUUSD. Resolve names to tickers first: gold is XAUUSD (spot), GLD (ETF) or GC=F (futures) — not GOLD, which is a US-listed equity (Gold.com, Inc.)."quantdata_weis_wave1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Resolve names to tickers first: gold is GLD or GC=F, not GOLD — GOLD is Barrick, the mining company."New value: +"Ticker. US stocks and ETFs as-is (NVDA, SPY). US futures with =F (ES=F, GC=F). Hong Kong as digits.HK (3690.HK). China A-shares as 6 digits (600519). Crypto as PAIR-USD (BTC-USD). Spot FX with no slash (EURUSD). Spot gold as XAUUSD. Resolve names to tickers first: gold is XAUUSD (spot), GLD (ETF) or GC=F (futures) — not GOLD, which is a US-listed equity (Gold.com, Inc.)."quantdata_brooks_eventsquantdata_day_typequantdata_weis_wave2 fields changedInput schema / properties / session / descriptionPrevious value: -"Omit for the US day session, the only window these numbers were measured on. 'asia' (09:00-16:00 Beijing) is accepted for 24-hour instruments only and is explicitly unvalidated — the pre-registered transfer test returned NO_GO. Only pass it if the user asks, and say it is unvalidated when you report it."New value: +"Omit for the US regular session. Use 'full' when comparing returned Weis events with the published reference win rates: those rates were measured on the whole bar stream, including pre/post-market. 'full' requires genuine extended-hours volume and can return 422 NO_EXTENDED_VOLUME; obey retryable, then use 'rth' if the source cannot provide it. 'asia' is accepted for 24-hour instruments only and is explicitly unvalidated."Input schema / properties / session / enumPrevious value: -[
- "rth",
- "asia"
-]New value: +[
+ "rth",
+ "asia",
+ "full"
+]quantdata_request_free_api_keyquantdata_day_typequantdata_gammaquantdata_max_painquantdata_weis_waveFree US market data as tools: SEC filings, insiders, short interest, 13F, COT, Fed liquidity.
Crypto market data, 200 indicators, order flow and a chart link. No account, no API key.
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
33 quant tools. Kalshi 15-minute markets and perps, NFL props, NHL, Fed odds — free, no key.
Add one secure layer between your agents and this server.