CRYPTYX — デジタル資産のためのインテリジェンスレイヤー
Model Context Protocol を通じて提供される、機関投資家グレードのデジタル資産インテリジェンスです。CRYPTYXは、断片化された暗号資産のテレメトリをファクタースコア、シグナル、マルチファクター・バックテスト、レジーム分類に変換し、数百のメトリクス、シグナル、資産にわたってインテリジェンスを継続的に蓄積します。
単なるデータプロキシではありません。 クオンツリサーチプラットフォームです。376のメトリクス、8つのファクタークラス、約200の追跡資産、日次更新されるシグナルレジストリにわたる21のツールを備えています。トレーダー、ファンド、財務部門、研究者、そしてそれらを支援するエージェントのために構築されました。
実行機能は補完的です。 OKXやKrakenのような取引所ツールキットとCRYPTYXを併用してください。取引所が実行を担い、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のメトリクスに対して本格的なクオンツリサーチを行うことができます。
ツール | 機能 |
| 情報係数によるトップパフォーマンス・メトリクス。A/B評価付きの確信度の高い8つのメトリクスを返します。最適な出発点です。 |
| 単一メトリクスのzスコア・バックテストと8期間のフォワードリターン。主要なファクター発見ツールです。 |
| マルチファクター交差バックテスト。 2〜4つのメトリクス条件を定義し、すべてが同時に発生したタイミングと、各期間のフォワードリターンを確認します。仮説が生まれる場所です。 |
| 最新日の約200の全資産に対してメトリクスをスキャンし、zスコアの極端な値を探します。1日/7日/30日のフォワードリターン・バックテスト付きのランキング結果を返します。 |
| 8つのファクタークラスと複数の期間にわたる資産のファクターtスコア。 |
シグナルとは、永続的でバージョン管理されたパラメータ化された仮説です。CRYPTYXにはアクティブなシグナルのカタログが付属しており、エージェントはそれらをバックテスト、フォーク、調整できます。
ツール | 機能 |
| 全資産にわたる本日のアクティブなシグナル発生状況。アトミックなシグナルとコンポジット・ロールアップ（確信度スコア付き）。 |
| アクティブなパラメータと30日間のトリガー統計を含む完全なシグナルカタログ。 |
| 特定の日に特定の資産でシグナルが発生した（または発生しなかった）理由の構造化された説明。ファクタースコアとコンポジットのコンテキストを返します。 |
| 任意の期間でシグナルをバックテスト。日別のトリガー数と集計統計（トリガー率、平均確信度）を返します。 |
| 既存のシグナルの新しい非アクティブなパラメータバリアントを作成します。フォークは永続的に追跡されますが、ライブシグナルには影響しません。有効化には人間の承認が必要です。 |
| シグナル閾値を変更した場合のトリガー率を、変更を加えずに推定します。手軽な「What-if」分析です。 |
ツール | 機能 |
| コンポジットスコア、リターン、ランキングを含む資産ユニバース。最新または時系列データ。 |
| ユニバース全体のファクターの広がり。ファクタークラスごとに、いくつの資産がポジティブ/ネガティブ/ニュートラルかを示します。 |
| エージェント最適化された完全な状態スナップショット：ファクターの広がり、上位/下位ランキング、シグナル概要、パイプライン状況。推論前の基礎コンテキストとして最適です。 |
| 現在のレジーム分類（トレンド、平均回帰、ボラティリティ）と、一次および二次レジームの確信度スコア。 |
| 単一資産の日次OHLCVローソク足。 |
| 追跡中の全資産の15分更新スポット価格。 |
| ユニバースタグを含む、追跡中の全ユニバース。 |
ツール | 機能 |
| ミッド価格から50/100/200bpのオーダーブック深度（スポットおよびオプションの先物）。実戦的な実行サイズ決定に不可欠です。 |
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/.well-known/ai-plugin.json
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.
