noisefloor

Name: noisefloor
Author: beepboop2025

by beepboop2025

Overview Schema Source Related Servers Discussions Admin

Python

Local

NoiseFloor

MCP Badge

What changed, what is repeated, and what can the evidence support?

A modular, offline toolkit for research desks, monitoring systems and AI agents. Python 3.9+, MIT, zero runtime dependencies. The same pure functions work through Python, JSON CLI, REST and MCP.

NoiseFloor checks market observations, groups repeated headlines, exposes data gaps and grades forecasts. It does not fetch feeds, call a model, retain your portfolio or execute trades.

Start with your research task

Your task	First step	What stays with the result
Inspect shared-factor concentration	Open the correlation workbench and run a labeled synthetic example	Alignment, source restrictions, gaps and reference assumptions
Review changing market observations	Run `noisefloor market examples/market.json` from this repository	Observation clocks, visibility gaps and descriptive review priorities
Reduce repeated headlines	Run `noisefloor narrative examples/narrative.json`	Original events, changed quantities and conflicting reports
Connect an API or MCP client	Open the client kit	The same bounded input contract across transports

Use Python or the CLI locally for private observations. The browser workbench submits the selected example only when you run it; its bundled examples are synthetic. Public financial-source retrieval is a separate workflow in the Financial Evidence connection guide.

Version 0.4.0 adds correlation spectra, shared-factor concentration, an experimental correlation-cleaning candidate and rolling diagnostics, plus a separate synthetic Dyson Brownian-motion simulator. See the product applications and methods.

Try the live correlation and Dyson workbench with explicitly synthetic examples for LiquiLens, Seiche, Undertow, Riptide, Palimpsest and trading-agent research. The API client kit includes OpenAPI, Postman, Bruno, HTTP and local Python workflows. Browser requests go to the public service only when you run them; use Python locally for private panels.

Related MCP server: backtest-reality-check

Try the complete workflow

pip install 'noisefloor==0.4.0'
noisefloor capabilities
# From this repository; these fixtures are synthetic, not live market evidence:
noisefloor market examples/market.json
noisefloor narrative examples/narrative.json
python examples/demo.py

import json
from noisefloor import market, narrative

request = json.load(open("examples/market.json"))
report = market.assess(**request)
print(report["attention_queue"])
print(report["visibility_gaps"])

news = json.load(open("examples/narrative.json"))
print(narrative.triage(**news)["attention_queue"])

Market attention

Each series carries its identity, units, source, declared reuse permission, observation times and freshness limit. Optional availability clocks retain what the caller knew at the time. Missing data stays missing.

The engine checks age, future timestamps, duplicate clocks, contiguous history and measurement coverage. Prices become log returns; rates and spreads retain their units. It never calculates a return across a declared gap. An explicit policy identifies persistent departures, isolated latest moves and volatility expansion. Correlated movements are visible without being counted as independent confirmation.

Each series returns review, watch, no_supported_departure or insufficient_visibility, with sources and reasons. These are review priorities, not significance tests or trading signals. A quiet diagnostic does not prove a movement is noise. Source permissions are caller declarations, not a licensing audit. Market calendars, corporate actions and materiality require caller review. Trading volume is an economic observation, not automatically a sample denominator.

News and narrative attention

NoiseFloor groups similar wording for the same declared entities, keeps changed quantities and explicit denials separate, records every original event and produces a bounded queue. Differing reports with the same declared event key are highlighted for review. Caller-declared primary sources rank before commentary; repetition alone never increases priority.

This is wording/relevance triage, not fact checking, sentiment prediction or proof of independent corroboration. Deferred and filtered items remain available. An empty queue does not certify a quiet market. Titles are data, never instructions.

Statistical building blocks

Module	Purpose	Evidence boundary
`experiment.compare`	Sequential Bernoulli A/B confidence sequences	Conditional stable-arm Bernoulli assumptions; arbitrary trading outcomes do not qualify automatically.
`change.scan`	Directional change monitoring	Descriptive statistic, not an e-value or universal market false-alarm guarantee.
`coverage.check`	Examine measurement-count changes	Linear descriptive diagnostic; it cannot prove causation or rule out every sampling effect.
`forecast.next_value`, `forecast.score`	Issue and evaluate identical adaptive intervals	Full historical records/misses; coverage is empirical, not guaranteed for the next observation.
`multiple.select`	e-BH selection over a declared family	Requires explicit caller confirmation of valid e-values; arbitrary scores cannot confer selection authority.

from noisefloor import experiment, change, forecast, multiple
experiment.compare(500, 5000, 750, 5000)
change.scan([1., 2., 1., 2., 1., 2., 1., 2., 8., 9.])
forecast.score([float(x) for x in range(40)])
# Only after an independently justified e-value construction:
multiple.select({"metric_a": 25.0, "metric_b": 1.0}, valid_evalues=True)

valid_evalues=True is a declaration, not certification. A single-family e-BH guarantee does not justify repeatedly selecting families or unqualified peeking. Version 0.3 corrects overstated guarantees in 0.2; read the methods and migration notes.

AI agents and HTTP

{"mcpServers":{"noisefloor":{"command":"uvx","args":["--from","noisefloor==0.4.0","noisefloor-mcp"]}}}

Ten MCP tools: market_assessment, narrative_triage, ab_test, did_it_change, real_or_sampling, forecast_next, score_forecasts, which_metrics_matter, spectral_assessment, dyson_reference. Results include structured JSON. The spectral assessment is descriptive research; the Dyson reference is a synthetic simulation, not a fitted market model.

noisefloor-mcp-http --host 127.0.0.1 --port 8792
curl http://127.0.0.1:8792/v1/capabilities
curl -H 'Content-Type: application/json' --data-binary @examples/market.json http://127.0.0.1:8792/v1/market/assess

REST: POST /v1/market/assess, POST /v1/narrative/triage, POST /v1/spectral/assess, POST /v1/research/dyson. The hosted API base is https://api.seiche.info/noisefloor; the hosted MCP endpoint is https://api.seiche.info/noisefloor/mcp. Research routes: POST /v1/spectral/assess, POST /v1/research/dyson. Discovery: GET /v1/capabilities, GET /openapi.json; MCP: POST /mcp. Self-host behind your TLS/authentication and quota layer. HTTP logs bounded operation/outcome labels, not submitted observations, titles or request targets.

Hosted MCP: https://api.seiche.info/noisefloor/mcp. Check its health/version and tool list before assuming a package release is deployed there. Package, registry and host acceptance are separate states.

mcp-name: io.github.beepboop2025/noisefloor

Modular by design

Bring permitted data through the offline adapters. The Financial Evidence adapter preserves institution, metric, unit, source, rights and knowledge clocks without importing its SDK. LiquiLens institution evidence, Seiche funding, Undertow liquidity and Palimpsest coverage can remain separate while using common diagnostics. This does not imply those products already run this release.

Request/policy SHA-256 digests support identity checks and replay; they are not signatures or proof of source truth. No runtime network, model, database or paid API dependency is required.

Verification

pip install -e '.[dev]'
pytest -q

Tests cover issued/scored forecast parity, invalid statistical composition, stale/future/missing observations, transforms, coverage shifts, repeated and conflicting wording, privacy and Python/CLI/REST/MCP parity. Synthetic calibration checks do not establish live-market accuracy, profitability or failure prediction.

Origin and licence

Built from measurement-quality work for Palimpsest. MIT. Source and methods are inspectable; results retain their assumptions.

Available Tools

6 tools

ab_testAInspect

Can you call a winner on an A/B test yet? Uses anytime-valid confidence sequences, so it is SAFE TO RUN AFTER EVERY OBSERVATION — peeking does not inflate the false-positive rate the way a t-test or z-test does.

ParametersJSON Schema

Name	Required	Description
`alpha`	No	error budget, default 0.05
`a_label`	No
`a_total`	Yes	total observations in arm A
`b_label`	No
`b_total`	Yes	total observations in arm B
`a_successes`	Yes	conversions in arm A
`b_successes`	Yes	conversions in arm B

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description fully carries the behavioral burden. It discloses the key behavior: peeking is safe and does not inflate false-positive rates. This is critical for correct usage. However, it does not mention other behaviors like mutability or side effects, which are not relevant here.

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?

Two sentences, front-loaded with the core question, and immediately providing the essential statistical property. Every sentence adds value without redundancy.

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

Completeness2/5

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

The tool lacks an output schema and the description does not explain what the tool returns (e.g., recommendation, p-value, winner). Given 7 parameters and no output schema, the description is incomplete for an AI agent to fully understand the tool's behavior.

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?

The input schema covers 71% of parameters with descriptions. The description adds no additional meaning to parameters beyond what the schema provides. For the 29% not covered (a_label, b_label), the description does not compensate. Baseline of 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 asks 'Can you call a winner on an A/B test yet?' which directly states the tool's purpose. It specifies the methodology (confidence sequences) and distinguishes from sibling tools like forecast_next or did_it_change.

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 explicitly states that the tool uses anytime-valid confidence sequences and that it is safe to run after every observation without inflating false-positive rates. It contrasts with t-test/z-test, providing clear usage guidance, though no direct comparison to siblings is given.

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

did_it_changeAInspect

Did a metric actually change, or is the move noise? Detects both rises AND collapses against the metric's own history, with a stated false-alarm rate and no assumption about the distribution.

ParametersJSON Schema

Name	Required	Description
`values`	Yes	the metric's history, oldest first
`half_life`	No	optional: readings after which old history counts half, for drifting metrics
`two_sided`	No	detect drops as well as rises (default true)

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses key behavioral traits: detection of both rises and drops, use of historical data, a false-alarm rate, and no distribution assumption. This is fairly transparent, though it doesn't clarify whether the tool is read-only or how the false-alarm rate is set.

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 a single, well-structured sentence that front-loads the core question. It is concise and efficient, though could be slightly more scannable with a brief list. Every word earns its place.

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

Completeness2/5

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

The tool has no output schema, and the description fails to specify what the tool returns (e.g., boolean, p-value, signal strength). This is a significant gap, especially for a statistical tool where output interpretation is critical. The description also doesn't explain how the false-alarm rate is configured or communicated.

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 coverage is 100%, so baseline is 3. The description adds algorithm context (false-alarm rate, no distribution assumption) but does not elaborate on parameter syntax beyond what the schema provides. No parameter-specific details are added, so it meets but does not exceed the baseline.

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's purpose: determining whether a metric change is real or noise. It specifies 'detects both rises AND collapses' and includes unique algorithm properties (false-alarm rate, no distribution assumption), distinguishing it from siblings like ab_test (hypothesis test) or which_metrics_matter (metric selection).

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 implies the tool should be used when you need to know if a change is noise, providing context like 'against the metric's own history'. However, it does not explicitly state when not to use it or mention alternatives among siblings, slightly limiting guidance.

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

forecast_nextCInspect

What should the next reading be, and within what range? Range adapts to the metric's recent volatility and stays valid even when the metric shifts.

ParametersJSON Schema

Name	Required	Description	Default
`values`	Yes	the metric's history, oldest first
`nominal`	No	range coverage, default 0.8

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states that the range adapts to recent volatility and stays valid with shifts, but does not disclose how many values are needed, what model is used, or what happens with insufficient data. No mention of errors or limitations.

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 very concise, consisting of two sentences. It is front-loaded with the key question. However, the use of a question format might be less direct for an AI agent. No redundant information.

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

Completeness2/5

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

The tool has a simple input schema but no output schema. The description is incomplete because it does not specify the structure of the output (e.g., object with 'prediction' and 'range' fields). It also lacks guidance on edge cases like very short history or extreme volatility. For a forecasting tool, more detail is needed.

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%, with clear descriptions for both 'values' and 'nominal'. The tool description adds no additional meaning beyond the schema. Given high coverage, baseline score of 3 is appropriate.

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

Purpose4/5

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

The description uses a question to state the tool's purpose: predicting next reading and range. It mentions adapting to volatility, which hints at a unique feature. However, it does not explicitly state 'forecast' or 'predict' as a verb, and could be more direct. It distinguishes well from sibling tools which have different focuses.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives. There is no mention of prerequisites, data requirements, or scenarios where other tools like 'score_forecasts' or 'did_it_change' would be better suited. The description only implies use for forecasting, but lacks comparative context.

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

real_or_samplingAInspect

Did the metric move, or did the sample size underneath it move? Run this before reporting any RATE as a change — conversion rates, error rates and click-through all shift when the denominator shifts, for reasons that have nothing to do with the thing being measured.

ParametersJSON Schema

Name	Required	Description	Default
`values`	Yes	the metric's history, oldest first
`sample_sizes`	Yes	the denominator behind each reading, same order and length

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It describes the conceptual behavior (checking denominator shifts) but does not specify the output format, assumptions, or edge cases. The agent knows the goal but not the result type.

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 extremely concise, consisting of two short sentences. It front-loads the core question and immediately provides actionable context. Every word earns its place, and there is no waste.

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

Completeness3/5

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

Given the absence of an output schema and annotations, the description should ideally specify the return value. It adequately explains the use case and parameter relationships but leaves a notable gap regarding what the tool returns, which is essential for an agent to use it 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?

Schema coverage is 100%, providing basic descriptions for both parameters. The tool description adds meaningful context by linking parameters to real-world rate metrics and denominator shifts, enhancing understanding beyond the raw schema.

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's purpose: to determine if a change in a rate metric is due to actual movement or a shift in the denominator. It uses a specific verb 'run' and resource 'rate metric change'. The description effectively distinguishes from sibling tools like 'ab_test' and 'did_it_change' by focusing on the artifact of denominator shifts.

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 explicit guidance on when to use the tool: 'Run this before reporting any RATE as a change', with examples like conversion rates and error rates. It implies the context for use but does not explicitly mention when not to use it or list alternatives; however, the context is clear enough.

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

score_forecastsAInspect

How good would these forecasts actually have been? Grades every prediction the tool would have made over the history, using only what was known at the time, and reports calibration plus the worst misses.

ParametersJSON Schema

Name	Required	Description	Default
`values`	Yes	the metric's history, oldest first
`nominal`	No	range coverage, default 0.8

TDQS

A3.8/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the tool uses only information known at the time (avoiding look-ahead bias) and reports calibration and worst misses. No destructive side effects mentioned, which is appropriate for a read-only evaluation tool.

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?

Single sentence, front-loaded with purpose, no redundant information. Every word contributes meaning.

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?

Given no output schema, the description adequately hints at return values ('calibration plus worst misses'). Parameter descriptions in schema complement well. No significant gaps for a tool of this complexity.

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 coverage is 100% with parameter descriptions for 'values' and 'nominal'. The description adds no new meaning beyond what the schema already provides, so baseline score of 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 'grades every prediction the tool would have made over the history' and 'reports calibration plus the worst misses', using specific verbs 'grade' and 'reports'. It distinguishes from siblings like 'forecast_next' by focusing on historical evaluation.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'forecast_next' or 'ab_test'. The description implies usage for historical forecast evaluation but does not provide explicit context or exclusions.

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

which_metrics_matterBInspect

You watch many metrics; which genuinely stand out? Controls the false discovery rate across all of them at once, which per-metric thresholds do not: forty metrics each alerting wrongly 5% of the time means two false alarms every round.

ParametersJSON Schema

Name	Required	Description	Default
`alpha`	No	false-discovery rate, default 0.1
`evidence`	Yes	metric name -> evidence value, e.g. the 'evidence' field from did_it_change

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description bears full burden. It explains the statistical concept (FDR control) and provides an example, but does not describe output format, assumptions, or edge cases (e.g., required dependencies like did_it_change evidence values).

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?

Two concise sentences with an engaging tone. The first sentence is a question but quickly leads to explanation. No filler, every word earns its place.

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

Completeness3/5

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

Given no output schema and sibling tools, the description misses key context: the evidence parameter expects output from a sibling (did_it_change), and the output is not described. The tool's niche is clear but integration details are lacking.

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 coverage is 100%, so baseline is 3. The description adds no extra detail about parameters beyond what the schema provides (e.g., alpha default, evidence structure).

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

Purpose4/5

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

The description clearly states the tool controls false discovery rate across many metrics, contrasting with per-metric thresholds. It includes a concrete example illustrating the problem. However, it does not explicitly differentiate from sibling tools beyond the conceptual niche.

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

Usage Guidelines3/5

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

The description implies use when multiple metrics are tested and false discovery control is needed, but lacks explicit guidance on when to use versus alternatives (e.g., when to use ab_test or score_forecasts).

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.

6 tool updatesv0.1.2Jul 28, 2026
- First observedab_test
- First observeddid_it_change
- First observedforecast_next
- First observedreal_or_sampling
- First observedscore_forecasts
- First observedwhich_metrics_matter

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-07-28 14:20 across 6 tools

Disambiguation5/5

Each tool targets a distinct statistical question: A/B testing, change detection, forecasting, denominator shift, forecast evaluation, and multiple testing correction. No overlap in purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase snake_case, e.g., did_it_change, forecast_next, which_metrics_matter. No deviations.

Tool Count5/5

6 tools is an ideal number for a focused statistics toolkit, covering essential operations without being overwhelming or sparse.

Completeness4/5

The set covers key statistical tasks (A/B testing, change detection, forecasting, multiple testing), but lacks a sample size/power analysis tool, which is a minor gap.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

regimen A
io.github.RaYYeR220
Tells you whether a trading strategy's edge is distinguishable from luck.
Finance Research & Data
41
LiveVariant A
io.github.livevariant
Build, inspect and read adaptive A/B tests. Config travels in the URL; no account or API key needed.
Feature Flags Marketing Product Management
911
databutler-stats A
io.github.physics-star-cat
Exact statistics & probability: distributions, hypothesis tests, CIs, Bayesian updates, regression.
Research & Data AI & Machine Learning
61
Disco A
com.leap-labs
Find novel, statistically validated patterns in tabular data — hypothesis-free.
Research & Data Data Platforms Databases
1427

Related MCP Servers

evalgateprivate
AI & Machine Learning Research & Data
ipezygj
A
license
A
quality
A
maintenance
Eval-integrity statistics for AI benchmark claims — multiple-testing correction, power/MDE for model gaps, judge-bias and leaderboard-rank checks. Catches a benchmark number that won't survive a second look.
Updated 2 months ago (2026-07-31 12:48 UTC)
9
MIT
backtest-reality-check
Finance Research & Data
maximdakulinin-boop
A
license
Not graded
quality
B
maintenance
Checks whether a trading backtest survives its own statistics: deflated Sharpe, multiple-testing correction against a best-of-N-noise benchmark, minimum track record length, and fill realism. Takes no market data and no API keys, and cannot recommend a trade — it only reports that a result is weaker than claimed or not yet provable.
Updated 2 months ago (2026-07-29 12:45 UTC)
MIT
Masset MCP Tools
Marketing Research & Data Data Visualization
BenMasset
A
license
Not graded
quality
B
maintenance
Provides honest A/B test verdicts using interactive cards, with statistical calculations for conversion rates, sample sizes, and Bayesian probability-to-beat.
Updated 2 months ago (2026-07-30 14:10 UTC)
MIT
genpark-statistical-zscore-iqr
AI & Machine Learning
alphaparkinc
A
license
Not graded
quality
B
maintenance
Enables zero-dependency statistical analysis of numerical and time-series streams, flagging outliers via standard Z-score, modified median absolute deviation (MAD), and Tukey IQR fences. Also supports trend forecasting with Holt linear smoothing, multivariate gradient-descent regression, Welch's t-test hypothesis testing, and Power Iteration PCA dimensionality reduction through a native MCP stdio interface.
Updated 16 days ago (2026-09-28 03:15 UTC)
7
MIT

NoiseFloor

Start with your research task

Try the complete workflow

Market attention

News and narrative attention

Statistical building blocks

AI agents and HTTP

Modular by design

Verification

Origin and licence

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

evalgateprivate