Skip to main content
Glama
celineycn

Quant Data MCP Server

by celineycn
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Quant Data — market-statistics skills for AI agents

Measured market statistics for index futures and equities, packaged so an AI agent can use them and — more importantly — report them honestly. Installs natively into Claude Code (plugin), Codex CLI (plugin marketplace) and Gemini CLI (extension), all from this one repository.

Skill

What the agent gains

Key needed

quantdata-daily-bias

Rolling Brooks price-action events with measured outcome rates, a calibrated day-type probability read for the US day session, a plain-arithmetic shape description of the bars already printed, and the measured verdicts on famous price-action claims

Free email key or paid key

quantdata-weis-wave

Volume-price wave structure and five Weis events, each with its measured win rate

Free email key or paid key

quantdata-max-pain

Options max pain, open-interest walls, put/call ratio, estimated dealer gamma exposure

Free email key or paid key; public pages need none

The honest summary of what you get: measured edges of 52–56%, published together with the places the models fail. There is a section below on exactly that, and it is not buried.

Which Quant Data this is. This project is Quant Data at quantdata.uk (API host api.quantdata.uk, MCP endpoint https://api.quantdata.uk/mcp, registry name uk.quantdata/quantdata). It is not affiliated with quantdata.us, an unrelated product with a similar name and a different API. Keys are not interchangeable between the two.

Install

Claude Code

/plugin marketplace add celineycn/quantdata-plugin
/plugin install quantdata@quantdata

Codex CLI

The same repository doubles as a Codex plugin marketplace:

codex plugin marketplace add celineycn/quantdata-plugin
codex plugin add quantdata@quantdata

Any other MCP client (Claude Desktop, ChatGPT, Cursor, VS Code, Zed)

The same four endpoints are a remote MCP server, together with an access tool that can email a free API key. Nothing to install — point the client at:

https://api.quantdata.uk/mcp

Streamable HTTP. With no key, one anonymous market-tool response is available per source per UTC day as a first look. The agent can then call quantdata_request_free_api_key with an email address; the free qd_ key is sent only to that inbox, needs no login or card, and gives the four market tools 10 shared successful calls per UTC day. A stdio bridge ships in quantdata/mcp/ for clients that can only launch a local command.

Details: quantdata/mcp/README.md.

Gemini CLI

The repository is also a Gemini CLI extension. GEMINI.md carries the three skill bodies merged into one context file:

gemini extensions install https://github.com/celineycn/quantdata-plugin

Then

Start a new session. You do not invoke a skill by name — just ask:

Did ES=F just break out of its range, and how often did breakouts like this fail?

Is the pullback in ES=F happening on low volume?

Where is max pain for TSLA this Friday?

Which way is dealer gamma leaning on NVDA?

To check it loaded, ask: "Which Quant Data skills do you have?"

Without the plugin system

A skill is just a folder with a SKILL.md in it, so you can also copy them by hand:

mkdir -p ~/.claude/skills
cp -R quantdata/skills/* ~/.claude/skills/

Or project-scoped, committed alongside your code, in .claude/skills/.

Related MCP server: agent-gamma (AgentGamma)

Start free — no login or card

One anonymous API or MCP call can return a complete first-look response per source per UTC day. For continued evaluation, request a free qd_ key by email:

curl -s -X POST https://api.quantdata.uk/v1/access/free-key \
  -H 'Content-Type: application/json' \
  -d '{"email":"you@example.com","marketing_opt_in":false,"source":"agent"}'

An MCP-connected agent can call quantdata_request_free_api_key instead. The raw key is never returned by the POST or MCP result; it is delivered only to the email address. The free key covers all four endpoints, sharing 10 successful calls per UTC day, and needs no account, password or card.

marketing_opt_in is optional and defaults to false. It is separate from key delivery. An agent must set it to true only after the owner of that email address explicitly asks for occasional product updates. Even then, the request records a pending preference, not an active subscription. The recipient must reply SUBSCRIBE to the key-delivery email to confirm it; no marketing updates are sent before that confirmation.

The permanently free surface is the Max Pain and GEX pages. No key, no account, no card:

https://quantdata.uk/max-pain/nvda
https://quantdata.uk/gex/nvda

Max pain (the option strike at which option buyers lose the most in aggregate at expiration), put/call ratio and open interest by expiration, one page per covered US stock or ETF — and a separate GEX page per ticker with net gamma exposure and the zero gamma (flip) level. The site is rebuilt nightly from the latest upstream settlement available, and every page states the open-interest settlement date it uses. Lowercase tickers. https://quantdata.uk/max-pain and https://quantdata.uk/gex are the coverage lists.

To check the research before paying for it, read https://quantdata.uk/methodology — an ordinary web page, free, no key. It publishes the fact-check of the trading literature's famous probability claims against 3,946 S&P 500 futures trading days (2010–2026). The claim that one of the session's extremes forms within the first 90 minutes is usually taught as 90%; the measured figure is 81.2%. The pattern holds across every claim tested — directionally right, inflated by roughly 7–10 percentage points.

Start there. If the numbers are not the size you expected from an honest test, do not buy.

The four API endpoints

The free email key covers every endpoint below, with 10 successful calls per UTC day shared across them. When that daily allowance is reached, the API returns 429 with the reset time and a checkout action to hand to a person. The paid plan removes the evaluation limit for ongoing, batch or unattended use.

One plan: $149/month, first 3 days free. Checkout is self-serve at https://quantdata.uk/pricing, and a card is collected up front. Checkout with the same email used for the free key upgrades that key in place, so an agent does not need a new secret. Cancel any time in the Stripe customer portal (https://billing.stripe.com/p/login/3cIfZhgcHfOb5IE7PD9Ve00), signing in with the checkout email.

Endpoint

Returns

GET /v1/brooks/{symbol}

Rolling Brooks price-action events, each with its measured outcome rate; range breakouts carry a calibrated per-event estimate. Every read also carries day_type — the calibrated five-class day-type distribution, US day session only — and shape, arithmetic over the bars already printed, in every window

GET /v1/weis/{symbol}

Volume waves and five named volume-price events with measured win rates

GET /v1/maxpain/{symbol}

Max pain per expiration, from open interest alone — pure arithmetic, no pricing model

GET /v1/gamma/{symbol}

Estimated dealer gamma exposure: net GEX, the zero gamma (flip) level, the heaviest strikes

One key covers all four. The two options endpoints are deliberately separate because the two figures are not equally reliable: max pain is arithmetic anyone can reproduce from the same chain, gamma is a Black-Scholes estimate built on an unobservable dealer-positioning convention. The skills quote the first as a figure and the second as an estimate.

The fact-check verdicts live on https://quantdata.uk/methodology as a static table — a web page to read, free and needing no key, not an endpoint to call.

Keys bought under the older two-product pricing keep working at their original price.

An AI agent can request the free key, but it cannot buy the paid plan for you. Card authentication (3-D Secure) requires the cardholder, so after the free allowance is reached the skills hand the checkout link to a person and stop.

Set your key

Copy the qd_ key from its delivery email into a secret store. Never paste a key into SKILL.md — those files are meant to be copied, committed and shared.

# ~/.zshrc (macOS default) or ~/.bashrc
export QUANTDATA_API_KEY="qd_your_key_here"

Then open a new terminal, or run source ~/.zshrc. Check it:

curl -s -H "X-API-Key: $QUANTDATA_API_KEY" https://api.quantdata.uk/v1/brooks/SPY

For an agent with no shell, the key goes wherever that tool stores secrets — an Actions authentication field, a credential entry, a .env loaded by your runtime. Same rule: a secret store, not a shared file.

Using these on platforms with no plugin system

Nothing here is specific to any one agent. A SKILL.md body is instructions plus an HTTP contract, so it works anywhere you can set a system prompt and send a request with a custom header. (Claude Code, Codex and Gemini CLI install natively — see Install above.)

  1. Open the SKILL.md you want, under quantdata/skills/.

  2. Copy everything below the closing --- of the YAML header.

  3. Paste it into your agent's system prompt, custom instructions or persona field.

  4. Replace the $QUANTDATA_API_KEY references with whatever your platform calls its secret.

Known to work this way: ChatGPT Custom GPTs (paste into Instructions, and add api.quantdata.uk as an Action with an X-API-Key header), Cursor and Windsurf rules files, Cline, GitHub Copilot instructions, n8n and Dify agent nodes, CrewAI and AutoGen agent backstories, LangChain system messages, and anything built directly on the OpenAI or Anthropic SDKs.

If your tool can send one HTTP request with one custom header, it is supported. There is no SDK, no OAuth flow and no callback URL.

What every one of these skills enforces

These rules are written into each SKILL.md and they are the reason the plugin exists:

  • Never present output as a buy or sell recommendation. The API returns detected events and historical frequencies. It does not know your position, account or risk. Turning "historically 62.6% of these breakouts failed within 10 bars" into "fade the breakout" is the agent inventing advice.

  • Always carry the disclaimer. Every response has a disclaimer field; it travels with the numbers.

  • Never claim precision the numbers do not have. The honest win rates are 52–56%. An agent that rounds that into "strong signal" has broken the product.

  • Name the baseline. A 51.8% event win rate is meaningless until you also say the any-wave-flip baseline is 49.3%. The day-type read's 66% top-1 accuracy travels the same way — always next to the 37% majority-class baseline.

  • Keep a measurement apart from a prediction. The day_type block predicts how an unfinished session could resolve and has published accuracy; the shape block measures bars that already printed and has none, because nothing is being predicted. A skill that labels a shape description a "trend day", or hangs the day-type accuracy on it, has broken the product just as surely as inventing a number.

  • Flag out-of-distribution use. The reference rates and models were measured on S&P 500 E-mini futures. A read on a single stock, on gold, or on crypto is descriptive, not validated.

  • At a free-key limit, relay message_for_your_human and hand checkout to the person. Respect quota_resets_at; never loop, and never substitute a different data source and present the result as Quant Data output.

Where this does not work

Publishing this is the point, not a disclaimer:

  • Crypto and gold have a consistent anti-signature. Of eight pre-registered Bitcoin signals, zero confirmed, and no_supply reversed direction outright.

  • Chart patterns did not survive testing. Over 121,000 pattern detections produced an AUC of 0.54 — near a coin flip.

  • The Asian session did not transfer. The pre-registered test of day-type gating on the Asian session returned NO_GO.

Educational analytics and developer tooling. Not investment advice, not a recommendation to buy or sell, not a price forecast. Trading involves risk of loss; past performance does not guarantee future results. Independent research — not affiliated with or endorsed by Al Brooks, David Weis, or any exchange or broker.

Docs: https://quantdata.uk/skills · Questions: quantdata@quantdata.uk

Available Tools

5 tools
quantdata_day_typeDay-type probabilitiesA
Read-only
Inspect

Day-type probabilities for the trading session in progress: a calibrated distribution over five classes (trending up, trending down, range, trending range, reversal) from a model trained on S&P 500 futures 5-minute bars. Answers 'what kind of day is this so far'. Descriptive statistics about how comparable past sessions resolved — not a forecast of today and not a recommendation. Check session_is_live before calling the read 'today', and check bars: fewer than 18 (90 minutes) means the distribution is provisional.

ParametersJSON Schema
NameRequiredDescriptionDefault
symbolYesTicker. 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.
sessionNoOmit 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.

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavior beyond the readOnlyHint and openWorldHint annotations: it explains that the output is a calibrated distribution, based on S&P 500 futures 5-minute bars, descriptive rather than predictive, and provisional under certain bar counts. It also discloses that the Asia session is explicitly unvalidated.

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

Conciseness5/5

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

The description is dense but every sentence adds value: it front-loads the core purpose, then covers output interpretation, caveats, and prerequisites without fluff. It is appropriately sized given the tool's complexity and safety checks.

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?

Despite having no output schema, the description fully explains what the tool returns (a calibrated five-class distribution plus descriptive statistics about past sessions), and it covers important context like the model training data and when results are provisional. The complexity is well handled with no major gaps.

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

Parameters4/5

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

The schema already covers both parameters thoroughly, so the baseline is 3. The description adds meaningful context by explaining that the default US session is the only window the model was measured on, and that the 'asia' session is accepted only for 24-hour instruments and is explicitly unvalidated.

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 clearly states the tool provides day-type probabilities for the trading session in progress, naming the five specific classes and the underlying model. It directly answers 'what kind of day is this so far', distinguishing it from the sibling tools which address other quantdata metrics.

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

Usage Guidelines5/5

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

It gives explicit prerequisites: check session_is_live before reading 'today', and fewer than 18 bars means the distribution is provisional. It also clearly warns against treating the output as a forecast or recommendation, and explains when to omit or pass the 'session' parameter, including the unvalidated Asia session.

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 exposureA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
symbolYesUS listed stock or ETF ticker, e.g. NVDA or SPY.
by_strikeNoInclude the strike-level gamma profile. Large; only request it when the user wants strike detail.

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

quantdata_max_painOptions max pain by expirationA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
symbolYesUS listed stock or ETF ticker, e.g. NVDA or SPY.
distributionNoInclude the full open-interest distribution by strike. Large; only request it when the user wants strike detail.

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

quantdata_request_free_api_keyRequest a free Quant Data API keyA
Idempotent
Inspect

Send 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailYesInbox that should receive the qd_ key.
marketing_opt_inNoOptional separate consent for product-update emails.

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses several behavioral traits beyond the annotations: the key is delivered only to the inbox and is never returned in the tool result, there is a shared daily quota of 10 successful calls, and a true marketing_opt_in stays pending until the recipient replies SUBSCRIBE. This adds substantial context that annotations (readOnlyHint=false, openWorldHint=true) do not convey.

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

Conciseness5/5

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

The description is well-structured and front-loaded with the core action. Every sentence adds value: no account required, coverage of data tools, key delivery mechanism, consent guidance, and pending status. It is appropriately detailed without redundancy.

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

Completeness4/5

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

The description thoroughly covers prerequisites, side effects, quota, and parameter handling. However, it does not explicitly state what the tool result contains (only that the key is not returned). Given there is no output schema, a brief mention of the expected result would improve completeness, but it is not a major gap.

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

Parameters5/5

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

Schema coverage is 100%, but the description enriches parameter meaning. For email, it implies the user's consent is needed. For marketing_opt_in, it adds crucial semantics: defaults to false, not required, only set true with explicit consent, and pending behavior. This is significantly more than the schema's brief descriptions.

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 starts with a specific verb and resource: 'Send a free qd_ API key to an email address.' It clearly distinguishes this from sibling market-data tools by stating the key covers all four market-data tools and that no account or payment is required. The purpose is unambiguous and differentiated.

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?

The description provides practical usage guidance: 'Ask the user for the email address before calling' and explicitly instructs when to set marketing_opt_in to true ('only when the email owner explicitly asks'). It also clarifies that marketing_opt_in defaults to false and is not required. While it does not explicitly name alternatives, the context of siblings makes the appropriate scenario clear.

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 structureA
Read-only
Inspect

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. Needs real exchange volume: spot FX has none — use CME currency futures (6E=F) instead. Use session='full' to match the published reference-rate window, or the default 'rth' for a regular-session-only read.

ParametersJSON Schema
NameRequiredDescriptionDefault
symbolYesTicker. 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.
sessionNoOmit 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.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint and openWorldHint, but the description adds meaningful behavioral context: it requires real exchange volume (spot FX has none), notes that two events came out REVERSED against tradition, and warns that session='full' can return 422 NO_EXTENDED_VOLUME and to obey retryable. This exceeds the annotation coverage without contradiction.

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

Conciseness4/5

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

The description is four sentences, each earning its place: definition, measured outcomes, FX/volume caveat, and session recommendation. It is dense but not bloated; all information is relevant. Slightly longer than necessary, but the structure 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.

Completeness4/5

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

Without an output schema, the description must convey what is returned, and it does: waves with summed volume, the five events, and their win rates. It also covers data requirements, error handling, and session semantics. Missing is a precise output format or example, but for the complexity, it is sufficiently complete.

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

Parameters4/5

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

Schema covers both parameters 100%, so baseline is 3. The description adds value by advising to use CME currency futures instead of spot FX due to volume requirements (relevant for symbol selection) and by recommending the session parameter based on the reference-rate window, which is a meaningful use-case nuance beyond the schema's technical detail.

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 clearly defines the tool as a Weis Wave volume-price structure analyzer, grouping price into waves and summing volume, plus identifying five classical volume-price events with measured win rates. It explicitly answers the question 'is there volume behind this move,' and is distinct from siblings like day_type, max_pain, and gamma.

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

Usage Guidelines5/5

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

The description states when to use this tool ('Answers is there volume behind this move'), provides an explicit alternative for spot FX ('use CME currency futures (6E=F) instead'), and gives session selection guidance ('full' to match published rates, default 'rth' for regular-session reads). This goes beyond simple context to explicit when-not and alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv1.4.0
    • First observedquantdata_day_type
    • First observedquantdata_gamma
    • First observedquantdata_max_pain
    • First observedquantdata_request_free_api_key
    • First observedquantdata_weis_wave
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct purpose: one handles API key requests, while the other four each address a different market data need (day type classification, volume-price structure, options max pain, and gamma exposure). Even the two options-related tools (max pain and gamma) are clearly differentiated by their methodology and output, with explicit notes on when to use one over the other. There is no meaningful overlap or ambiguity between any pair of tools.

Naming Consistency4/5

All tool names share the consistent 'quantdata_' prefix and use lowercase snake_case, which creates a clear family branding. However, the suffixes are not uniformly of the same grammatical form: 'request_free_api_key' is a verb phrase, while 'day_type', 'weis_wave', 'max_pain', and 'gamma' are nouns or noun phrases. This is a minor deviation from a strict verb_noun pattern, but the consistency in prefix and casing makes the set predictable.

Tool Count5/5

With exactly five tools, the server is well-scoped and compact. The tool count is within the ideal range (3-15) and each tool serves a clear, non-redundant function. There is no sense of bloat or sparseness; the number feels appropriate for a specialized quant data server.

Completeness4/5

For a server focused on delivering specific quant indicators, the set covers its stated domain well: request key, day type, weis wave, max pain, and gamma. The main potential gap is the lack of broader historical market data or a direct options chain endpoint, but the descriptions suggest the server's purpose is limited to these four analytical products. Overall, the surface is complete for its intended niche, with only minor possible additions.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • curistat-mcp

    moxiespirit
    A
    license
    A
    quality
    D
    maintenance
    Futures volatility intelligence MCP server for ES, NQ, and related products. Provides forecasts, regime detection, rare signals, and research tools for AI trading agents.
    10
    1
    MIT

  • agent-gamma (AgentGamma)

    Longfortv5
    F
    license
    Not graded
    quality
    D
    maintenance
    Here is a brief description of what our MCP server does: Description Project Tollbooth is a real-time market microstructure and options analytics gateway. It exposes quantitative Gamma Verdicts (hedging effects, dealer exposure aggregates, and volatility regimes) and 0DTE Verdicts (real-time pinning magnets, pin scores, and target probabilities) for major instruments (\*\*SPX,
    -

  • Petros Trading Scanner MCP

    peter21476
    F
    license
    Not graded
    quality
    B
    maintenance
    Read-only MCP server for short-term stock and ETF market research, providing tools for futures, premarket movers, market breadth, earnings, watchlist signals, and daily briefings.
    -

  • fin-data-mcp-server

    CohenD
    A
    license
    A
    quality
    C
    maintenance
    A Model Context Protocol server providing free financial market data across 13 categories with 83 no-key tools, enabling access to stocks, indices, options, forex, crypto, energy, prediction markets, and more.
    83
    2
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/celineycn/quantdata-plugin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server