Four market-statistics tools + a free qd_ key by email: 1 anonymous look, then 10 calls/UTC day.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 5 of 5 tools scored.
Each tool targets a distinct market data domain: Brooks price action events, dealer gamma, options max pain, API key request, and Weis Wave volume-price structure. Despite some conceptual overlap between options-related tools, their descriptions clearly differentiate calculations and data sources.
All five tools follow the exact same `quantdata_<topic>` snake_case pattern, making the naming perfectly uniform and predictable. No mixed conventions or stylistic deviations.
Five tools is a well-scoped set for a specialized quant data server. Each tool serves a clear analytical purpose, and the API key request tool supports access to the four data tools without bloating the surface.
The set explicitly covers four market-data categories plus key management, and each tool is fully self-contained for its intended analysis. No obvious dead ends or missing core operations within the stated domain of quantitative market analytics.
quantdata_brooks_eventsRolling price-action eventsAClassical 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.
quantdata_gammaEstimated dealer gamma exposureAEstimated 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?
Annotations include readOnlyHint and openWorldHint. Description adds context: estimation method (Black-Scholes with zero rate/dividend), dealer convention (long calls, short puts), null flip handling, and that it's based on end-of-day quotes. No contradiction with 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?
Description is lengthy but well-structured, front-loading purpose and key constraints. Each sentence adds necessary detail; could be slightly tighter but no superfluous content.
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?
No output schema provided, but description explains return fields (net/gross GEX, zero gamma flip, heaviest strikes, flip status, as_of, spot_date). Covers behavioral nuances and error handling, making it 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 description coverage is 100%, so baseline is 3. Description adds value: for 'by_strike' it warns it's large and only request when needed; for 'symbol' it reiterates the scope. Substantial extra guidance.
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?
Clearly states it estimates dealer gamma exposure for US listed stocks/ETFs. Distinguishes from siblings like max_pain with a detailed description of the Black-Scholes estimation method.
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 says when to use (US listed stocks/ETFs) and when not (cash-settled index options like SPX, NDX, RUT, VIX), providing alternatives (SPY, QQQ, IWM). Also notes it reads prior session's settled open interest and cannot update intraday.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quantdata_max_painOptions max pain by expirationAOptions 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?
Discloses that computation is pure arithmetic without pricing models, making it deterministic. Notes that open interest is from prior session, requiring as_of and spot_date. Annotations already indicate read-only and open-world, but description adds valuable context.
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?
Description is well-organized, front-loading the core definition, then adding necessary caveats and usage notes. No fluff; every sentence serves a 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?
Despite no output schema, the description clearly states what the tool returns (put/call ratio, heaviest strikes, all expirations within 45 days) and error conditions. Sufficient for an agent to understand outputs.
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 covers both parameters with descriptions. Description adds no new parameter-specific info but reinforces the purpose of 'distribution' as large and optional. Overall, it complements schema well.
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 defines the tool as computing options max pain per expiration from open interest, specifying it as the strike where option buyers lose most in aggregate. It distinguishes from siblings by focusing on a specific analytical metric.
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 states when to use (US stocks/ETFs) and when not to (cash-settled indexes, recommending alternatives like SPY, QQQ, IWM). Also explains that it returns all expirations within 45 days, guiding proper interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quantdata_request_free_api_keyRequest a free Quant Data API keyASend a free qd_ API key to 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. The raw key is delivered only to the inbox and is never returned in this tool result. Ask the user for the email address before calling. Set marketing_opt_in to true only when the email owner explicitly asks to receive occasional product updates; it defaults to false and is not required for the key. A true value stays pending until the recipient replies SUBSCRIBE to the key email.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Inbox that should receive the qd_ key. | ||
| marketing_opt_in | No | Optional separate consent for product-update emails. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: key is delivered only to the inbox and never returned in the tool result, the key shares 10 successful calls per UTC day across tools, and marketing_opt_in remains pending until the recipient replies SUBSCRIBE. These details meaningfully enrich the behavioral understanding.
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?
Seven sentences, each contributing relevant information without fluff. The main action is front-loaded, and the structure logically flows from what the tool does to prerequisites to parameter nuances. Slightly verbose but well-organized.
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?
Comprehensive coverage of prerequisites, side effects, rate limits, and the key's non-return. The only minor gap is not stating what the tool result actually contains (e.g., a success message), but the description explicitly clarifies what it does not contain.
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 clear descriptions for both parameters. The description adds value by specifying that the key is 'free', delivered only to the inbox, and provides consent-wording expectations ('only when the email owner explicitly asks') plus the pending state behavior for marketing_opt_in.
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 'Send a free qd_ API key to an email address' with a specific verb and resource. It distinguishes itself from the sibling market-data tools by explaining that the key covers all four tools, making the tool's role as an access-granting step 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?
Provides explicit prerequisites: 'Ask the user for the email address before calling' and clear consent instructions for marketing_opt_in. It does not explicitly name alternatives or exclusions, but the purpose is distinct enough to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quantdata_weis_waveVolume-price wave structureAWeis 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.