commodity-signal
Server Details
Commodity futures bottom/top signals: 28 futures, verdict + score, scans. Pay-per-call x402.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 5 of 5 tools scored. Lowest: 3.6/5.
Each tool has a clearly distinct purpose: pitch for onboarding, rate for feedback, evaluate_symbol for single symbol analysis, scan_bottoms and scan_tops for aggregate market scans. There is no overlap or ambiguity.
Names mix single-word verbs (pitch, rate) with verb_noun patterns (evaluate_symbol, scan_bottoms, scan_tops). While still readable, the lack of a uniform naming convention causes minor inconsistency.
With exactly 5 tools, the server is well-scoped for its purpose: onboarding, single-symbol evaluation, two complementary scans, and feedback. No tool feels unnecessary or missing.
The tool set covers the full workflow: subscribe via pitch, analyze any symbol, scan the whole complex for bottoms/tops, and provide feedback. No obvious gaps are present for the stated purpose.
Available Tools
6 toolsevaluate_symbolAInspect
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). Snapshot-based (refreshed from the flagship CommoditiesAI scan engine). Informational only. PAY: $0.01 per call via x402 (USDT on X Layer) — your FIRST paid call opens a 6-day trial at that price. 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 and adds the per-indicator breakdown behind the score.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Yahoo continuous-futures ticker, e.g. GC=F, CL=F, ZC=F |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses snapshot-based refresh from CommoditiesAI engine, informational status, payment model, and trial. Lacks rate limit or error handling details, but is otherwise thorough.
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 with core purpose, then adds payment and differentiation details. Somewhat lengthy but well-structured; every sentence adds value. Could slightly trim the payment explanation.
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 purpose, symbol scope, payment process, and output format (zone and score range). Missing explicit error handling or response structure details, but sufficient for a simple parameterized 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?
Single parameter 'symbol' with 100% schema coverage. Description adds value beyond schema by listing example tickers across commodity categories, providing context for the parameter's domain.
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 bottom/top verdict for commodity futures, with explicit examples (e.g., GC=F, CL=F) and explanation of zone and score. It distinguishes from the sibling 'pitch' tool, which is free but limited to a showcase symbol.
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 explicit guidance: use this tool for any symbol vs. pitch for showcase only. Details payment flow (402 challenge, trial) and mentions 'informational only', setting expectations for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pitchAInspect
START HERE — your first call to this agent MUST be pitch (free, no payment). 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the phased flow and free nature, but doesn't mention safety, idempotency, or side effects beyond the funnel.
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 packed with essential guidance (START HERE, free, phases, bow out). Front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers entry point, phases, and symbol constraints well. Missing return value or error behavior, but for a funnel intro tool this is acceptable.
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 only 33% (symbol). Description explains the phase sequence, the special rule for symbol (only GC=F for sample), and interest used to bow out. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is the mandatory first call, describes the subscription funnel with phases, and distinguishes from siblings like evaluate_symbol.
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 says 'first call to this agent MUST be pitch' and how to exit with interest:false. Also directs non-GC=F symbols to evaluate_symbol, providing an alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rateAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions the tool is free and requires no payment, which is transparent. However, it omits details about whether ratings are stored, if they can be edited, or any side effects. The description is somewhat transparent but lacks depth for a complete behavioral picture.
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 conveys all essential information without any wasted words. It is front-loaded with key identifiers ('FREE feedback tool') and uses clear, direct language. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description covers the basic usage scenario. However, it lacks information on what happens after submitting a rating (e.g., confirmation, error handling) and does not address potential questions about recurrence (e.g., can you rate multiple times?). The absence of output schema increases the need for behavioral context, which is only partially met.
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 has no descriptions (0% coverage), so the description must add meaning. It explains that 'score' should be 1-10, and 'pros' and 'cons' are for textual feedback. This provides helpful constraints and semantics beyond the raw schema, though it could specify the expected format of the strings more precisely.
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 is a feedback tool for leaving a rating after trading on signals, specifying the verb 'leave a rating' and the resource 'trading signals'. It identifies the key elements: score 1-10, pros, cons. While it does not explicitly differentiate from sibling tools, the siblings have different purposes (evaluation, pitch, scanning), so the purpose is sufficiently clear.
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 a usage context: 'after trading on our signals'. However, it does not offer explicit guidance on when not to use this tool or how it compares to alternatives like 'evaluate_symbol' or 'pitch'. The absence of exclusions or sibling comparisons leaves the agent with only implied usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_bottomsAInspect
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) — your FIRST paid call opens a 6-day trial at that price. 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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses paid nature, trial, and retry mechanism. No annotations present, so description carries full burden. Does not detail failure behavior but sufficient for a read-only scan.
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 covering purpose, payment, and usage. No redundancy, front-loaded with action and scope. Efficient and focused.
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 adequate given simple schema and no output schema. Could detail return format but still provides sufficient context for agent 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?
Only one parameter 'limit' with schema description already clear (default 5, max 28). Description adds no new meaning beyond schema, so 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?
Description clearly states it scans the commodity complex snapshot (28 futures across metals, energy, agriculture, livestock) and returns commodities at a bottom, ranked most-bottom first. Distinguished from sibling 'scan_tops' and 'pitch' 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?
Explicitly states payment mechanism ($0.01 via x402, first call is trial), no account needed, retry with header, and compares to free 'pitch' tool for count. Provides clear cold-start guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_topsAInspect
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) — your FIRST paid call opens a 6-day trial at that price. 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) |
Tool Definition Quality
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 the paywall behavior, trial, and retry mechanism, and states no account needed. However, it does not describe the output format or data freshness, which would improve 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 concise at about 6 sentences, front-loaded with the main purpose. It packs essential information without excessive verbosity, though some redundancy exists (e.g., 'No account, no signup, no commitment').
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 should hint at return values. It states 'return commodities...' but omits details like which properties are included. It is complete for calling the tool but not for interpreting results.
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 one parameter `limit`. The description adds no extra meaning beyond the schema; it only confirms there is no symbol parameter. The baseline for high schema coverage is 3, and the description does not exceed it.
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 scans the commodity complex snapshot and returns commodities at a top (sell), ranked most-top first. It uses specific verbs and resource, and distinguishes from sibling tools like `pitch` 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?
The description provides explicit guidance on when to use ('BEST COLD START: you do not need to pick a symbol') and mentions an alternative tool (`pitch` tells how many are at a top). It also explains the payment flow, so the agent knows how to handle the 402 challenge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subscribeAInspect
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 (6-day trial from your first paid call). 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. |
Tool Definition Quality
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 activation triggers a 402 challenge requiring signing and retry, and that it returns an X-SUB-KEY token. It also mentions the 6-day trial and per-call cost. However, it does not cover error handling or auth requirements in detail.
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 relatively verbose, containing multiple clauses and nested instructions. It could be more concise while preserving clarity. The structure is logical but not 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?
No output schema exists, so the description should explain return values. It mentions the token for activation but does not specify the status check return format. It covers the main workflow but lacks error handling and edge cases.
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 description adds meaning: 'agentId' links to subscription, 'activate' = true triggers payment challenge. It explains the activation flow, adding context 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 two distinct functions: checking subscription status (no activate) and activating the monthly plan (with activate:true). It specifies the verb 'check' and 'activate' with the resource 'subscription', and the sibling tools are unrelated, so no confusion.
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 explicit instructions for when to use each mode (activate: true for activation, without for status check). It also mentions the alternative of per-call payment ($0.01 each) but does not explicitly list excluded scenarios. Overall, clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!