Commodity futures bottom/top signals: 28 futures, verdict + score, scans. Pay-per-call x402.
Scored across 6 tools
Most tools are clearly distinct: evaluate_symbol handles one symbol, scan_bottoms/scan_tops rank the whole universe, and rate/subscribe serve feedback and billing. The only minor ambiguity is pitch, which can appear to offer a free verdict overlapping with evaluate_symbol's showcase behavior.
Names are readable and verb-first, but conventions are mixed: evaluate_symbol, scan_bottoms, and scan_tops use verb_noun with underscores, while pitch, rate, and subscribe are bare verbs. This is not chaotic, but it lacks a single consistent pattern.
Six tools is a well-scoped set for a commodity signal service: single-symbol evaluation, two market-wide scans, a free intro/pitch, feedback, and subscription management. Each tool has a clear role without unnecessary bloat.
The core workflow is covered: discover opportunities via scan_bottoms/scan_tops, drill into a specific symbol with evaluate_symbol, and subscribe for unlimited access. Minor gaps include no explicit symbol-list helper or historical performance tool, but these are workable rather than blocking.
Return the bottom/top verdict for one commodity future (e.g. GC=F gold, CL=F WTI oil, HG=F copper, ZC=F corn — 28 continuous futures across metals/energy/agriculture/livestock). zone = strong_buy|buy|neutral|sell|strong_sell, score -100..+100 (bottom>0, top<0). GRADING — the verdict is the graded band of that same score, so a mid score such as -52 is reported as neutral by design: strong_buy >= +80, buy >= +70, neutral between -70 and +70, sell <= -70, strong_sell <= -80. Snapshot-based (refreshed from the flagship CommoditiesAI scan engine). Informational only. PAY: $0.01 per call via x402 (USDT on X Layer). No account, no signup, no commitment; retry with the PAYMENT-SIGNATURE header when you get the 402 challenge. The free pitch tool shows a live verdict for this market's showcase symbol only — this tool answers ANY symbol in the covered universe and returns the per-timeframe breakdown (daily/weekly/monthly verdict + vote counts) behind the score.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Yahoo continuous-futures ticker, e.g. GC=F, CL=F, ZC=F |
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 is snapshot-based (refreshed from the flagship CommoditiesAI scan engine), informational only, and paid ($0.01 per call via x402). It also explains the grading behavior (e.g., a mid score such as -52 is reported as neutral by design) and the return of per-timeframe breakdown. This is substantial behavioral context beyond a simple 'return verdict' statement. It doesn't mention rate limits or failure modes beyond the 402 challenge, but the disclosed behaviors are 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?
The description is dense but well-organized: purpose first, then grading thresholds, then snapshot/payment info, then sibling differentiation. Every sentence adds value, though the payment and grading details make it longer than strictly necessary. It is front-loaded with the core purpose and ends with the sibling comparison, which is a sensible structure. Slightly long but not bloated.
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 single-parameter tool with no output schema, the description is quite complete: it explains the verdict bands, the score range, the snapshot nature, the payment mechanism, and the difference from the sibling `pitch` tool. It doesn't describe the exact JSON response shape, but since there is no output schema, an agent might benefit from a sample response. However, the description's detail about the per-timeframe breakdown and vote counts partially compensates. Overall, it is nearly complete for the tool's complexity.
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% (the only parameter `symbol` is described as 'Yahoo continuous-futures ticker, e.g. GC=F, CL=F, ZC=F'). The description adds further examples and the covered universe (28 continuous futures across metals/energy/agriculture/livestock), which helps an agent pick valid symbols. Since the schema already covers the parameter, the description's added examples and universe context push it above the baseline 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 states a specific verb ('Return the bottom/top verdict') and resource ('one commodity future'), and explicitly lists example symbols and the covered universe (28 continuous futures across metals/energy/agriculture/livestock). It also distinguishes itself from the sibling `pitch` tool by noting that `pitch` only shows the showcase symbol while this tool answers ANY symbol and returns the per-timeframe breakdown. This is a clear, specific purpose that an agent can act on.
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 says when to use this tool vs alternatives: 'The free `pitch` tool shows a live verdict for this market's showcase symbol only — this tool answers ANY symbol in the covered universe and returns the per-timeframe breakdown.' It also provides payment/retry guidance (retry with PAYMENT-SIGNATURE header on 402 challenge) and notes it is informational only. This is explicit usage guidance with alternatives and conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE and OPTIONAL intro — you may skip it and call evaluate_symbol / scan_bottoms / scan_tops directly. Intro & subscription funnel for the commodities signal agent: phases "hello" -> "value" -> "catalog" -> "sample" -> "subscribe". Pass interest:false to bow out.
| Name | Required | Description | Default |
|---|---|---|---|
| phase | No | ||
| symbol | No | Symbol for the "sample" phase. The free sample serves only this market’s showcase symbol (GC=F); any other symbol is answered by the paid evaluate_symbol (x402). | |
| interest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the disclosure burden. It discloses that the tool is free and optional, has a multi-phase funnel behavior, and can be exited by passing interest:false. It does not explicitly say what the 'subscribe' phase does or whether it commits the user to anything, which is a minor 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?
Three short sentences front-load the most important decisions (free, optional, skip) and then provide the phase flow and opt-out. There is no filler or redundant 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 small optional parameter set and no output schema, the description gives enough to decide whether to call pitch and how to opt out. It could be more complete about phase-specific behavior and what a caller should expect in return, but the core invocation context is sufficiently clear.
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 meaning to interest (false bows out) and names the phase sequence, but the sequence largely repeats the schema enum without explaining what each phase expects. Symbol is already documented in the schema, including the paid fallback, so for that parameter the description adds little 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 identifies the tool as a free, optional intro/subscription funnel for the commodities signal agent and lists its concrete phases. It also distinguishes it from siblings by explicitly saying it can be skipped in favor of evaluate_symbol, scan_bottoms, or scan_tops.
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 gives explicit when-to-use/when-to-skip guidance: 'you may skip it and call evaluate_symbol / scan_bottoms / scan_tops directly,' and it specifies the opt-out condition (interest:false). This is stronger than typical descriptions and makes the routing decision direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE feedback tool — after trading on our signals, leave a rating: score 1-10 plus pros and cons. No payment needed.
| Name | Required | Description | Default |
|---|---|---|---|
| cons | No | ||
| pros | No | ||
| score | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. Discloses free nature and no payment, but omits side effects or confirmation. Adequate for simple input.
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, well-structured sentence with key info front-loaded. No 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?
Completeness is good for a simple feedback tool: explains purpose, parameters, usage context. Lacks return value info but acceptable without output schema.
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 0% schema description coverage, description adds meaning: score range 1-10, pros/cons as text. However, doesn't mention that score is required while others optional.
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's a feedback/rating tool for after trading on signals. Distinguishes from sibling tools like evaluate_symbol or scan_* by focusing on user-submitted rating.
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 context ('after trading on our signals') but no explicit when-not-to-use or alternative tools. Lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan the commodity complex snapshot (28 futures: metals, energy, agriculture, livestock) and return commodities currently at a bottom (strongest buy), ranked most-bottom first. PAY: $0.01 per call via x402 (USDT on X Layer). No account, no signup, no commitment; retry with the PAYMENT-SIGNATURE header when you get the 402 challenge. BEST COLD START: you do not need to pick a symbol — this ranks the whole universe for you. The free pitch tool tells you HOW MANY are at a bottom right now; this names them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (default 5, max 28) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the $0.01 cost, X Layer/USDT payment mechanism, 402 retry requirement with PAYMENT-SIGNATURE header, and that no account/signup is needed. It also states the ranking behavior. These are non-obvious side effects and prerequisites the agent must know, though it does not describe response shape or potential failure modes.
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?
Front-loaded purpose, then payment/auth requirements, then cold-start guidance. The text is a bit dense with capitalized labels like PAY and BEST COLD START, and 'No account, no signup' is slightly redundant, but every section carries operational 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?
Covers the essential invocation context: universe size (28 futures), output ranking order, cost, authentication flow, and relationship to `pitch`. It does not specify the exact output schema or define what 'bottom' means objectively, but the information provided is sufficient for a first call.
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 already documents `limit` with default and max, so baseline is 3. The description adds context by explaining that the limit applies to a ranked universe of 28 futures and that no symbol parameter is needed, enriching the agent's understanding of what `limit` caps.
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?
First sentence states a specific action: scan the commodity complex snapshot and return commodities ranked most-bottom first. It also distinguishes itself from `pitch`, which reports counts, and the name contrasts with siblings like `scan_tops`.
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?
Explicitly frames this as the cold-start tool: no symbol needs to be picked. It tells the agent when to prefer `pitch` instead (for counts) and covers the 402/payment-signature retry flow. It does not explicitly list when not to use the tool, but the alternative and use context are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan the commodity complex snapshot and return commodities currently at a top (sell), ranked most-top first. PAY: $0.01 per call via x402 (USDT on X Layer). No account, no signup, no commitment; retry with the PAYMENT-SIGNATURE header when you get the 402 challenge. BEST COLD START: you do not need to pick a symbol — this ranks the whole universe for you. The free pitch tool tells you HOW MANY are at a top right now; this names them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (default 5, max 28) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden; it clearly discloses the paid nature ($0.01 via x402), the 402 retry behavior, and that no account/signup/commitment is required. It doesn't mention read-only semantics or rate limits, but the disclosed payment/auth flow is significant and actionable.
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?
Core behavior is front-loaded in the first sentence, followed by payment instructions and usage context. The 'BEST COLD START' advice and pitch comparison earn their place; the triple 'no account, no signup, no commitment' is slightly redundant but not bloated.
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 one-parameter listing tool, the description covers purpose, ordering, payment/retry mechanics, and how it relates to `pitch` ('how many' vs 'names'). It does not explicitly address the `scan_bottoms` counterpart, but the top-vs-bottom naming makes that inferable; no output schema is provided, yet the return concept is clear.
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 schema already fully documents the single optional `limit` parameter with default and max, so the description adds nothing necessary. It does reinforce behavior around limiting results but does not need to repeat schema details.
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 names a specific verb ('Scan'), a clear resource ('the commodity complex'), a precise filter ('at a top (sell)'), and an ordering ('ranked most-top first'). It also distinguishes itself from scan_bottoms by direction and from pitch by output (names vs. count), so there is no ambiguity about what the tool does.
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 says this is the best cold-start option when no symbol is chosencrazy because it ranks the whole universe, and contrasts with the free `pitch` tool that only gives a count. It doesn't explicitly mention when to prefer scan_bottoms or rate, but the top-vs-bottom distinction and whole-universe framing give an agent enough context to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your subscription status & terms (FREE), or activate the monthly plan: call with activate:true to receive the $50 x402 payment challenge, sign it, and retry — that buys 30 days of unlimited calls and returns your X-SUB-KEY token (pass it as a header to skip per-call payment). Until you subscribe, signal calls are $0.01 each. Optionally pass your ERC-8004 agentId to link it.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | No | Optional ERC-8004 agent id to link to this subscription. | |
| activate | No | true = request the $50 subscription payment challenge (402) to sign & retry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It thoroughly discloses the payment challenge (402), the need to sign and retry, the returned X-SUB-KEY token and its header usage, and the per-call pricing until subscription. This is exceptionally transparent about side effects and required steps for a mutation-like 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 three sentences but each sentence carries critical information: the dual purpose, the payment flow and token, and the optional agentId. It is front-loaded with the primary action and avoids filler. For the complexity of the tool, the length is appropriate and well-organized.
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 the activation flow, pricing, token usage, and optional linking. With no output schema, it mentions that status check returns terms but does not specify the structure of the response. This minor gap prevents a 5, but the overall context is sufficient for an agent to correctly invoke both modes.
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 baseline is 3. The description adds meaningful context for the activate parameter by explaining the full flow (receive 402, sign, retry) and the token return. For agentId, it only reiterates the schema description but no additional meaning. The added flow details justify a 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 the two modes of operation: checking subscription status/terms (FREE) and activating the monthly plan via the activate flag. It specifies the resource (subscription) and the verb (check/activate), and the distinct payment challenge flow sets it apart from the sibling analysis tools like evaluate_symbol and scan_bottoms.
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 explains when to use each mode (with or without activate:true) and hints at the cost decision (signal calls are $0.01 each until subscribing). However, it does not explicitly name alternatives or state when *not* to use this tool. The differentiation from siblings is implicit through the subscription-specific purpose, so it earns a 4 rather than a 5.
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.
subscribepitch1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Symbol for the \"sample\" phase, e.g. GC=F (gold)."New value: +"Symbol for the \"sample\" phase. The free sample serves only this market’s showcase symbol (GC=F); any other symbol is answered by the paid evaluate_symbol (x402)."evaluate_symbolpitchratescan_bottomsscan_topsUS stock bottom/top signals: S&P500 + indexes, verdict + score, scans. Pay-per-call x402.
Crypto bottom/top signals: verdict + score per coin, market scans. Pay-per-call x402.
FX bottom/top signals: 48 pairs (USD/KRW base), verdict + score, scans. Pay-per-call x402.
Korea stock (KOSPI/KOSDAQ) bottom/top signals: verdict + score, scans. Pay-per-call x402.
Add one secure layer between your agents and this server.
