Integrates Binance on-chain data to provide order flow analysis (24h delta) for BTC, ETH, and SOL trading signals.
AI-consensus market oracle for autonomous agents. 27 live data feeds. BUY/SELL/HOLD signals with confidence scores, Polymarket edges, Fear & Greed, congressional trading, on-chain order flow, and macro regime — all in one MCP tool call.
Smithery: octodamusai/market-intelligence API: api.octodamus.com X: @octodamusai
Tool | Description | Auth |
| BUY/SELL/HOLD + confidence + Fear & Greed + BTC price + Polymarket edges | Free |
| One-paragraph oracle read across all assets + macro. Drop into any LLM system prompt. | Free |
| Prediction market opportunities with EV, true probability, Kelly sizing | Free |
| AI sentiment score per asset (-1.0 bearish to +1.0 bullish) | Free (BTC) |
| Live prices with 24h change for BTC, ETH, SOL (+ stocks with key) | Free |
| Raw 11-signal consensus votes — RSI, MACD, funding rate, L/S ratio, taker flow, whale moves | API key |
| All 27 live data feeds with update frequencies | Free |
| Everything in one call — signal + edges + sentiment + prices + brief | API key |
Related MCP server: cryptoiz-mcp
Add to your MCP config:
{
"mcpServers": {
"octodamus": {
"url": "https://api.octodamus.com/mcp",
"config": {
"apiKey": ""
}
}
}
}Leave apiKey blank for free tools (500 req/day). Get a free key: POST https://api.octodamus.com/v1/signup?email=you@example.com
npx @smithery/cli install octodamusai/market-intelligence{
"action": "BUY",
"confidence": "high",
"signal": {"asset": "BTC", "direction": "LONG", "timeframe": "1W"},
"fear_greed": {"value": 17, "label": "Extreme Fear"},
"btc": {"price_usd": 81385, "change_24h": 2.64, "trend": "UP"},
"polymarket_edge": [
{"question": "BTC above $90k by June?", "side": "YES", "ev": 0.22, "confidence": "high"}
],
"reasoning": "Extreme fear + LONG signal + macro dip = accumulation zone.",
"track_record": {"wins": 5, "losses": 6, "total": 11}
}Plan | Price | Limit |
Free | $0 | 500 req/day |
Pay-per-call | $0.01 USDC/call | Unlimited — x402 on Base, no account needed |
Annual | $29/year | 10k req/day |
x402 payments: Base chain (eip155:8453), USDC. No account or credit card required — just a funded Base wallet.
Signup: POST https://api.octodamus.com/v1/signup?email=your@email.com
Crypto: BTC, ETH, SOL
Stocks: NVDA, TSLA, AAPL, MSFT, SPY (+ tokenized versions on Base via Dinari)
Macro: FRED yield curve, DXY, VIX, M2, Fed probability (CME FedWatch)
On-chain: Binance 24h delta, Base DEX flow, whale wallet moves
Sentiment: Grok/X crowd sentiment with contrarian divergence flags (BULL_TRAP/BEAR_TRAP)
Congressional: Finance Committee insider trading on mega-cap stocks (QuiverQuant)
Prediction markets: Polymarket edges with EV and Kelly sizing
All premium responses are signed with Octodamus's Ed25519 key for on-chain verification. The public key is published at https://api.octodamus.com/.well-known/x402.json under signing.
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
import base64, json
response = ... # API response dict
pubkey_b64 = response["signer_pubkey"]
sig_b64 = response["signature"]
payload = {k: v for k, v in response.items() if k not in ("signature", "signer_pubkey")}
canonical = json.dumps(payload, sort_keys=True, separators=(",", ":")).encode()
key = Ed25519PublicKey.from_public_bytes(base64.b64decode(pubkey_b64))
key.verify(base64.b64decode(sig_b64), canonical) # raises if invalid14 offerings available for agent-to-agent commerce via Virtuals ACP ($1.00-$2.00 USDC/job):
Market Signal (BTC/ETH/SOL) $1.00
Grok Sentiment Brief $1.00
Fear vs Crowd Divergence $2.00
BTC Bull Trap Monitor $1.50
Overnight Asia Brief $2.00
Tokenized Stock Signal (AAPL/MSFT/SPY on Base) $1.00
MacroMind Brief $1.00 | StockOracle Brief $1.00
Order ChainFlow Brief $1.00 | X Sentiment Brief $1.00
Discovery: GET https://api.octodamus.com/.well-known/acp.json
MIT — see LICENSE
Ask the Octodamus oracle for a probability estimate on any yes/no market question. Returns an estimated probability, key factors for each side, and oracle reasoning. Works for crypto, macro, and Polymarket-style questions.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | A yes/no market question, e.g. Will BTC hit 100k by end of 2026? |
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool returns an estimated probability, key factors, and reasoning, which is sufficient for a read-only query tool. It does not disclose rate limits or auth, but those are not critical for this simple tool.
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 long, each sentence adding essential information: the action and return values in the first, the domains in the second. No wasted 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?
With an output schema present (not shown), the description complements it by listing key return fields. For a single-parameter tool, the description fully informs about usage and return values. No gaps remain.
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 input schema has one parameter 'question' with 100% description coverage. The description adds value by specifying the expected format ('a yes/no market question') and providing an example, which aids correct usage 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 it asks an oracle for a probability estimate on yes/no market questions, lists return fields (estimated probability, key factors, reasoning), and specifies applicable domains (crypto, macro, Polymarket). It is distinct from sibling tools like get_market_brief or get_market_sentiment.
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 clear context: it works for yes/no market questions and gives example domains. However, it does not explicitly state when to avoid this tool or compare it to siblings, though the sibling names imply different scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get active Polymarket trade calls with EV, Kelly-sized position, and oracle reasoning. Each call includes the market question, YES/NO side, edge percentage, recommended size, and why Octodamus placed the call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not indicate whether this is a read-only operation or if any side effects occur. The description only lists output fields, missing necessary behavioral context like data freshness or authentication 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?
The description consists of two well-structured sentences. The first sentence states the primary action and key outputs, and the second adds detail. No wasted words or 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?
The tool has no parameters and an output schema, reducing the burden on the description. It adequately explains what the tool returns (active calls with specific fields). It could mention potential limitations like pagination or data freshness, but overall it is sufficiently complete for this simple 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 input schema has zero parameters, so schema description coverage is 100% by default. The description does not need to add parameter info, and the baseline for no parameters is 4. It adds value by describing the output content, compensating for the absent parameter documentation.
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 active Polymarket trade calls and enumerates specific fields (EV, Kelly-sized position, oracle reasoning). This distinguishes it from sibling tools like get_market_brief or get_signal, which serve different purposes.
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 clear context that this tool is for getting active calls, implying when it should be used. It does not explicitly state when not to use it or mention alternatives, but the purpose is unambiguous enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Octodamus identity and capabilities: what the oracle covers, which assets it tracks, how to access the API (free tier and x402 micropayments on Base), and links to the MCP server, X account, and API documentation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly describes the returned information (identity, capabilities, assets, API details, links) without contradicting any implicit side effects. It is transparent about the tool's nature.
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 front-loads key information. While somewhat lengthy, every part adds value, making it appropriately concise for the content.
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 an existing output schema (not shown), the description provides sufficient context by enumerating the types of information returned. It is complete enough for an AI agent to understand the tool's purpose and 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?
The input schema has no parameters, so the description does not need to add parameter-level detail. It adds context by specifying what the output covers, which is 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 returns identity and capabilities of Octodamus, including coverage, assets, API access, and links. It effectively distinguishes itself from sibling tools by being a meta-discovery tool.
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 should be used first to understand the oracle's capabilities, but does not explicitly state when not to use it or mention alternatives. The context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full AI market brief synthesizing all 27 live signals. Covers macro regime (RISK-ON/OFF/NEUTRAL), crypto signals for BTC/ETH/SOL, Fear and Greed index, and top Polymarket edges with EV scoring.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description carries full burden. It honestly describes the brief's content (macro regime, crypto signals, etc.) with no hidden side effects. However, it does not disclose potential costs or rate limits, which would be helpful for a synthesizing tool.
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 main purpose then details. No filler or redundancy; 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?
Given tool complexity (27 signals, multiple data types), description covers all major components concisely. Output schema exists to detail return structure, so description's job is 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?
Input schema has zero parameters with 100% description coverage, so baseline is 4. Description effectively conveys what the tool returns, which is the only relevant semantics for a parameterless tool.
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's purpose: get a full AI market brief synthesizing all 27 live signals. It lists specific components (macro regime, crypto signals, Fear & Greed, Polymarket edges) which distinguishes it from siblings like get_market_sentiment or get_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?
Implies usage for comprehensive market overview due to wording 'full AI market brief', but does not explicitly state when to use versus alternatives like get_market_sentiment. No exclusion or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current market sentiment indicators: Fear and Greed index (0-100), BTC/ETH/SOL funding rates (positive = longs paying, negative = shorts paying), and long/short ratios showing crowd positioning.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden and explains the returned metrics well (index range, funding rate interpretation, crowd positioning). However, it does not mention that this is a read-only operation or any potential rate limits or data freshness, which would enhance transparency.
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 efficiently summarizes the tool's output. It could benefit from slight structural improvements (e.g., bullet points), but it is front-loaded and wastes no 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 simplicity (no parameters) and the presence of an output schema, the description fully explains the return values—defining the Fear and Greed index range, funding rate sign meaning, and long/short ratios. This covers all necessary context for an agent to use the tool 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 no parameters, and schema description coverage is 100% (vacuously). According to the rule for 0 parameters, baseline is 4. The description does not need to add param info, and it correctly focuses on the output.
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 market sentiment indicators, explicitly listing the Fear and Greed index, funding rates for BTC/ETH/SOL, and long/short ratios. This verb+resource combination is specific and distinguishes it from sibling tools like get_market_brief and get_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 usage for obtaining sentiment data but does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_market_brief for a broader overview, get_signal for trading signals). No exclusions or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest crypto and macro news headlines Octodamus is monitoring. Includes market-moving events, Fed decisions, on-chain developments, and regulatory news relevant to BTC, ETH, SOL, and tokenized equities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
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 the type of news (crypto, macro) but does not mention update frequency, rate limits, or any behavioral traits beyond 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 clear, front-loaded sentences with no unnecessary words. Every sentence adds specific 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 no parameters and an output schema exists, the description is fairly complete, covering what the tool fetches. It could additionally hint at the output format, but the output schema likely covers that.
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%. The description adds value by specifying the content scope beyond the empty schema, earning a baseline 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?
The description clearly states 'Get the latest crypto and macro news headlines' and lists specific topics and assets, making it distinct from sibling tools like get_market_brief or get_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?
Usage is implied by the description (for news headlines), but no explicit guidance on when to use this versus alternatives like get_market_brief or get_signal is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a live BUY/SELL/HOLD signal for a crypto asset. Returns consensus signal, confidence score, Fear and Greed index, current price, and oracle reasoning from 11 signals. Supported assets: BTC, ETH, SOL.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Crypto asset symbol: BTC, ETH, or SOL. Defaults to BTC. | BTC |
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It mentions 'live signal' implying real-time data and lists return fields, but does not explicitly state it is a read-only operation or disclose any side effects, rate limits, or data freshness. The output schema likely covers return structure, but behavioral traits are minimally described.
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, efficient and front-loaded. Every sentence adds value without 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?
For a tool with one optional parameter and an output schema, the description is nearly complete. It covers purpose, output, and supported assets. Minor improvement would be to note that it is read-only, but not essential.
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 description adds no new information beyond the input schema, which already covers the 'asset' parameter with values BTC, ETH, SOL. Schema coverage is 100%, so the default score is 3. The description does not provide additional semantic meaning.
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 live BUY/SELL/HOLD signal and lists the output fields and supported assets. However, it does not explicitly differentiate from sibling tools like get_market_brief or get_market_sentiment, but the specific output (consensus signal, confidence score) makes it distinct enough.
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 such as get_market_sentiment or ask_oracle. The description lacks context about its appropriate application, e.g., for trading decisions or real-time analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Octodamus oracle track record: total calls placed, win rate percentage, cumulative P&L, Sharpe ratio, and the best/worst individual calls. All calls are timestamped and publicly verifiable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states calls are timestamped and publicly verifiable, adding useful context. However, it does not disclose whether the operation is read-only, requires authentication, or has rate limits.
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 key metrics plus a second sentence on verifiability. No unnecessary words; front-loads 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?
Zero parameters make this tool simple. An output schema exists, and the description lists all major return fields. For a read-only tracking tool, this is comprehensive.
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?
Input schema has zero parameters and is fully covered (100%). With no params, the description's addition of the returned metrics adds value without needing parameter details. Baseline 4 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 retrieves the Octodamus oracle track record and lists specific metrics (total calls, win rate, P&L, Sharpe ratio, best/worst calls). This distinguishes it from siblings like ask_oracle (makes predictions) or get_active_calls (current open calls).
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 usage for viewing historical performance but does not explicitly state when to use this tool over alternatives (e.g., use for assessing reliability, not for current signal). No exclusions or scenarios provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe an email address to the Octodamus Market Intelligence Digest. Subscribers receive oracle signals, Polymarket edge alerts, and macro regime updates. Confirms subscription with a welcome message.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Valid email address to subscribe, e.g. trader@example.com |
| Name | Required | Description |
|---|---|---|
| result | Yes | Oracle response text with signal data, analysis, or confirmation |
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 states the subscription confirmation via welcome message but lacks details on error handling, duplicate subscriptions, or data usage. Adequate for a simple subscription but could be more explicit.
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, front-loaded with the core action, no redundant 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?
Given the simple single-parameter tool with an output schema, the description covers the purpose, content of subscription, and confirmation. No missing context needed 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 description coverage is 100% with a clear example. The tool description does not add extra meaning beyond the schema's parameter description, meeting baseline expectation.
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 (subscribe an email address) and the resource (Octodamus Market Intelligence Digest), and distinguishes from sibling tools like 'ask_oracle' or 'get_market_brief' which are not subscription-related.
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 usage context (when wanting to subscribe to the digest) but does not specify when not to use it, prerequisites, or alternatives. However, no sibling tool offers a similar function, so ambiguity is minimal.
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.
ask_oracle2 fields changedInput schema / properties / question / descriptionAdded value: +"A yes/no market question, e.g. Will BTC hit 100k by end of 2026?"Output schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"get_active_calls1 field changedOutput schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"get_identity1 field changedOutput schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"get_market_brief1 field changedOutput schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"get_market_sentiment1 field changedOutput schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"get_news1 field changedOutput schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"get_signal2 fields changedInput schema / properties / asset / descriptionAdded value: +"Crypto asset symbol: BTC, ETH, or SOL. Defaults to BTC."Output schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"get_track_record1 field changedOutput schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"subscribe_to_octodamus2 fields changedInput schema / properties / email / descriptionAdded value: +"Valid email address to subscribe, e.g. trader@example.com"Output schema / properties / result / descriptionAdded value: +"Oracle response text with signal data, analysis, or confirmation"v1.0.0ask_oracleget_active_callsget_identityget_market_briefget_market_sentimentget_newsget_signalget_track_recordsubscribe_to_octodamusScored across 9 tools
Each tool targets a distinct aspect of market intelligence: probability estimates, trade calls, identity, market brief, sentiment, news, signals, track record, and subscription. No two tools serve overlapping purposes.
All tool names follow a consistent verb_noun pattern using snake_case (ask_, get_, subscribe_). The naming is predictable and easy to understand.
9 tools is well-scoped for the domain of market intelligence. Each tool provides a necessary function without being overwhelming or sparse.
The set covers core oracle, market data, signals, and subscription features. A minor gap is the absence of an unsubscribe tool, but agents can manage via external channels.
Pay-per-call crypto market intelligence for AI agents. USDC on Base via x402.
Verifiable crypto signals, recorded history and always-on monitoring for AI agents via x402 on Base.
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
AI-native settlement rail + intelligence oracle for autonomous agents. x402, Base mainnet, 81 tools.
