Skip to main content
Glama

TradingCalc MCP: Options, Forex, Risk Stats, Prediction Markets, On-Chain & Crypto Futures

Event Study

workflow.run_event_study
Read-only

Event study with a placebo: is the average return after your events (a listing, an unlock, a signal firing) different from the average return of the same window started on random non-event dates? Give event_returns and placebo_returns in the same units; optional event_tickers and placebo_tickers (one per return) cluster the standard error by ticker, because events on one coin are not independent draws. Returns the effect (event mean minus placebo mean), Welch t-test, permutation p-value (exact when the number of splits is small, otherwise seeded random shuffles; two-sided as scipy.stats.permutation_test defines it), the cluster-robust t and p (statsmodels cluster covariance, t with clusters-1 degrees of freedom), the single event carrying most of the effect with the effect once it is dropped, honesty flags (few events, few clusters, one event dominates, sign flips without it, clustering changes the verdict) and a verdict that is distinguishable_from_placebo, not_distinguishable or fragile. It tests a difference you hand it; it does not pick dates, fetch prices or correct for look-ahead. Edge cases: event_returns and placebo_returns each 2 to 5000 finite values; event_tickers and placebo_tickers, if given, one per return, 1 to 32 characters; n_permutations a whole number 1000 to 100,000 (default 10,000) and permutations times events at most 50,000,000; alpha strictly between 0 and 0.5 (default 0.05); seed a whole number (same seed, same result); two constant samples are an error. Not covered: choosing the event window or the placebo set (the result is only as good as that choice), overlapping events, clustering in time, and causality. Use when user asks "is this effect real or noise", "does my signal beat random dates" or "run an event study with a placebo". Without at least two ticker clusters the verdict is never distinguishable_from_placebo, because there is no clustered test to confirm it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "event_returns": "<event_returns>",
      "placebo_returns": "<placebo_returns>"
    },
    "name": "workflow.run_event_study"
  }
}

Input Schema

NameRequiredDescriptionDefault
seedNoSeed for the shuffles, 0 to 4294967295; same input and seed give the same result. Default 1.
alphaNoSignificance level for the verdict, above 0 and below 0.5. Default 0.05.
event_returnsYesOne return per event over the event window, any consistent unit (percent or fraction). 2 to 5000 values.
event_tickersNoOptional, one ticker per event return, used to cluster. Omitted: every event is its own cluster.
n_permutationsNoRandom shuffles when the exact test is too large, 1000 to 100000. Default 10000.
placebo_returnsYesReturns over a window of the same length started on random dates without an event. 2 to 5000 values; event and placebo together at most 5000.
placebo_tickersNoOptional, one ticker per placebo return. Omitted: every placebo is its own cluster.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/destructive hints; the description goes far beyond by naming the exact outputs (effect, Welch t-test, permutation p-value, cluster-robust t and p with clusters-1 df), the honesty flags, and the three-valued verdict. It also discloses determinism (same seed, same result) and the critical behavioral caveat that without at least two ticker clusters the verdict can never be distinguishable_from_placebo.

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

Conciseness3/5

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

Front-loaded well with the core comparison, but the paragraph is a dense wall of text and a substantial portion restates structured data verbatim (2 to 5000 values, 1 to 32 characters, n_permutations 1000 to 100,000, alpha between 0 and 0.5, default 0.05). Those repeats earn no credit and lengthen an already long description.

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?

There is no output schema, and the description fully compensates by enumerating every returned statistic, the honesty flags, and the verdict values, plus failure modes (constant samples are an error) and statistical limitations. For a high-complexity statistical workflow, an agent has everything needed to call and interpret it.

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 coverage is 100% so the baseline is 3, but the description adds real meaning beyond field docs: the two return arrays must share the same units, and tickers exist specifically to cluster the standard error because "events on one coin are not independent draws." It also flags the combined 5000 cap and the permutations-times-events limit, which the schema does not state together.

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?

Opens with a specific method and a concrete comparison: average return after events versus the same window started on random non-event dates. No sibling tool covers event studies, and the description makes the placebo-based design unmistakable, so an agent can select it without opening the schema.

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?

Explicitly quotes the user phrasings that should route here ("is this effect real or noise", "does my signal beat random dates") and states when NOT to rely on it: it "does not pick dates, fetch prices or correct for look-ahead", with a separate "Not covered" list including overlapping events, clustering in time and causality. That is a genuine when/when-not/limits split.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.