SignalFuse 的 MCP 服务器 — 为 AI 智能体提供交易情报。
为任何兼容 MCP 的智能体添加了 11 个工具：方向性信号、情绪、宏观环境、策略竞技场、网络搜索、沙盒代码执行和账户管理。
# | 工具 | 端点 | 描述 | 价格 |
1 |
|
| 融合方向性信号 | $0.010 |
2 |
|
| 一次调用获取所有资产 | $0.075 |
3 |
|
| 社交情绪 | $0.002 |
4 |
|
| 宏观环境（风险偏好/风险厌恶） | $0.001 |
5 |
|
| 实时策略排名 | 免费 |
6 |
|
| 特定策略信号 | $0.001 |
7 |
|
| 通过 Brave 进行网络搜索 | $0.008 |
8 |
|
| 通过 Tavily 进行 AI 驱动搜索 | $0.012 |
9 |
|
| 通过 E2B 进行沙盒代码执行 | $0.005 |
10 |
|
| 定价信息 | 免费 |
11 |
|
| 积分余额查询 | 免费 |
四个实时策略在竞技场排行榜上进行正面交锋：
EMA Breakout — 基于指数移动平均线交叉的趋势跟踪
RSI Extremes — 在 RSI 超买/超卖水平的动量入场
RSI Reversion — 针对 RSI 极值的均值回归
VWAP Reversion — 围绕成交量加权平均价的均值回归入场
使用 get_arena_leaderboard 查看排名，然后使用 get_arena_signal 获取任何策略的信号。
Related MCP server: oneqaz-trading-mcp
npx signalfuse-mcp@1.1.0或全局安装：
npm install -g signalfuse-mcpPython 客户端（内置 x402 支付）：
pip install signalfuse添加到 ~/Library/Application Support/Claude/claude_desktop_config.json：
{
"mcpServers": {
"signalfuse": {
"command": "signalfuse-mcp"
}
}
}重启 Claude Desktop。询问："What's the signal for BTC?"，它会自动调用 SignalFuse。
添加到项目的 .mcp.json 中：
{
"signalfuse": {
"command": "signalfuse-mcp"
}
}免费试用 — 5 次调用，无需注册：
curl -X POST https://api.signalfuse.co/v1/credits/trial \
-H "Content-Type: application/json" \
-d '{"wallet":"YOUR_ETH_ADDRESS"}'在工具调用中传递返回的 credit_token。
批量积分 — 入门包（500 次调用）和专业包（5,000 次调用）可在 signalfuse.co 获取。
SignalFuse 提供数据融合 API，而非财务建议。信号是数学合成数据，可能存在错误。交易风险自负。
MIT
Check remaining credits for a prepaid credit token. Returns wallet, credits_remaining, and pack info.
| Name | Required | Description | Default |
|---|---|---|---|
| credit_token | Yes | Credit token to check balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers the return values ('wallet, credits_remaining, and pack info') and implies a read-only operation, adding useful transparency beyond the bare minimum.
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 packs the purpose, action, and output details without any wasted words, fitting the tool's simplicity.
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 is adequate for a simple balance check with one parameter, but it lacks details on token validity, error handling, or auth requirements, which could be important for correct invocation.
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% (parameter has description), and the tool description adds context about the output fields, which helps the agent understand the parameter's effect even without an output 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 action 'Check remaining credits' and the target resource 'prepaid credit token', distinguishing it from sibling data-fetching tools like get_signal or get_pricing.
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 alternatives are mentioned, but the tool's purpose is narrowly defined for credit balance checking, which is implied. Siblings are sufficiently different, reducing ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute code in a sandboxed E2B environment. Supports Python (default) and JavaScript. Max 60s timeout. Paid endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code to execute | |
| language | No | Programming language (python or javascript) | |
| timeout | No | Execution timeout in seconds (max 60) | |
| credit_token | No | Credit token for authentication (optional if using x402) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description covers sandboxed environment, max timeout, and paid endpoint. Could mention side effects like file system access or network restrictions, but sandbox implies isolation.
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?
Three sentences with no redundancy. Every sentence provides essential information.
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?
Tool is simple; description covers key aspects. No output schema, but return value is implied. Could mention error handling or output format, but overall adequate.
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 covers all parameters (100% coverage). Description adds 'Python (default)' and 'Max 60s timeout', which are already in schema, and 'Paid endpoint' which is global context.
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 it executes code in a sandboxed E2B environment, supports Python and JavaScript, with max timeout and paid endpoint. Easily distinguishable from sibling tools.
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 statements, but the sibling tools are all different (non-execution), making context clear. Lacks any usage constraints or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Strategy Arena leaderboard. Returns an array of strategies with wins, losses, total_pnl_bp, win_rate, and total_income_usd. Free endpoint.
| 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; only mentions 'free endpoint' but does not disclose potential rate limits, authentication needs, or side effects beyond being a read operation.
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 concise sentences that convey the tool's purpose and return fields without any unnecessary text.
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 tool with no parameters and no output schema, the description lists all relevant return fields; it is sufficiently complete, though it omits data types or formatting 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 in schema (0 params) so baseline is 4; description adds no additional parameter meaning 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?
Clearly states it retrieves the Strategy Arena leaderboard, specifies the returned fields (wins, losses, etc.), and distinguishes from sibling tools like get_arena_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?
No explicit guidance on when to use this tool versus alternatives; mentions 'free endpoint' but lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a signal from a specific Strategy Arena strategy for a given asset. Returns direction, score, and confidence. Paid endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_id | Yes | Strategy identifier. One of: rsi_7_extremes, ema_5_breakout, bb_squeeze, rsi_reversion_swing, vwap_reversion | |
| symbol | Yes | Asset ticker, e.g. BTC, ETH, SOL | |
| credit_token | No | Optional credit token for bulk-prepaid access |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description discloses that it is a paid endpoint (cost consideration) and returns specific data fields. No mention of side effects or rate limits, but for a read-only operation this is sufficient.
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. First sentence states purpose, second adds output and cost info. Efficient and well-structured.
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 covers purpose, output, and cost, but lacks details on output format (types, ranges) or common usage patterns. For a simple tool this is nearly complete, but a note about output structure would help.
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 clear descriptions for each parameter. The description adds no additional meaning beyond restating required fields and optional credit token, so 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 the tool gets a signal from a specific Strategy Arena strategy for a given asset, and specifies it returns direction, score, and confidence. This distinguishes it from siblings like get_signal and get_signal_batch, which likely cover different scopes.
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 it's a paid endpoint, implying cost awareness, but does not explicitly state when to use this tool over siblings like get_signal or get_signal_batch. Usage context is implied by the name but not formalized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pricing info for all SignalFuse API endpoints. Free endpoint.
| 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. The single behavioral trait mentioned is 'Free endpoint', but it lacks details on data freshness, availability guarantees, or any limitations beyond cost.
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 short sentences with zero wasted words. It is front-loaded and efficient, earning every word.
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?
Despite low complexity, the description does not mention return format or structure, which is missing given no output schema. For a tool that returns pricing info, the description should clarify what the output contains.
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 schema description coverage is 100%, so baseline is 4. The description adds no param details, which is acceptable since none exist.
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 explicitly states 'Get pricing info for all SignalFuse API endpoints', clearly indicating the verb 'get' and the resource 'pricing info'. It distinguishes from siblings like get_sentiment or check_balance by specifying a unique subject.
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 no guidance on when to use this tool versus alternatives. It does not explain prerequisites, when not to use it, or compare with siblings like get_signal or check_balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current macro risk regime — risk_on, risk_off, or neutral. Useful for position sizing and directional bias.
| Name | Required | Description | Default |
|---|---|---|---|
| credit_token | No | Optional credit token for bulk-prepaid access |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only mentions the output values but does not disclose whether the operation is read-only, any authentication requirements, rate limits, or 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?
Two short sentences, front-loaded with the core purpose. No unnecessary words, 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 tool has only one optional parameter and no output schema. The description lists the possible return values, which is sufficient for a simple get tool, though it could explicitly note the return type (string).
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% as the sole parameter (credit_token) has a description in the schema. The description does not add additional meaning beyond the schema, so 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 the tool gets the current macro risk regime and lists the three possible values (risk_on, risk_off, neutral). It distinguishes itself from sibling tools like get_sentiment and get_signal by specifying a unique resource.
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 context for using the tool: 'Useful for position sizing and directional bias.' It does not specify alternatives or when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get raw social sentiment breakdown for a crypto asset.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Asset ticker | |
| credit_token | No | Optional credit token for bulk-prepaid access |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It says 'raw' but does not explain what that implies (e.g., real-time, historical, aggregation). No mention of rate limits, data freshness, or required permissions.
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 sentence of 6 words, highly concise. It fronts the key action and resource. However, it sacrifices necessary detail for brevity, but structure is good.
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 tool with 2 typed parameters and no output schema, the description is fairly complete in saying what it returns (sentiment breakdown), but lacks specification of the output structure or data source, leaving the agent somewhat uninformed.
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 documents both parameters. The description does not add extra meaning beyond the field labels, so 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 the verb 'get', the resource 'raw social sentiment breakdown', and the scope 'for a crypto asset'. It distinguishes from sibling tools like get_signal, get_regime, etc., which cover different data types.
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_signal or get_arena_signal. The description does not mention prerequisites, typical use cases, 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.
Get composite trading signal for a crypto asset. Returns sentiment, macro regime (risk_on/risk_off), funding rate bias, OI delta, signal strength (0-100), confidence, and direction (long/short/neutral). Powered by SignalFuse.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Asset ticker, e.g. BTC, ETH, SOL, DOGE, PEPE | |
| credit_token | No | Optional credit token for bulk-prepaid access |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It describes the output fields well but omits important details like authentication requirements, rate limits, idempotency, or implications of the optional credit_token parameter. The behavior is partially transparent, but gaps remain.
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 sentence that immediately states the tool's function, followed by a compact list of return fields and a source credit. No unnecessary words, and all information is front-loaded.
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 compensates by listing all return fields. However, it lacks information on error handling, usage of credit_token beyond prepaid access, and does not mention the batch sibling for multiple symbols. It is adequate but not fully complete for an agent to use without additional context.
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 both parameters described. The main description adds value by listing example tickers and clarifying the credit_token's purpose ('bulk-prepaid access'). This enriches the schema information, justifying a score above baseline.
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 a composite trading signal for a crypto asset, listing all components (sentiment, macro regime, funding rate bias, etc.). It distinguishes itself from sibling tools like get_sentiment and get_regime by emphasizing its composite nature.
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 no guidance on when to use this tool versus alternatives like get_sentiment, get_regime, or get_signal_batch. It does not specify any prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fused signals for multiple assets at once. Pass comma-separated symbols or omit for all supported assets.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | No | Comma-separated tickers, e.g. BTC,ETH,SOL. Omit for all. | |
| credit_token | No | Optional credit token for bulk-prepaid access |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'Get fused signals', indicating a read operation but lacks details on side effects, authentication needs, rate limits, or any behavioral traits beyond the basic purpose.
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 concise sentences, front-loaded with the tool's purpose. No wasted words; 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?
Tool has 2 simple parameters and no output schema. Description does not explain return values (e.g., format of signals) or mention any constraints like pagination. While adequate for basic use, it lacks completeness about what the agent can expect as output.
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% and both parameters have clear descriptions in the schema (e.g., 'Comma-separated tickers'). The description adds no additional meaning beyond what the schema provides, earning a baseline 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?
Description clearly states 'Get fused signals for multiple assets at once', specifying verb, resource, and scope. This distinguishes it from sibling 'get_signal' which likely handles single assets.
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?
Provides specific guidance: 'Pass comma-separated symbols or omit for all supported assets'. Clearly tells when to use with symbols vs omit. However, it does not explicitly mention when to use alternative tools like get_signal for individual assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using Brave Search via SignalFuse gateway. Paid endpoint (x402). Returns Brave search results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| count | No | Number of results to return (default 10) | |
| credit_token | No | Optional credit token for bulk-prepaid access |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source. It discloses the paid nature (x402) and that it returns Brave results, but lacks details on rate limits, authentication, or cost specifics. Adequate but not comprehensive.
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?
Three sentences, no redundant words, front-loaded with purpose. Every sentence earns its place. Efficient and clear.
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 exists, so the description should explain return format or behaviors. It only says 'Returns Brave search results,' which is vague for a paid tool. Could specify structure or error handling. Adequate for simple search but incomplete for production use.
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 baseline is 3. The description does not add significant meaning beyond the schema fields; it only adds context about payment. Meets minimum but adds little value.
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 searches the web using Brave Search via SignalFuse gateway, distinguishing it from sibling tools like search_tavily (different engine). It also notes it's a paid endpoint.
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?
It mentions the tool is a paid endpoint but does not provide guidance on when to use it versus alternatives (e.g., search_tavily) or when not to use it. Context is implied but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using Tavily via SignalFuse gateway. Paid endpoint (x402). Returns Tavily search results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| search_depth | No | Search depth: "basic" or "advanced" | |
| max_results | No | Maximum number of results to return | |
| credit_token | No | Optional credit token for bulk-prepaid access |
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 only discloses that the endpoint is paid (x402) but does not mention rate limits, auth requirements, or what happens if credits run out. Minimal behavioral insight.
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 description is concise and front-loaded with the core action, meeting conciseness standards perfectly.
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 and no annotations, the description is insufficient. It does not explain the format of 'Tavily search results', pagination, errors, or limitations. A web search tool should provide more context.
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 baseline is 3. The description adds no additional meaning beyond what the schema provides; parameters like query, search_depth, max_results, and credit_token are not elaborated upon.
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 searches the web using Tavily via SignalFuse gateway and mentions it is a paid endpoint. However, it does not differentiate from the sibling tool 'search_brave', which serves a similar purpose.
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 the tool is a paid endpoint but provides no guidance on when to use it versus alternatives like search_brave. Lacks explicit context on use cases 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.
v1.1.2check_balanceexecute_codeget_arena_leaderboardget_arena_signalget_pricingsearch_bravesearch_tavilyv1.0.5get_regimeget_sentimentget_signalget_signal_batchScored across 11 tools
Most tools have distinct purposes, but search_brave and search_tavily are functionally identical (web search via different providers), causing potential confusion. Similarly, get_sentiment and get_signal overlap since sentiment is part of the signal, though descriptions clarify their roles.
All tool names follow a consistent verb_noun pattern with lowercase underscores (e.g., get_signal, search_brave, execute_code). There is no mixing of conventions or confusing abbreviations.
With 11 tools covering signals, arena, pricing, and web search, the count is reasonable for a specialized API. It is slightly on the higher side but each tool serves a clear purpose, and the set feels well-scoped.
The tool set covers core signal retrieval (single, batch, arena), sentiment, regime, and pricing. Missing features like historical data or account management are minor gaps given the stated purpose of providing real-time signals and analytics.
Pay-per-call trading intelligence for AI agents: live market regime, trading signals, composite conv
Unified financial infrastructure connecting AI agents directly to trade live/demo brokerage accounts, Web3 non-custodial wallets, real-time market data across equities, ETFs, crypto, forex, options, DeFi swaps, and prediction markets, institutional research feeds, and algorithmic strategy backtesters.
Market intelligence for AI agents. Real-time data, cross-market analysis, and regime detection.
Live crypto + IDX stock market intelligence for AI agents — 19 tools, no API key.
