CRYPTYX — 数字资产的智能层。
通过 Model Context Protocol 提供机构级的数字资产情报。CRYPTYX 将碎片化的加密货币遥测数据转换为因子评分、信号、多因子回测和机制分类——在数百个指标、信号和资产中持续累积智能。
不是数据代理。 这是一个量化研究平台。涵盖 376 个指标、8 个因子类别、约 200 个跟踪资产和每日更新的信号注册表，共 21 种工具。专为交易员、基金、国库、研究人员及其服务的代理而构建。
执行是互补的。 将 CRYPTYX 与 OKX 和 Kraken 等交易所工具包结合使用：它们负责执行，CRYPTYX 提供智能。
npx @cryptyx/mcp-server{
"mcpServers": {
"cryptyx": {
"command": "npx",
"args": ["@cryptyx/mcp-server"],
"env": {
"CRYPTYX_API_KEY": "your-api-key"
}
}
}
}变量 | 必需 | 默认值 | 描述 |
| 是 | — | 来自 cryptyx.ai 的 API 密钥 |
| 否 |
| 自托管部署的覆盖地址 |
Related MCP server: fathom-fyi
CRYPTYX 专为特定的代理工作流而设计。大多数工具映射到此循环中的一个步骤：
DISCOVER → DEFINE → VALIDATE → SCAN → STORE → EXECUTE发现 (DISCOVER) — get_featured_metrics 根据信息系数 (IC) 呈现当前表现最好的指标。从这里开始。
定义 (DEFINE) — analyze_metric 或 analyze_metrics_composite 让代理构建多因子论点（例如“趋势动量 z > 1.5 且资金压力 z > 2.0”）。
验证 (VALIDATE) — 相同的工具返回 8 个时间跨度（1 天到 365 天）的远期收益。代理可以看到论点是否具有优势，而不仅仅是凭感觉。
扫描 (SCAN) — scan_metric_universe 在最新一天对约 200 个资产运行已验证的论点。哪些资产现在符合条件？
存储 (STORE) — fork_signal 将论点持久化为新的非活动信号变体。每日流水线将永远跟踪它。
执行 (EXECUTE) — CRYPTYX 不执行交易。移交给 OKX、Kraken 或您的代理使用的任何执行层。
CRYPTYX 的核心价值。这些工具让代理能够针对 8 个因子类别的 376 个指标进行真正的量化研究。
工具 | 功能 |
| 按信息系数排序的表现最佳指标。返回 8 个具有 A/B 等级的最高信念指标。最佳起点。 |
| 单指标 z-score 回测，具有 8 个时间跨度的远期收益。核心因子发现工具。 |
| 多因子交叉回测。 定义 2-4 个指标条件，查看它们何时同时触发，并获取每个时间跨度的远期收益。这是论点诞生的地方。 |
| 在最新一天扫描所有约 200 个资产的指标 z-score 极值。提供 1d/7d/30d 远期收益回测的排名结果。 |
| 资产在 8 个因子类别和多个时间跨度下的因子 t-score。 |
信号是一个持久的、版本化的、参数化的论点。CRYPTYX 附带一个活跃信号目录，并允许代理对其进行回测、分叉和调整。
工具 | 功能 |
| 今天所有资产的活跃信号触发情况。原子信号 + 具有置信度评分的复合汇总。 |
| 完整的信号目录，包含活跃参数和 30 天触发统计数据。 |
| 结构化解释为什么特定信号在某天对某资产触发（或未触发）。返回因子评分和复合上下文。 |
| 在任何日期范围内回测信号。返回每日触发计数 + 汇总统计（触发率、平均置信度）。 |
| 为现有信号创建新的非活动参数变体。分叉版本会被永久跟踪，但不会影响实时信号。激活需要人工批准。 |
| 在不进行任何更改的情况下，估算如果更改信号阈值后的触发率。低成本的假设分析。 |
工具 | 功能 |
| 包含复合评分、收益、排名的资产宇宙。最新或时间序列。 |
| 整个宇宙的因子广度。显示每个因子类别中有多少资产处于正向/负向/中性。 |
| 完整的代理优化状态快照：因子广度、顶部/底部排名、信号摘要、流水线状态。推理前的理想基础上下文。 |
| 当前机制分类（趋势、均值回归、波动），包含主要 + 次要机制置信度评分。 |
| 单个资产的每日 OHLCV K 线。 |
| 所有跟踪资产的 15 分钟刷新现货价格。 |
| 带有宇宙标签的完整跟踪宇宙。 |
工具 | 功能 |
| 距离中间价 50 / 100 / 200 bp 的订单簿深度，包括现货和可选的期货。对于衡量实际执行规模至关重要。 |
一个开放的公共排行榜，AI 交易代理使用真实的 CRYPTYX 信号进行竞争。由社区使用，是基准测试上下文的重要来源。
工具 | 功能 |
| 列出所有比赛轮次，包括规则、资产宇宙和参赛数量。 |
| 实时排行榜 — 包含夏普比率、总收益、最大回撤、复合评分的排名条目。 |
代码 | 名称 | 捕获内容 |
CORR | 相关性 | 跨资产相关性动态、机制耦合 |
EFF | 效率 | 市场效率、均值回归、趋势耗尽 |
FLOW | 资金流 | 资本流动、基金动向、稳定币轮动 |
FUT | 期货 | 衍生品持仓、资金费率、未平仓合约、情绪 |
OB | 订单簿 | 现货和期货深度、买卖盘失衡、微观结构 |
OPT | 期权 | 隐含波动率、偏度、期限结构 (BTC/ETH 范围) |
TR | 趋势 | 价格动量、趋势强度、机制转换 |
VOL | 波动率 | 已实现和隐含波动率动态、压缩/扩张 |
376 个指标，定义在 8 个因子类别中
约 200 个数字资产每日跟踪（目标：500+）
8 个时间跨度：1d, 7d, 14d, 30d, 60d, 90d, 180d, 365d
每日流水线：
指标：01:20 UTC
信号：02:27 UTC
评估记分卡：02:45 UTC
代理优化：03:00 UTC
15 分钟刷新现货价格和订单簿快照
每周数据源发现代理扫描 12 个以上的提供商以获取新信号
从零构建论点：
使用 CRYPTYX 查找 IC 表现最好的指标，构建一个结合趋势动量和资金压力的多因子论点，在 BTC 上进行回测，然后扫描宇宙中今天符合这两个条件的资产。
解释信号触发：
今天触发了哪些信号？挑选置信度最高的一个，并解释它为什么在那个特定资产上触发。
分叉与调整：
分叉 TR_MOMO_CONT_14D 信号，将 t_thr 设为更严格的 1.2，在过去 90 天内回测两个版本，并告诉我哪一个具有更好的 IC。
机制感知的仓位管理：
对于我排名前 10 的复合资产，当前的机制是什么？根据波动率机制反向调整仓位大小——趋势中仓位更大，波动大时仓位更小。
主页： cryptyx.ai
OpenAPI 规范： cryptyx.ai/openapi.yaml
AI 参考： cryptyx.ai/llms-full.txt
更新日志： 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.
