CRYPTYX — la capa de inteligencia para activos digitales.
Inteligencia de activos digitales de grado institucional entregada a través del Model Context Protocol. CRYPTYX convierte la telemetría cripto fragmentada en puntuaciones de factores, señales, backtests multifactoriales y clasificaciones de régimen, componiendo continuamente inteligencia a través de cientos de métricas, señales y activos.
No es un proxy de datos. Es una plataforma de investigación cuantitativa. 21 herramientas que abarcan 376 métricas, 8 clases de factores, ~200 activos rastreados y un registro de señales que se actualiza diariamente. Creado para traders, fondos, tesorerías, investigadores y los agentes que los sirven.
La ejecución es complementaria. Utilice CRYPTYX junto con kits de herramientas de intercambio como OKX y Kraken: ellos ejecutan, CRYPTYX proporciona la inteligencia.
npx @cryptyx/mcp-server{
"mcpServers": {
"cryptyx": {
"command": "npx",
"args": ["@cryptyx/mcp-server"],
"env": {
"CRYPTYX_API_KEY": "your-api-key"
}
}
}
}Variable | Requerido | Predeterminado | Descripción |
| Sí | — | Clave API de cryptyx.ai |
| No |
| Sustitución para despliegues autohospedados |
Related MCP server: fathom-fyi
CRYPTYX está diseñado para un flujo de trabajo agéntico específico. La mayoría de las herramientas se asignan a un paso en este bucle:
DISCOVER → DEFINE → VALIDATE → SCAN → STORE → EXECUTEDESCUBRIR — get_featured_metrics muestra las métricas de mejor rendimiento actual según el coeficiente de información (IC). Empiece aquí.
DEFINIR — analyze_metric o analyze_metrics_composite permite al agente construir una tesis multifactorial (p. ej., "z de impulso de tendencia > 1.5 Y z de estrés de financiación > 2.0").
VALIDAR — Las mismas herramientas devuelven rendimientos futuros en 8 horizontes (de 1 día a 365 días). El agente ve si la tesis tiene ventaja, no solo intuiciones.
ESCANEAR — scan_metric_universe ejecuta la tesis validada en ~200 activos en el último día. ¿Qué activos cumplen las condiciones ahora mismo?
ALMACENAR — fork_signal persiste la tesis como una nueva variante de señal inactiva. La tubería diaria la rastreará para siempre.
EJECUTAR — CRYPTYX no ejecuta. Entregue la orden a OKX, Kraken o cualquier capa de ejecución que utilice su agente.
El valor central de CRYPTYX. Estas herramientas permiten al agente realizar una investigación cuantitativa real frente a 376 métricas en 8 clases de factores.
Herramienta | Qué hace |
| Métricas de mejor rendimiento por coeficiente de información. Devuelve las 8 métricas de mayor convicción con calificaciones A/B. El mejor punto de partida. |
| Backtest de puntuación z de una sola métrica con rendimientos futuros en 8 horizontes. La herramienta principal de descubrimiento de factores. |
| Backtest de intersección multifactorial. Defina 2-4 condiciones de métricas y vea cuándo TODAS se activan simultáneamente, con rendimientos futuros en cada horizonte. Aquí es donde nacen las tesis. |
| Escanee una métrica en todos los ~200 activos para obtener extremos de puntuación z en el último día. Resultados clasificados con backtests de rendimiento futuro a 1d/7d/30d. |
| Puntuaciones t de factores para un activo en 8 clases de factores y múltiples horizontes. |
Una señal es una tesis persistente, versionada y parametrizada. CRYPTYX se envía con un catálogo de señales activas y permite a los agentes realizar backtesting, bifurcarlas y ajustarlas.
Herramienta | Qué hace |
| Activaciones de señales activas de hoy en todos los activos. Señales atómicas + resúmenes compuestos con puntuaciones de confianza. |
| Catálogo completo de señales con parámetros activos y estadísticas de activación de 30 días. |
| Explicación estructurada de por qué se activó (o no) una señal específica para un activo en un día determinado. Devuelve puntuaciones de factores y contexto compuesto. |
| Realice un backtest de una señal en cualquier rango de fechas. Devuelve recuentos de activación por día + estadísticas agregadas (tasa de activación, confianza promedio). |
| Cree una nueva variante de parámetro inactiva de una señal existente. La bifurcación se rastrea para siempre pero no afecta a la señal en vivo. Se requiere aprobación humana para activar. |
| Estime la tasa de activación si se cambiara un umbral de señal, sin realizar cambios. Hipótesis económicas. |
Herramienta | Qué hace |
| Universo de activos con puntuaciones compuestas, rendimientos, clasificaciones. Último o serie temporal. |
| Amplitud de factores en todo el universo. Muestra cuántos activos son positivos / negativos / neutrales por clase de factor. |
| Instantánea del estado optimizada para el agente: amplitud de factores, clasificaciones superiores/inferiores, resumen de señales, estado de la tubería. Contexto de base ideal antes de razonar. |
| Clasificación del régimen actual (en tendencia, reversión a la media, volátil) con puntuaciones de confianza de régimen primario + secundario. |
| Velas OHLCV diarias para un solo activo. |
| Precios spot con actualización de 15 minutos en todos los activos rastreados. |
| Universo completo rastreado con etiquetas de universo. |
Herramienta | Qué hace |
| Profundidad del libro de órdenes a 50 / 100 / 200 pb desde el punto medio, spot y opcionalmente futuros. Crítico para dimensionar la ejecución en el mundo real. |
Una tabla de clasificación pública y abierta donde los agentes de trading de IA compiten utilizando señales reales de CRYPTYX. Utilizado por la comunidad y una gran fuente de contexto de evaluación comparativa.
Herramienta | Qué hace |
| Enumere todas las rondas de competición con reglas, universo de activos y recuentos de entradas. |
| Tabla de clasificación en vivo: entradas clasificadas con ratio de Sharpe, rendimiento total, reducción máxima, puntuación compuesta. |
Código | Nombre | Qué captura |
CORR | Correlación | Dinámica de correlación entre activos, acoplamiento de régimen |
EFF | Eficiencia | Eficiencia del mercado, reversión a la media, agotamiento de tendencia |
FLOW | Flujo | Flujo de capital, movimiento de fondos, rotación de stablecoins |
FUT | Futuros | Posicionamiento de derivados, tasas de financiación, interés abierto, sentimiento |
OB | Libro de órdenes | Profundidad de spot y futuros, desequilibrio de oferta/demanda, microestructura |
OPT | Opciones | Volatilidad implícita, sesgo, estructura de plazos (alcance BTC/ETH) |
TR | Tendencia | Impulso de precios, fuerza de tendencia, transiciones de régimen |
VOL | Volatilidad | Dinámica de volatilidad realizada e implícita, compresión/expansión |
376 métricas definidas en 8 clases de factores
~200 activos digitales rastreados diariamente (objetivo: 500+)
8 horizontes: 1d, 7d, 14d, 30d, 60d, 90d, 180d, 365d
Tuberías diarias:
Métricas: 01:20 UTC
Señales: 02:27 UTC
Cuadros de mando de evaluación: 02:45 UTC
Optimización de agentes: 03:00 UTC
Actualización de 15 minutos para precios spot e instantáneas del libro de órdenes
Semanalmente, el agente de descubrimiento de fuentes de datos escanea más de 12 proveedores en busca de nuevas señales
Construir una tesis desde cero:
Usa CRYPTYX para encontrar las mejores métricas por IC, construye una tesis multifactorial que combine el impulso de tendencia con el estrés de financiación, haz un backtest en BTC y luego escanea el universo en busca de activos que cumplan ambas condiciones hoy.
Explicar una activación de señal:
¿Qué señales se activaron hoy? Elige la de mayor confianza y explica por qué se activó en ese activo específico.
Bifurcar y ajustar:
Bifurca la señal TR_MOMO_CONT_14D con un t_thr más estricto de 1.2, haz un backtest de ambas versiones durante los últimos 90 días y dime cuál tiene mejor IC.
Dimensionamiento de posición consciente del régimen:
Para mis 10 mejores activos compuestos, ¿cuál es el régimen actual? Dimensiona las posiciones inversamente al régimen de volatilidad: más grandes en tendencia, más pequeñas en volátiles.
Página de inicio: cryptyx.ai
Especificación OpenAPI: cryptyx.ai/openapi.yaml
Manifiesto del plugin de IA: cryptyx.ai/.well-known/ai-plugin.json
Referencia de IA: cryptyx.ai/llms-full.txt
Registro de cambios: CHANGELOG.md
MIT
Single-metric z-score backtest with forward returns across 8 horizons (1d to 365d). The core factor discovery tool — test whether a metric has predictive power.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Asset symbol (e.g. BTC) | |
| operator | Yes | Z-score comparison operator | |
| metric_id | Yes | Metric ID (e.g. TR_ADX_14D, VOL_GARCH_7D) | |
| threshold | Yes | Z-score threshold value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description discloses key behavior: it performs a z-score backtest with forward returns, implying a read-only computation. However, it does not specify whether it is read-only or mention any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and avoids unnecessary words. Every part contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains input and purpose well but is silent on output format or return values. Given no output schema, the agent lacks information on what the tool produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already documents parameters. The description adds value by explicitly mentioning 'z-score' and 'threshold', clarifying that threshold is a z-score threshold and connecting parameters to the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a single-metric z-score backtest with forward returns across 8 horizons, positioning it as the core factor discovery tool. This distinguishes it from sibling tools like analyze_metrics_composite and backtest_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is the go-to tool for testing a single metric's predictive power, but does not explicitly state when not to use it or mention alternative tools for multi-metric or signal-based analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-factor z-score intersection backtest. Define 2-4 metric conditions and see when ALL fire simultaneously, with forward returns at 8 horizons.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Asset symbol (e.g. BTC) | |
| conditions | Yes | Array of 2-4 metric conditions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'backtest' and 'forward returns at 8 horizons' but lacks details on resource consumption, data time range, or side effects. Without annotations, this is insufficient for safety assessment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. First sentence summarizes core purpose, second adds operational details. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description adequately covers purpose and behavior. It mentions 'forward returns at 8 horizons' to hint at output structure, but lacks details on edge cases or ordering. Still, it's sufficient for a basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context: conditions are z-score thresholds, require 2-4 items, and must all fire simultaneously. This clarifies the 'conditions' array's purpose beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a multi-factor z-score intersection backtest, specifying the verb 'backtest' and resource 'metric conditions'. It distinguishes from siblings like analyze_metric (single metric) and backtest_signal (signal-based) by focusing on multiple conditions firing together.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: define 2-4 conditions and see when all fire, with forward returns. It implies when to use (multi-factor intersection) and hints at alternatives (single metric or signal backtesting) via sibling tools, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a backtest for a signal over a date range. Returns per-day trigger counts and aggregate statistics (trigger rate, avg confidence). Essential for strategy optimization.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date YYYY-MM-DD | |
| from | Yes | Start date YYYY-MM-DD | |
| dryrun | No | If true, evaluate without writing to signal_log (default false) | |
| signal_id | Yes | Signal ID (e.g. VOL_SPIKE, TR_PRICE_MOM_Z) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Mentions outputs but omits side effects, permissions, or limitations (e.g., whether backtest writes to logs, read-only nature). Incomplete for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no verbosity, front-loaded with purpose, then output details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description partially explains return values (per-day counts, aggregate stats like trigger rate and avg confidence) but lacks details on other possible outputs, error handling, or data source assumptions. Adequate but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. Description adds little beyond naming outputs, not enhancing parameter meaning. Baseline 3 maintained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Run a backtest', resource 'signal', and scope 'over a date range'; specifies outputs (per-day trigger counts, aggregate statistics) and use case (strategy optimization). Distinguishes from siblings like simulate_signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage from 'Essential for strategy optimization' but no explicit when-to-use or when-not-to-use guidance. No comparison with sibling tools like simulate_signal provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new inactive parameter variant of an existing signal. The forked version can be backtested without affecting the live signal. Requires approval to activate.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | New parameter values as key-value pairs (e.g. { "z_threshold": 2.5 }) | |
| signal_id | Yes | Signal ID to fork (e.g. VOL_SPIKE) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the fork is inactive and needs approval, and that it doesn't affect the live signal. However, it lacks details on persistence, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence defines the action, second adds critical context about backtesting and activation. Every sentence is efficient and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters and no output schema, the description covers the tool's purpose, its safe testing nature, and the activation requirement. Minor gaps exist (e.g., error handling, limits), but it is largely complete for a simple mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented. The description repeats the example from the schema for 'params' and does not add new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new inactive parameter variant of an existing signal, using the verb 'create' and resource 'parameter variant of signal'. It distinguishes from siblings by specifying that the forked version can be backtested without affecting the live signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the fork is for backtesting and requires approval to activate, providing context. However, it does not explicitly state when not to use it or compare to alternatives like backtest_signal for direct backtesting without forking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get order book depth data for an asset — bid/ask USD at 50/100/200bp from mid. Critical for assessing real-world execution costs.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history (default 0 = latest only) | |
| asset | Yes | Asset symbol (e.g. BTC) | |
| include | No | Set to "futures" to include futures OB depth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions the tool returns bid/ask at specific basis points from mid, which is partially transparent. However, it does not disclose whether the operation is read-only (presumed), any rate limits, error handling for missing assets, or the exact output structure. This leaves some behavioral aspects unclear, justifying a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence states the tool's primary function, and the second adds importance. Every word is purposeful; there is no redundancy or extraneous information. It is well front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (3 parameters, 1 required) and no output schema. The description provides enough context for an agent to understand what the tool returns (bid/ask depth at specific price levels). While the exact output structure is not detailed, the description compensates sufficiently for a low-complexity tool. A higher score would require explicit output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter adequately. The description adds overall context (purpose of depth data) but does not clarify parameter-specific semantics beyond what the schema provides. With high schema coverage, the baseline is 3, and the description does not significantly elevate parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get order book depth data for an asset — bid/ask USD at 50/100/200bp from mid.' It specifies the verb ('Get'), resource ('order book depth'), and scope ('bid/ask at specific price levels'). This distinguishes it from siblings like 'get_market_snapshot' which likely provides broader market data. The description is precise and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'Critical for assessing real-world execution costs.' This implies the tool should be used when evaluating trade execution costs. However, it does not explicitly state when not to use it or mention alternatives among the sibling tools. While the guidance is clear and relevant, it lacks explicit exclusions or comparisons, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the CRYPTYX Challenge leaderboard — ranked competition entries with Sharpe ratio, return, drawdown, and composite scores.
| Name | Required | Description | Default |
|---|---|---|---|
| sort_by | No | Sort column (default: composite_score) | |
| round_id | No | Round ID (default: round_1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavioral traits. It only describes the output content (ranked entries with metrics) but omits details like read-only nature, authentication requirements, rate limits, or pagination. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and resource. Every word is informative, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explains the return value (ranked competition entries with specific metrics). It doesn't mention ordering or pagination, but overall it is sufficiently complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the two parameters (sort_by and round_id). The tool description adds no additional semantic meaning beyond what the schema provides, achieving the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'CRYPTYX Challenge leaderboard', and lists the key metrics included (Sharpe ratio, return, drawdown, composite scores). This distinguishes it from sibling tools like get_competition_rounds and get_composite_rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The purpose is implied, but there is no mention of alternatives or exclusion criteria. A score of 3 reflects adequate but not explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all competition rounds with rules, asset universe, and entry counts. Shows active and past rounds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the scope (all rounds, active/past) and output fields. But lacks details on ordering, pagination, or authentication requirements. Since it's a simple list, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Front-loaded with the action and resource, followed by specific content. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains the return content sufficiently for a list tool. Could mention ordering or whether filtering by round status is supported, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so schema coverage is 100%. Description adds meaning by listing output fields (rules, asset universe, entry counts), which is valuable beyond the empty schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists all competition rounds with specific content (rules, asset universe, entry counts) and includes both active and past rounds. It distinguishes from siblings like get_competition_leaderboard which focuses on individual round rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: when you need info about competition rounds. However, no explicit when-to-use or when-not-to-use compared to siblings like get_competition_leaderboard or other analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full current-state snapshot optimized for AI agents: factor breadth, top/bottom composite rankings, signal trigger summary, and pipeline status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose read-only nature, authorization needs, rate limits, or any side effects. The tool is likely a read operation, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded key purpose ('Get the full current-state snapshot') and a concise list of contents. No wasted words, though the phrase 'optimized for AI agents' is somewhat vague and could be omitted or clarified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description lists the main components (factor breadth, rankings, triggers, status). However, it lacks details on output format, data freshness, or limitations. For a no-param tool, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline 3 is appropriate as the description adds no parameter meaning since there are none. The description correctly implies no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a 'full current-state snapshot' with specific components (factor breadth, composite rankings, signal trigger summary, pipeline status). It distinguishes from siblings like get_factor_scores or get_signal_triggers by aggregating multiple aspects. However, it could be more explicit about how it differs from get_market_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The phrase 'optimized for AI agents' hints at context but does not specify scenarios or preferences over sibling tools like get_market_snapshot or get_factor_scores.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get factor t-scores for an asset across 8 factor classes (CORR, EFF, FLOW, FUT, OB, OPT, TR, VOL) and multiple horizons.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history (default 90) | |
| mode | No | snapshot (latest) or series | |
| asset | Yes | Asset symbol (e.g. BTC, ETH) | |
| horizons | No | Comma-separated horizons (e.g. 7d,30d). Valid: 1d,7d,14d,30d,60d,90d,180d,365d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry transparency burden. It only states it 'gets' data, implying read-only, but does not explicitly confirm idempotency, side-effects, or any behavioral traits like rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 16 words, front-loaded with verb and object, no redundant or extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, description provides minimal context: lists factor classes and horizons but does not explain what factor t-scores represent, how to interpret results, or any limitations. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions, so baseline is 3. Description adds context about factor classes and multiple horizons but repeats information already implied in schema (horizons enum). No additional clarification of parameter behavior or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Get' and resource 'factor t-scores for an asset' with explicit enumeration of 8 factor classes (CORR, EFF, FLOW, FUT, OB, OPT, TR, VOL) and multiple horizons, clearly distinguishing from sibling tools which focus on metrics, signals, or liquidity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_composite_rankings or get_regime_analysis. Lacks explicit when-not, prerequisites, or context for selection among 20 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top-performing metrics by information coefficient (IC). Returns the 8 highest-conviction metrics with A/B grades, plus the single best metric.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return content (8 metrics with A/B grades, plus best), but no annotation support. Adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a 0-parameter tool with no output schema; specifies return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage 100%. Baseline 4, description adds no param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it gets top-performing metrics by IC, returning 8 highest-conviction with grades plus best. Clearly distinguishes from siblings like analyze_metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied use as a quick overview tool, but no explicit when-to-use or alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest spot prices for all tracked assets (refreshed every 15 minutes). Useful for real-time context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the 15-minute refresh interval, indicating staleness, and implies a read-only operation ('spot prices'). Additional details like rate limits or data availability would warrant a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource. Every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits output structure; it says 'latest spot prices' but doesn't describe format (e.g., map of asset to price). Since there is no output schema, the description should briefly indicate what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest spot prices for all tracked assets, with a specific refresh interval. This distinguishes it from siblings like get_price_history (historical data) and get_market_snapshot (broader context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is 'useful for real-time context' but does not explicitly contrast with alternatives or state when not to use it. Given multiple sibling tools with overlapping purposes, clearer usage guidance would improve score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get factor breadth and regime analysis across the entire asset universe. Shows how many assets are in positive/negative/neutral territory per factor class.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history (default 30) | |
| classes | No | Comma-separated factor classes (e.g. TR,VOL) | |
| horizons | No | Comma-separated horizons (e.g. 7d,30d) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only describes what the tool returns. It does not disclose behavioral traits such as read-only nature, authentication requirements, or performance impact. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no superfluous information. The first sentence states the main purpose, and the second adds a concrete detail about the output. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no required parameters and no output schema, the description adequately explains the output (counts per factor class) and implies the role of parameters. It could be more explicit about the exact data structure returned, but overall it is sufficient for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds minimal extra meaning beyond the schema (e.g., hints that 'classes' relates to factor classes). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves factor breadth and regime analysis across the entire asset universe, specifying what it shows (counts per factor class). It distinguishes itself from sibling tools like get_regime_analysis by focusing on breadth and factor classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives. The description does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get asset universe with composite scores, returns, and rankings. Returns top-ranked digital assets by CRYPTYX composite score.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history for series mode (default 30) | |
| mode | No | snapshot (latest) or series (time series) | |
| assets | No | Comma-separated asset symbols (e.g. BTC,ETH,SOL). Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It mentions 'top-ranked' but does not define the ranking criteria, the number of results returned, or any limitations (e.g., default count, sorting). The output structure is also unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the core purpose. The second sentence adds specificity about top-ranked assets and the composite score, though it slightly repeats the first sentence. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's three optional parameters, no output schema, and many sibling tools, the description is insufficient. It does not explain the output format, how to use the 'mode' parameter, or when to specify assets. Additional context about the ranking criteria or result limits would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance understanding of how parameters interact (e.g., days only applies in series mode).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an asset universe with composite scores, returns, and rankings, specifically for top-ranked digital assets using the CRYPTYX composite score. This distinguishes it from sibling tools like get_composite_rankings and get_market_pulse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. It does not explain the purpose of the 'mode' parameter (snapshot vs series) or how specifying assets affects the output, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily OHLCV candle data for a single asset. Useful for backtesting and charting.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history (default 90) | |
| asset | Yes | Asset symbol (e.g. BTC) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions daily OHLCV data, but lacks details on error handling, rate limits, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with front-loaded purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple historical data tool with 2 params and no output schema, description covers purpose and use case adequately. Could mention response details but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds 'useful for backtesting' but does not enrich parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get daily OHLCV candle data for a single asset', specifying verb, resource, and scope. Distinguishes from siblings like get_live_prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Useful for backtesting and charting', providing context for use. No explicit alternatives, but implied differentiation from live data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current regime classification for an asset (e.g. trending, mean-reverting, volatile). Includes primary and secondary regime with confidence scores.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history (default 90) | |
| mode | No | snapshot (latest) or series | |
| asset | Yes | Asset symbol (e.g. BTC) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only lists output content (regime types, confidence) but omits any behavioral traits (read-only, authentication, rate limits, caching behavior, or potential side effects). This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then details. No extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output content (regime with confidence) but lacks error handling, rate limits, and context on whether the output is for a single asset or can be batched. With no output schema, the description could be more detailed. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters documented). The description adds no additional meaning beyond the schema; it does not clarify parameter interactions (e.g., effect of mode on output) or provide usage examples. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the current regime classification (trending, mean-reverting, volatile) and includes primary/secondary regimes with confidence scores. This verb-resource pair is distinct from sibling tools like get_market_pulse or analyze_metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for regime classification, but it does not explicitly state when to use versus alternatives (e.g., for short-term vs long-term regimes) or when not to use it. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active signals with their parameters and 30-day trigger statistics. Useful for understanding available signals before backtesting.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral weight. It correctly implies a read-only operation and describes the output (parameters and trigger stats). However, it lacks details on pagination, rate limits, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The key information is front-loaded, making it easy for an agent to quickly understand the tool's purpose and value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the main purpose and return content adequately. It could mention result format or limits, but is sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage. The description adds value by specifying that it lists active signals with their parameters and trigger statistics, which is meaningful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active signals with parameters and trigger statistics, using a specific verb and resource. It distinguishes itself from sibling tools like backtest_signal or get_signal_triggers by focusing on the catalog aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions usefulness before backtesting, providing clear usage context. However, it does not specify when not to use or list alternatives, which would be ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a structured explanation of why a specific signal fired (or did not fire) for a given asset on a given day. Returns factor scores and composite context.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Date in YYYY-MM-DD format | |
| asset | Yes | Asset symbol (e.g. BTC) | |
| signal_id | Yes | Signal ID (e.g. VOL_SPIKE, CORR_BREAKDOWN) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns factor scores and context, but it does not mention whether it is read-only, authentication requirements, or any side effects. The behavior is implicitly a read operation, but not explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose and key aspects. Every word adds value without any redundancy. It is appropriately front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description hints at the return value ('factor scores and composite context'), which is helpful but could be more complete about the structure of the explanation. For a tool with three required parameters and common signal analysis context, it provides sufficient context to use it, but lacks details on the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add new semantic details about the individual parameters beyond what the schema already provides (date format, asset symbol, signal ID). It restates the purpose but does not clarify data types, formats, or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'structured explanation of why a specific signal fired', and it uniquely distinguishes itself from siblings by specifying the three key parameters (signal_id, day, asset) and the return of 'factor scores and composite context'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for retrieving explanations of signal firing, but it does not explicitly state when to use it over alternatives like 'get_factor_scores' or 'get_signal_triggers'. No when-not-to-use guidance is provided, so it meets a minimal standard but lacks differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's active signal firings across all assets. Returns both atomic signals and composite rollups with confidence scores.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose behavioral traits such as whether the data is live or cached, timezone assumptions, rate limits, or what happens when there are no active triggers. The term 'today's' is vague without a definition of the time boundary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each adding distinct information. It is front-loaded with the core purpose and efficiently adds detail without any redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description covers the essential purpose and return types. However, it lacks context on timezone, data freshness, or error handling, making it minimally adequate but not thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by explaining the return content (atomic signals and composite rollups with confidence scores), which is not present in the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns today's active signal firings across all assets, with both atomic signals and composite rollups. It is specific enough to distinguish from siblings like 'get_signal_catalog' (which lists signals) and 'get_signal_explanation' (which explains a signal), though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For instance, it does not mention that only today's triggers are returned, nor that historical data requires a different tool. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a metric across all ~200 assets for z-score extremes on the latest day. Returns ranked results with forward returns at 1d/7d/30d horizons.
| Name | Required | Description | Default |
|---|---|---|---|
| operator | Yes | Z-score comparison operator | |
| metric_id | Yes | Metric ID to scan | |
| threshold | Yes | Z-score threshold value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'scans all ~200 assets' and 'returns ranked results with forward returns', but does not mention behavioral traits like read-only status, rate limits, or data freshness. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences concisely convey the action, scope, and output. No filler words; each sentence adds essential information. Front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 simple parameters and no output schema, the description provides a solid overview: it explains what the tool does, the scope (all 200 assets), and the output (ranked results with forward returns at three horizons). Missing details like result format or pagination, but adequate for a scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters (metric_id, operator, threshold) with descriptions. The description mentions 'z-score extremes' and 'threshold' implicitly but adds no new semantic meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scan', the resource 'metric across all ~200 assets', and the specific purpose 'z-score extremes on the latest day'. It distinguishes from siblings like 'analyze_metric' by specifying the universe-wide scope and time horizon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for scanning z-score extremes, but provides no explicit guidance on when to use it versus alternatives like 'analyze_metric' or 'backtest_signal'. Users have to infer usage from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tracked assets in the CRYPTYX universe with their universe tags.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action and result ('list all tracked assets with tags'), but omits details like response format, pagination, rate limits, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. However, it is very brief and could benefit from slightly more detail about the output or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain the return format or key fields. It only mentions 'universe tags' but does not specify what properties each asset object contains, making it incomplete for an agent to process results effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter info, but none is needed since the schema coverage is 100% (vacuously).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all tracked assets with their universe tags, using a specific verb ('List') and resource ('tracked assets in the CRYPTYX universe'). It distinguishes from sibling tools by focusing on assets rather than metrics or signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., scan_metric_universe for metrics). There is no mention of context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the trigger rate if a signal threshold were changed. Compares proposed threshold against current active threshold without making changes.
| Name | Required | Description | Default |
|---|---|---|---|
| asof_day | No | Date to simulate on (YYYY-MM-DD, default latest) | |
| signal_id | Yes | Signal ID (e.g. VOL_SPIKE) | |
| threshold_key | Yes | Parameter key to simulate (e.g. z_threshold) | |
| threshold_value | Yes | Proposed threshold value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It correctly states the tool is non-destructive ('without making changes'), but does not disclose other behavioral traits such as required permissions, rate limits, or whether it uses real-time or historical data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. It is front-loaded and efficient, conveying the core purpose and behavior without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema. The description explains the simulation concept but does not specify what the output is (e.g., estimated trigger rate, comparison details) or any limitations. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds minor context by mentioning 'proposed threshold' and 'current active threshold', but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates trigger rate for a threshold change, with the verb 'estimate' and resource 'trigger rate'. It also clarifies it does not make changes, distinguishing its intent, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives like backtest_signal. The phrase 'without making changes' implies it is for what-if analysis, but lacks clear context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_metricanalyze_metrics_compositebacktest_signalfork_signalget_asset_liquidityget_competition_leaderboardget_competition_roundsget_composite_rankingsget_factor_scoresget_featured_metricsget_live_pricesget_market_pulseget_market_snapshotget_price_historyget_regime_analysisget_signal_catalogget_signal_explanationget_signal_triggersscan_metric_universesearch_assetssimulate_signalScored across 21 tools
Each tool targets a distinct aspect of crypto analysis: single vs multi-metric analysis, signal management, different market data types, competition info, and factor scores. Even similar tools like 'get_market_pulse' and 'get_regime_analysis' have clear scope differences (broad vs per-asset).
Most tools follow a 'verb_noun' pattern, with 'get_' dominating (13/21). A few use different verbs like 'analyze_', 'backtest_', 'fork_', 'simulate_', 'scan_', 'search_', but the pattern is still readable and predictable.
21 tools cover the domain of crypto factor analysis, backtesting, and market data without being overwhelming. Each tool serves a clear purpose, and the count is well-scoped for the server's functionality.
The toolset covers core workflows: factor testing, signal backtesting, market scanning, competition info, and liquidity. Minor gaps exist (e.g., no direct signal creation, no competition entry submission), but agents can work around them.
Market intelligence for AI agents. Real-time data, cross-market analysis, and regime detection.
Crypto trading intelligence MCP — 34+ endpoints, x402 pay-per-use, AI agent strategy & execution
10 crypto tools for AI agents: BTC/ETH/SOL/XRP momentum signals, Polymarket odds, sentiment, x402.
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
