By TickDistill — order-flow microstructure signals. Educational content, not financial advice.
MCP-first, agent-native distribution means that the primary interface for AI agents is not a web page to scrape, but a set of structured tools — MCP (Model Context Protocol) tools — through which an agent can discover packages, read signals, simulate rarity, and initiate a checkout, all without touching the visual UI. The machine-readable surface (MCP tools, llms.txt, JSON-LD) is the agent’s UI; the visual site is for human traders.
Web scraping is fragile as a distribution strategy for agents. A UI designed for human eyes has dropdown menus, modal overlays, dynamic charts, and session state that changes on every deploy. An agent scraping such a surface breaks the moment a CSS class is renamed or a component is refactored.
The correct alternative is a stable, versioned, semantically typed interface that agents can call directly. MCP tools fill exactly this role: each tool has a fixed name, a declared parameter schema, and a typed return value. The agent calls get_signal(package, asset, params, tf, range) the same way whether the visual site was redesigned last week or not.
The principle in TickDistill’s architecture is explicit: agents act via MCP and machine-readable endpoints; the visual UI is built for humans. The same logic runs underneath both surfaces.
TickDistill exposes five categories of MCP tool, mapping to the natural workflow of an agent that wants to use order-flow signals.
| Tool | What it does | Auth required |
|---|---|---|
list_packages |
Returns the full package catalog with summaries, tiers, and capability tags | None (public) |
get_package |
Returns full metadata for one package: technical detail, pseudocode (if free-tier), knob schema, knob_defaults, version |
None |
simulate_signal |
Returns frequency/rarity statistics for a package + parameter set: expected signals per day/week, recent sample | None for free, entitlement for paid |
get_signal |
Returns signal values for a time range and parameter set | API key + entitlement |
get_backtest |
Returns a signed download URL for a bulk Parquet/CSV backtest file | API key (free for standard, paid for deep history) |
create_checkout |
Returns a Stripe checkout link or confirms prepaid agent credits | Human-authorized or prepaid agent account |
An agent that discovers TickDistill for the first time calls list_packages, picks a package, calls get_package to read the knob schema, calls simulate_signal to verify the signal fires at a useful frequency for its strategy, then calls get_signal or get_backtest to retrieve data. Each step is a typed API call with a stable contract.
simulate_signal prevents agent overfittingsimulate_signal is the agent-facing equivalent of the rarity-meter shown in the human UI. Given a package, an asset, and a set of knob parameters, it returns how often that configuration fires historically — expected signal count per day or week, plus a recent sample of events.
This matters because a poorly tuned signal can fire hundreds of times per day (noisy, low-information) or almost never (so rare the agent cannot build a strategy around it). simulate_signal lets the agent — or the human reviewing the agent’s plan — verify that a parameter configuration is sensible before committing to a subscription or a backtest download. The computation is the same function used in the visual site’s frequency panel; there is one implementation in the engine, exposed via two surfaces.
A TickDistill signal is not a fixed output — it is a function f(primitives, parameters). The parameters (directional ratio, containment, density, window width, sigma threshold) are the knobs. Exposing the full knob schema in get_package means an agent can reason about the parameter space, select values programmatically, and call simulate_signal to validate a configuration before requesting data.
This design makes the MCP surface genuinely agent-native rather than a thin API wrapper. The agent can navigate the catalog, reason about tradeoffs, and configure a signal — all without a human intermediary. See How the Knobs Work as an Architecture for the full parametric model.
create_checkout returns a Stripe checkout link; it does not execute a payment. An agent calling create_checkout produces a URL that a human must open and authorize, or applies prepaid credits the account holder loaded in advance. TickDistill never permits an agent to move money without explicit human authorization — either at checkout time or through the deliberate act of loading agent credits onto an account. This is a hard product rule, not a soft preference.
Beyond MCP tools, three static layers make the site navigable by crawlers and retrieval systems.
llms.txt is a plain-text index at the site root that lists all explainers, package documentation, and API references in a format designed for language-model retrieval. It follows the llms.txt convention proposed as an emerging standard for AI-accessible site maps.
JSON-LD (TechArticle and Dataset schemas) is embedded in each explainer page and package detail page. It provides structured metadata — title, author, date, subject, related entities — that retrieval systems and knowledge graphs can parse without reading the prose. Search engines and AI retrieval pipelines both consume JSON-LD directly.
Machine-readable docs for each package include the pseudocode for free-tier packages (visible without login), the full knob schema in JSON, and OpenAPI-generated API references. These are designed to be parsed by an agent, not just read by a developer.
Together, these layers mean an agent can discover TickDistill through a retrieval search, read the package catalog in structured form, understand the signal semantics from the pseudocode, and invoke the MCP tools — without a human in the loop at any stage of discovery.
Every backtest result in TickDistill is deterministic given (signal, params, range, version). This produces two agent-relevant properties.
A content-addressed permalink is a shareable, stable URL that always reproduces the same backtest result. An agent can store this permalink and retrieve the same data later, or share it with another agent or a human reviewer, with a guarantee of bit-exact reproduction.
Version pinning (?version=v1) means that when TickDistill improves a signal formula to v2, all existing requests for v1 continue to return the v1 result. An agent that built a strategy on a v1 signal does not silently receive different numbers after a formula update. See Reproducible Backtests, Permalinks, and Version Pinning for the full design.
The MCP tool surface and the visual UI are not two separate codebases. The engine exposes one function for each computation — frequency statistics, signal retrieval, backtest generation — and both the MCP server and the Next.js site call the same underlying endpoint. This matters for reliability: a bug fixed in the engine is fixed for both agents and human users simultaneously, and behavior cannot drift between the two surfaces.
The architecture is described as “same logic below, two surfaces” — MCP tools for agents, rendered UI for humans. Each package’s metadata (human_summary, technical_detail, pseudocode, knob schema, version) lives in one registry and is served to both consumers from a single source of truth.
Can an agent use TickDistill without a human setting up an account?
Free-tier tools (list_packages, get_package, simulate_signal on free packages, get_backtest for the standard free history) require no prior account. An agent can discover, explore, and download free-tier data autonomously. Paid packages require an API key, which an account holder must generate; create_checkout requires human payment authorization or prepaid agent credits.
What is MCP and why is it used here instead of a plain REST API? MCP (Model Context Protocol) is a protocol for exposing typed, named tools to language-model agents. Unlike a plain REST endpoint, an MCP tool carries a machine-readable schema that an agent can inspect to understand what parameters are accepted and what the response structure is. The TickDistill MCP server wraps the underlying FastAPI REST endpoints; the typed schema is what makes the surface agent-native rather than just agent-accessible.
Does simulate_signal consume paid entitlement?
For free-tier packages, simulate_signal runs without entitlement. For paid packages, it requires the caller to hold the relevant package entitlement. The frequency/rarity computation itself is lightweight — it queries aggregated historical counts, not raw tick data — so it does not count against data-volume rate limits.
How does an agent know which packages apply to which assets?
Each package entry returned by list_packages and get_package includes capability tags: needs (which event types the package requires: trades, book L2, options) and markets (which assets the package supports: BTC, ES, or cross-market). An agent filters by these tags before calling get_signal. Packages that require L2 order-book data will not be available on assets for which only trade data is provided.
Why does the pseudocode appear in get_package but not the exact thresholds?
Free-tier packages expose their pseudocode as part of TickDistill’s transparency-first philosophy — the conceptual mechanism is public, and publishing it improves GEO discoverability. The exact calibration (window sizes, threshold values, composite weights) is proprietary and never returned by any tool, because the calibration is what makes the signal statistically clean and non-reversible to raw tick data. See Why We Sell the Measurement, Not the Alpha for the reasoning behind this distinction.
TickDistill sells clean, computed order-flow inputs — not trading advice or guaranteed alpha. Backtests are illustrative and not a promise of future results.