El agent feed, metodología MCP

Qué es

Una llamada MCP devuelve un objeto de estado de mercado normalizado. El agent feed cubre nueve activos, BTC, ETH, SOL, BNB, XRP, DOGE, HYPE, ZEC, ENA, en Binance, Bybit, OKX y Hyperliquid, publicado bajo el nombre de registro ai.markettrace/agent-feed y alojado en https://api.markettrace.ai/mcp.

El feed reporta lo que puede medir y autodeclara cuánto confiar en cada número. Nunca devuelve una recomendación de trading; reporta historia y hechos con cobertura honesta. Reporta historia, no predicciones.

Fuentes de datos

El feed reutiliza el mismo pipeline cross-exchange que alimenta el sitio , todo en Rust, cero daemons de Python. Cada métrica lleva su propia procedencia y enlaza a una metodología por métrica más profunda:

• Financiación. Una tasa cross-venue informada por el OI más un percentil sobre una ventana móvil de 730 días de financiación normalizada por intervalo, ranqueada en un conjunto de venues consistente y profundo. Metodología de financiación →
• Interés abierto. Una suma en USD nativos de 4 venues: Bybit openInterestValue, OKX oiUsd, Hyperliquid coins × markPx, Binance coins × mark.
• Volumen. Una cinta consolidada de 30 días.
• CVD e imbalance del libro. Flujo taker cross-venue y OBI ponderado por flujo. Metodología de posicionamiento →
• Liquidaciones. Tres venues, Binance, Bybit, OKX; Hyperliquid se omite deliberadamente. Los valores en USD son estimaciones, cantidad base × el precio de referencia de la fuente del venue, y Bybit y OKX publican precio de bancarrota, algo que notional_semantics revela en cada respuesta. Metodología de liquidaciones →
• Basis. Perp-vs-spot en puntos básicos; positivo significa que el perp cotiza por encima del índice spot, donde el índice es un compuesto spot multi-exchange.
• Precio / OHLCV. Velas cross-exchange consolidadas.

El interés abierto suma los cuatro venues en USD nativos, Bybit openInterestValue, OKX oiUsd, Hyperliquid coins × markPx, Binance coins × mark. oi.rel compara el valor actual con su mediana horaria móvil (1d / 1w / 1m), y oi.chg_1h_pct es el cambio sobre la hora completa anterior. La línea base se une sobre el conjunto de venues en vivo, así que las filas heredadas de solo-Binance salen de la mediana , una re-acumulación honesta en lugar de una mezcla silenciosa de cobertura vieja y nueva.

volume.usd_24h es el notional negociado consolidado de 24 horas entre venues; volume.rel lo expresa frente a su mediana horaria móvil, como un multiplicador.

price.last es el mid consolidado. Los campos chg_*_pct son retornos frente a una línea base emparejada por tolerancia; atr_1h_pct es el ATR(14) sobre barras horarias, como porcentaje del precio; y rv_24h_pct es la volatilidad realizada anualizada a partir de retornos por minuto.

Cobertura honesta

Cada métrica lleva una entrada coverage. Una métrica escasa o joven se responde con honestidad, revelando su profundidad, y nunca se falsea para aparentar profundidad.

coverage: { venues, window_days, n_samples, partial, reason }
reason ∈ { accruing | unavailable | degraded | stale }

age_seconds es la antigüedad en el peor caso entre las fuentes en vivo que alimentaron los campos no nulos, de modo que un solo sub-feed rancio no puede esconderse tras otros más frescos. Un faro feed en cada respuesta, feed.version y feed.tools, permite a un agente detectar un catálogo de herramientas cacheado y obsoleto, y volver a leer el esquema.

Resultados condicionales

La herramienta insignia mide las tasas base de retornos futuros tras una condición declarada por el llamador. Sustituye el folclore , “financiación alta significa squeeze”, por la tasa base extraída de los propios datos del feed. La mecánica es deliberadamente conservadora:

• Percentil as-of. En cada hora histórica t, una condición declarada como percentil se ranquea solo contra datos en o antes de t, sin look-ahead. Se aplica un suelo estructural: un rango as-of existe solo cuando su serie tiene 12 muestras, porque un rango entre dos puntos es degenerado. Los umbrales de valor crudo no llevan ese suelo.
• Emparejamiento. Una coincidencia es cualquier hora donde todos los campos de condición declarados se cumplen a la vez, los campos se combinan con AND.
• Retornos futuros. Por horizonte (por defecto 4h / 24h / 72h):

r_h(t)  = close(t+h) / close(t) − 1            // retorno futuro al horizonte h
maxDD_h = min( low(t+1 … t+h) ) / close(t) − 1  // peor mínimo horario en (t, t+h]

• Colapso por solapamiento. Las ventanas futuras solapadas no son muestras independientes, así que las coincidencias se adelgazan a al menos un horizonte de separación, dando n_effective; el n_matches crudo se reporta junto a él. Toda estadística se computa sobre n_effective.
• Advertencia de clúster. La respuesta reporta la proporción de coincidencias efectivas que caen dentro de la ventana de 14 días más densa, una salvaguarda contra un solo episodio de squeeze disfrazado de N episodios independientes.
• El veredicto history_silent. Por debajo de 12 coincidencias efectivas en todos los horizontes, las estadísticas son null y el veredicto dice history_silent. Es una respuesta de primera clase, “la historia está en silencio; estarías operando sobre creencia, así que dimensiona en consecuencia”, no un error.
• Serie de precios. Los retornos se computan sobre cierres horarios de Binance (coverage.price_src), por diseño: sin serie consolidada ni cosida entre venues dentro de un mismo backtest.
• Condiciones de features de archivo (v2). Las condiciones sobre obi_skew, oi_chg_1h_pct, taker_buy_ratio o basis_bps intersecan la ventana de financiación con el joven archivo de 15 minutos; la ventana de respuesta reporta esa intersección con honestidad.

Historial de estado

Un archivo de 15 minutos almacena el estado de mercado servido completo por activo. get_state_history devuelve arrays de series temporales paralelos de cualquier campo numérico con notación de puntos , funding.percentile, oi.usd, obi.skew, submuestreados a max_points. El paso (stride) usado se reporta, y la fila más nueva nunca se descarta por submuestreo. El archivo es joven, nació el 2026-07-03, y crece hacia adelante, así que las respuestas escasas son honestas, no un fallo.

Herramientas

• get_market_state, un objeto de estado de mercado normalizado para un activo.
• get_funding_percentile, tasa de financiación con su percentil sobre la ventana móvil de 730 días.
• get_liquidations_recent, estimaciones de notional de liquidaciones recientes en los tres venues cubiertos.
• get_ohlcv, velas cross-exchange consolidadas.
• get_conditional_outcomes, retornos futuros de tasa base tras una condición declarada.
• get_state_history, arrays de series temporales del archivo de 15 minutos.
• get_volume_profile, niveles de volume profile por día UTC: POC, área de valor, POC desnudos.
• get_big_trades, grandes órdenes agresivas con totales por lado.
• get_footprint_events, muros del libro de órdenes absorbidos y retirados del footprint de 1 minuto.
• get_stacked_imbalances, desequilibrios apilados de compra y venta por vela, con la misma regla diagonal que el gráfico footprint.

Para saber cómo conectar un agente, consulta /agents.

Limitaciones

• Precio solo de Binance en el backtest. La serie de resultados condicionales usa cierres horarios de Binance; el delta frente a un precio consolidado es pequeño en los horizontes de 4h y más que reporta.
• El archivo de estado es joven. Crece hacia adelante desde el 2026-07-03, así que las condiciones de features de archivo y get_state_history devuelven ventanas cortas hasta que se llene.
• Salvedades de cobertura heredadas. Las salvedades propias de cada métrica subyacente se trasladan, pondera cualquier lectura por su entrada coverage.
• Solo lectura, descriptivo. El feed es de solo lectura y nunca una recomendación de trading. Reporta historia, no predicciones.

Versionado

Metodología versión v1.9.0 · actualizado 2026-10-06. Los cambios materiales (nuevas fuentes, ajustes de fórmula, cambios de umbral) suben la versión y actualizan dateModified en los datos estructurados de arriba.

v1.9.0 (2026-10-06): get_stacked_imbalances devuelve desequilibrios apilados de compra y venta por vela (1m, 5m, 15m, 1h) de la cinta de operaciones consolidada de los cuatro venues, con la regla diagonal que usa el gráfico footprint: banda de precio, filas marcadas y USD del lado dominante por serie, con ratio 2, 3 o 4.

v1.8.0 (2026-10-06): get_footprint_events devuelve muros del libro de órdenes absorbidos y retirados del clasificador del footprint de 1 minuto, con el tamaño máximo, el ejecutado y el de cierre en USD, y el recuento de minutos de libro fino; el archivo de eventos empieza el 2026-10-03 y crece hacia adelante.