Commodity futures bottom/top signals: 28 futures, verdict + score, scans. Pay-per-call x402.
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.
Average 4.3/5 across 6 of 6 tools scored.
Each tool has a uniquely identifiable purpose: evaluate_symbol for single-symbol verdicts, pitch for onboarding, rate for feedback, scan_bottoms and scan_tops for universe scans, and subscribe for subscription management. No two tools overlap in functionality.
Most tools follow a verb_noun pattern (evaluate_symbol, scan_bottoms, scan_tops), but three are single verbs (pitch, rate, subscribe). The pattern is mostly consistent and readable, with only minor deviations.
With 6 tools, the set covers all essential actions: introduction, single-symbol analysis, universe scanning (bottoms/tops), subscription, and feedback. This is well-scoped for the commodity signal domain.
The tool surface covers the core workflow (intro, evaluation, scanning, subscription, feedback). Minor gaps exist, such as a way to filter or request additional symbol details beyond the verdict, but the essential CRUD-like lifecycle is present.
evaluate_symbolAInspectReturn 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool is snapshot-based, informational only, and involves payment with a trial. It does not explicitly state read-only or idempotent behavior, but the informational nature implies no side effects. Some gaps in rate limits or latency remain, but overall adequately transparent.
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 moderately sized with a clear structure: purpose and examples first, then output format, then behavior (snapshot/informational), then payment details, and finally comparison with pitch. Each sentence adds meaningful information, though slightly verbose in parts.
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 (one parameter, no output schema) and complexity (paid call with 402 handling), the description covers the output (zone and score), behavior (snapshot, informational), payment model, and distinction from pitch. It does not address error handling for invalid symbols, but overall it is sufficiently complete for an agent to use the tool correctly.
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 already described. The description adds value by providing concrete examples (e.g., GC=F, CL=F) and explaining the domain (28 continuous futures across categories). This helps the agent understand acceptable inputs beyond the schema's generic description.
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 specifies the verb 'Return', the resource 'bottom/top verdict for one commodity future', and the output format including zone and score range. It distinguishes from the sibling tool 'pitch' by noting that this tool answers any symbol while pitch is 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?
The description explicitly states when to use this tool (for any symbol) versus the free 'pitch' tool (only showcase symbol). It also provides guidance on the payment model, the 402 challenge, and the need for a PAYMENT-SIGNATURE header, covering both usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pitchAInspectSTART 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the funnel phases, free nature, and exit mechanism. It does not detail side effects or data persistence, but the funnel is inherently interactive and low-risk, making this 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?
Extremely concise (two sentences) yet packs all essential info. Front-loaded with 'START HERE' as a clear directive. 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?
The description covers the tool's purpose, phases, and key parameters. No output schema is present, but the funnel phases imply a conversational flow. Lacking explicit details on what each phase returns, but likely sufficient for an agent to navigate. Minor gap: no mention of error handling or unexpected inputs.
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% (only symbol described), but the description adds rich semantics: explains phase enum values, specifies that symbol works only for GC=F in the sample phase, and clarifies interest:false exits the funnel. This fully compensates for the schema gaps.
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 this as the entry point funnel for the commodities signal agent, with a specific verb ('pitch') and resource (subscription funnel). It distinguishes from siblings by referencing evaluate_symbol for the sample phase and explicitly stating this is the first call.
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 the tool must be the first call and provides guidance for exiting (interest:false). It does not explicitly list when not to use it, but the funnel context implies alternative tools are for later steps. Could be improved with a 'when to use' vs 'when not to use' distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rateAInspectFREE 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?
With no annotations, the description carries full burden. It adds 'FREE' and 'No payment needed', which are useful behavioral traits. However, it does not disclose whether ratings are public, reversible, or have side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key phrase 'FREE feedback tool' and efficiently covers purpose, usage, and parameter details without 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?
For a simple tool with no output schema, the description covers purpose, usage timing, and parameter semantics adequately. It does not explain what happens after rating submission (e.g., confirmation), but that is minor.
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 directly explains all parameters: 'score 1-10' (constraint on number), 'pros and cons' (string fields). This adds significant meaning beyond the input schema, which only provides types and no descriptions (0% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'leave a rating' with specific details (score 1-10 plus pros and cons). It distinguishes itself from siblings like 'pitch' or 'subscribe' by focusing on post-trading feedback.
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 'after trading on our signals', which provides clear context for when to use the tool. However, it does not mention when not to use it or compare to alternatives like 'evaluate_symbol'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_bottomsAInspectScan 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses payment mechanism ($0.01 per call, first paid call opens trial), retry instructions for 402 challenge, and no account needed. Does not describe error conditions or output format fully, but adequately conveys behavioral aspects.
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?
Five sentences, each adding distinct value: purpose, payment, retry, cold start, contrast with pitch. Front-loaded with the core action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, no output schema, and no annotations, the description is fairly complete. It explains the tool's action, ranking, payment, and contrasts with a sibling. Could briefly describe output format (e.g., returns list of commodity names or symbols), but 'return commodities' and 'ranked most-bottom first' gives sufficient 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 description coverage is 100% for the single 'limit' parameter. Description adds minimal extra semantics beyond the schema (mentions cold start but not parameter details). Falls at the baseline with no significant added 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?
Clearly states it scans the commodity complex snapshot and returns commodities at a bottom (strongest buy), ranked most-bottom first. Distinguishes from siblings like 'pitch' and 'scan_tops' by specifying that this names them while pitch tells how many.
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 guidance: best cold start (no need to pick a symbol), contrasts with free 'pitch' tool. Implicitly distinguishes from 'scan_tops' by naming opposite direction. Lacks explicit when-not-to-use for all siblings, but covers main alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_topsAInspectScan 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description covers payment ($0.01, 6-day trial), no signup required, and 402 retry mechanism. Does not mention rate limits or data freshness, but adequately discloses key behavioral aspects.
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?
Description is front-loaded with core purpose and all sentences add value. Slightly long but efficient given the need to explain payment and workflow.
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 1-param tool with no output schema, description is fairly complete: explains purpose, payment, cold start, and points to sibling. Missing exact output format but 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?
Only parameter 'limit' has full schema description (default 5, max 28). Description adds ordering context but not additional parameter meaning. Baseline 3 for high coverage.
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 and returns top (sell) commodities ranked most-top first. Distinguishes from sibling 'scan_bottoms' for bottoms and 'pitch' for counts.
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 when to use: to get sell signals for the whole universe without picking a symbol. Mentions alternative 'pitch' for count, and implies 'evaluate_symbol' for single symbol. Provides cold start guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subscribeAInspectCheck 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that calling with activate:true triggers a 402 payment challenge, requires signing and retry, and returns an X-SUB-KEY token for 30 days. It also mentions optional agentId linking. However, it does not describe side effects like whether activating modifies account state or what happens if already subscribed.
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 long and includes many clauses in one sentence. It front-loads the two use cases but then continues with payment details and trial info. Not every part is directly actionable; some information could be more concisely stated.
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 complexity (activation, token, trial), the description covers the main interaction flow. It explains the outcome of activation and the token usage. However, it lacks details on error cases, what the status check returns, and what happens if already subscribed. Overall, it provides sufficient context for an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description for both parameters (agentId, activate) is nearly identical to the schema descriptions. The description adds no new meaning beyond what the schema already provides, so it meets baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states two use cases: checking subscription status (FREE) and activating the monthly plan with activate:true. It explains the payment challenge and token generation. The verb 'check' and 'activate' are specific to the resource 'subscription'. It distinguishes from sibling tools which are unrelated.
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 indicates when to use activate:true vs without it. It mentions the trial period and per-call cost for non-subscribers. However, it does not explicitly state when not to use the tool or provide alternatives, but siblings are unrelated, so guidance is adequate.
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.
No comments yet. Be the first to start the discussion!
