El agent feed, metodología MCP
Un feed de microestructura cross-exchange de solo lectura y descriptivo, expuesto sobre MCP (Model Context Protocol) para agentes de IA: siete activos en cuatro venues, reportados como hechos y normalización, sin veredictos.
Conecta un agente en /agents.
Qué es
Una llamada MCP devuelve un objeto de estado de mercado normalizado. El agent feed cubre siete activos, BTC, ETH, SOL, BNB, XRP, DOGE, HYPE, 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 plurianual sobre 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, OKXoiUsd, Hyperliquidcoins × markPx, Binancecoins × 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. 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 det, 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; eln_matchescrudo se reporta junto a él. Toda estadística se computa sobren_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 dicehistory_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_ratioobasis_bpsintersecan 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 plurianual.get_liquidations_recent, 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.
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_historydevuelven 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.4.1 · actualizado 2026-07-04. 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.4.1 (2026-07-04): primera metodología publicada del agent feed MCP, el modelo de cobertura honesta, la estadística de resultados condicionales y el archivo de estado de 15 minutos.