MCP Concepts

The vocabulary ByteTree MCP tools and the bytetree://glossary resource share. MCP clients pull the glossary in-band so the agent can ground its responses; this page is the human-readable form for customers who want to read before they poke.

ByteTree’s market-data dataset uses a small number of proprietary metrics that aren’t part of any public taxonomy. The definitions below are precise so prompts and tools can be reasoned about correctly.

Naming convention. Prose refers to the two ByteTrend variants as Weekly and Daily. The wire-format field suffixes are …200w and …30d respectively — those map to Weekly and Daily throughout this document. Both variants update every row; the suffix names a moving-average window length, not the score’s update cadence.

Quick reference

The five-key block below is what your LLM client sees inline if it calls summarise_dataset — short framings designed to fit in tool-response context. Use it as a TL;DR before reading the full sections.

{
  CAPR:
    "Currency-Adjusted Price Relative — the asset's USD price divided by the same day's MSCI World close. Rising = outperforming the global benchmark; falling = underperforming. Not a valuation metric.",

  ByteTrend:
    "Composite 0–5 score from 5 binary rules (close-vs-MAs, MAs-rising, last-touch-high). Two variants per axis: **Weekly arc** (fields suffixed `…200w`, with 200-week / 30-week MAs) for long-trend signal, and **Daily arc** (fields suffixed `…30d`, with 200-day / 30-day MAs) for short-trend momentum. Both arcs update every row; the suffix names the MA timescale, not the update cadence.",

  localVsCapr:
    "Every ByteTrend score has a Local (own-price) and CAPR (vs-benchmark) variant. So every asset has four ByteTrend scores per row: Weekly Local, Weekly CAPR, Daily Local, Daily CAPR. Comparing Local vs CAPR for the same arc isolates absolute vs relative leadership.",

  trendRegimes:
    "Five labels: Neutral (most assets, most days), Leading Trend, Emerging Trend, Weakening Trend, Bear Trend. The four named regimes only fire when an asset is simultaneously at an arc-window extreme (30-week for the Weekly `…200w` variants, 30-day for the Daily `…30d`) AND at a specific score level. The Weekly CAPR variant has a confirmation layer: `confirmedRegimeCapr200w` (stable, lags 5 trading days) + `pendingRegimeCapr200w` (candidate during transition) + `pendingRegimeCount200w` (1–4 during a streak, promotes at 5). Other variants (Weekly Local, Daily CAPR, Daily Local) are raw-only.",

  glossary:
    "Full definitions, predicates, and window-size tables: read the bytetree://glossary resource."
}

---

CAPR — Currency-Adjusted Price Relative

REST cross-link: Data Model, Latest Metrics — Valuation

CAPR is the asset’s US-dollar price divided by the MSCI World index on the same day: rising means it is beating the global market. ByteTrend’s documentation is the canonical explanation; see CAPR. On the wire, capr is the adjusted series (the default) and caprRaw the unadjusted one; they diverge across splits and dividends.

---

ByteTrend score

REST cross-link: Latest Metrics

A 0–5 score, one point for each of five rules on the asset’s recent price. ByteTrend’s documentation is the canonical explanation: the five rules, Daily and Weekly (including the moving-average and lookback windows, and crypto’s calendar-day equivalents) and Local and CAPR.

Each asset has four scores per row. The field suffix labels the variant (200w is Weekly, 30d is Daily), not how often it updates (every variant updates every row):

	Local (own price)	CAPR (against MSCI World)
Weekly (…200w)	byteTrendLocal200w	byteTrendCapr200w
Daily (…30d)	byteTrendLocal30d	byteTrendCapr30d

Score readings: 5 Strong Bullish · 4 Bullish · 3 Neutral-Bullish · 2 Neutral-Bearish · 1 Bearish · 0 Strong Bearish.

---

Trend regime taxonomy

REST cross-link: Latest Metrics, Regime Transitions

ByteTrend’s documentation explains the trend regimes for Weekly CAPR. The API classifies all four variants the same way, each with its own high/low window. Five labels, classified per first-match:

Order	Label	Predicate
1	Leading Trend	score === 5 AND at arc high
2	Emerging Trend	score > 0 AND at arc high
3	Weakening Trend	score > 0 AND at arc low
4	Bear Trend	score === 0 AND at arc low
5	Neutral	fallthrough — none of the above

The predicates above are the classifier’s. Because the high/low window is the same length as the short moving average, the reachable scores are narrower: Emerging Trend occurs at scores 1–4 (in practice 2–4; a score of 1 needs a price that has not moved across the whole window) and Weakening Trend at scores 1–3. Leading Trend is always 5 and Bear Trend always 0.

• atHigh = devFrom…High{30w|30d} >= 0 (the asset’s CAPR or local price equals the window max)
• atLow = devFrom…Low{30w|30d} <= 0 (equals the window min)

The high/low window follows the variant’s arc — it is not always 30 weeks: the Weekly (…200w) regimes use the 30-week deviation (devFromLocalHigh30w/Low30w, devFromCaprHigh30w/Low30w) and the Daily (…30d) regimes use the 30-day deviation (devFromLocalHigh30d/Low30d, devFromCaprHigh30d/Low30d). The same classifier runs for each variant with its own arc-matched deviation pair; it is a separate signal from the score’s own MA window pair. Each asset gets four regime labels per row, one per variant (trendRegimeLocal200w, trendRegimeCapr200w, trendRegimeLocal30d, trendRegimeCapr30d).

Most days, most assets are in Neutral. The four named regimes are corner cases that fire only when the asset is simultaneously at an arc-window extreme (30-week for Weekly, 30-day for Daily) AND at a specific score level. A Leading Trend asset can fall to Neutral simply by drifting off that high without any score change at all.

A null score (data gap) yields a null label, and the caller carries the previous label forward.

Confirmed, pending, and raw regime — the Weekly CAPR state machine

The confirmation layer applies only to Weekly CAPR (the trendRegimeCapr200w family). The other three regime variants — Weekly Local (trendRegimeLocal200w), Daily CAPR (trendRegimeCapr30d), Daily Local (trendRegimeLocal30d) — are raw-only. They flip immediately and have no confirmed or pending companion.

For the Weekly CAPR variant, four fields work together:

Field	Scope	Meaning
trendRegimeCapr200w	raw same-day	Today’s label per the first-match predicates above. Flips immediately. Useful for current-day display; noisy for historical reasoning.
confirmedRegimeCapr200w	confirmed	The label after 5 consecutive days of agreement. Use this for stable regime reasoning across history.
pendingRegimeCapr200w	candidate	A different label that’s currently accumulating votes towards becoming confirmed. null when raw matches confirmed and no transition is in progress.
pendingRegimeCount200w	counter	How many consecutive days the pending candidate has held. 0 when no pending; 1–4 during a streak; resets when the streak breaks or completes.

State transitions

REGIME_CONFIRMATION_DAYS = 5. Five branches, evaluated in order each trading day:

1. Data gap (raw is null) → freeze confirmed, pending, count, and trendAge200w at their previous values.
2. First valid day (no prior confirmed) → adopt raw immediately. confirmed = raw, pending = null, count = 0, age = 1.
3. Raw matches confirmed → confirmed unchanged, pending = null, count = 0 (cancels any active streak), age increments.
4. Raw matches the active pending (the candidate streak holds another day) → increment count. If count reaches 5: promote — confirmed = raw, pending = null, count = 0, age resets to 5. Otherwise stay in pending state — confirmed unchanged, pending = raw, count incremented, age increments.
5. New candidate (raw differs from both confirmed and any active pending) → start a fresh pending streak. pending = raw, count = 1, age increments.

Reading the state in practice

• A new regime label takes at least 5 trading-day rows to surface in confirmedRegimeCapr200w. Until then it sits in pendingRegimeCapr200w with pendingRegimeCount200w ticking up.
• A non-null pendingRegimeCapr200w with pendingRegimeCount200w >= 1 is “this label is on track to become confirmed in (5 − pendingRegimeCount200w) more days if it holds.” Useful for early signal of a regime change.
• A 1-day flicker (raw flips one day, then back the next) leaves confirmedRegimeCapr200w untouched — that’s the noise-absorption that makes the confirmed series usable for historical reasoning.

---

trendAge200w — Weekly trend age

REST cross-link: Latest Metrics

A daily counter coupled to the Weekly CAPR regime state machine. The naming suggests “days since the current regime began” but the actual semantics are slightly more nuanced — read carefully if precision matters.

Behaviour by branch (same state machine as the regime fields):

• During a stable confirmed regime (raw = confirmed): increments cleanly every non-null day. In this case it does mean “days at the current confirmed regime.”
• During an active pending streak (raw ≠ confirmed, accumulating candidate): continues incrementing past the prior regime’s end. The counter doesn’t pause for the streak.
• On the day a pending streak completes confirmation (count reaches 5): resets to exactly 5 (one for each day the streak ran). Empirically verified across thousands of confirmed regime flips at trendAge200w === 5; query semantics can use strict equality. Then increments normally from there.
• On a data-gap day (raw is null): keeps yesterday’s value rather than incrementing or resetting.

The clean reading (“strictly days since the current confirmed regime began”) only holds while pendingRegimeCapr200w === null. During an active pending streak the counter is approximate — it’s overcounting by the length of the streak so far. After confirmation it snaps back to a clean count.

No Daily-arc equivalent. trendAge only exists for Weekly CAPR; the other three regime variants have no age counter, since they have no confirmation layer to anchor “since this regime was confirmed.”

Unit is days at the price-data row cadence, asset-type-dependent:

• Stocks: trading days only (no rows on weekends/holidays).
• FX: weekdays. The series has weekend rows, but they repeat Friday’s value rather than adding to the count.
• Crypto: all days (24/7 markets).

A trendAge200w: 100 on a stock means ~5 calendar months; on a crypto it means ~3.3 calendar months. LLMs tend to read “100 days” as calendar days — be explicit about cadence when surfacing this number.

---

Score history fields

REST cross-link: Latest Metrics

scoreVelocity5d200w encodes the recent direction of the Weekly Local ByteTrend score (byteTrendLocal200w) on every metrics row. It makes trend-stability checks cheap from a single get_latest_metrics call — no series fetch needed.

scoreVelocity5d200w

5-day rate of change of the Weekly Local ByteTrend score, in score points per day:

scoreVelocity5d200w = (byteTrendLocal200w − byteTrendLocal200w-5-rows-ago) / 5

The denominator is a constant 5 (not “5 calendar days”); units are score-points-per-row at the asset’s row cadence. Range is bounded because byteTrendLocal200w is 0–5: max possible delta over 5 rows is ±5, so velocity is ±1.

Important scope note. These fields track the Weekly Local variant only. There is no scoreVelocity field for Weekly CAPR, none for either Daily-arc variant, and no per-rule lag chain. If an LLM client reasons “score trajectory is healthy” from scoreVelocity5d200w, that’s specifically the absolute-price-based ByteTrend trajectory — for the relative-to-MSCI-World trajectory, you’d need to compute byteTrendCapr200w[t] − byteTrendCapr200w[t-5] from a get_metrics_series call.

---

Universes

REST cross-link: Universes reference, Groups

Group-level aggregates come from two places on the public surface: the open macro dataset and the named product-dataset universes.

• macro — the open cross-market dataset, not a universe. Covers every active asset over five dimensions (region, sector, industry, type, country), each resolved as described on Dimensions: region is derived from country, and any dimension can carry a per-asset correction. It is get_group_metrics’ default and is served on its own path, so it does not appear in list_grouping_configs.

A universe is a named product dataset; each one’s source says how its membership is defined:

• rule — a screen: every active asset matching a rule (e.g. an asset-type filter).
• manual — a hand-picked basket.
• portfolio — a curated portfolio.

The public roster is bytetrend (the ByteTrend screen over active assets) plus curated baskets that appear once populated. Only populated universes are listed — list_grouping_configs shows the live set and each one’s memberCount. Dimensions (region, sector, industry, type, country) are shared across the surface, not defined per universe.

On the asset-level tools (list_assets, get_regime_transitions, get_metric_distribution) the two are independent filters: universe keeps only that universe’s members and narrows everything else you pass, while dimension + group (always together) filter on the global dimensions with or without a universe. Omit universe to cover the whole market.

Country is fixed across the surface

ISO codes mapped to full country names. The same per-country grouping applies everywhere; it is not customisable per universe.

Use list_grouping_configs to discover the universe slugs. Use get_group_metrics to query the aggregated metrics for a (universe, dimension, group) tuple — omit universe (or pass macro) for the open cross-market dataset.