Primary Source Commodities
Server Details
Primary-source commodities data for AI agents — EIA, FRED, CFTC, USDA, USGS via x402 on Base.
- 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.3/5 across 11 of 11 tools scored.
Each tool has a clearly distinct purpose: calendar.get for release schedules, catalog.list for instrument listing, price.latest and price.history for prices, inventory.get for EIA data, positioning.get for CFTC data, fundamentals.get for reports, fx.latest for FX, spread.get for derived spreads, snapshot.get for bundled sector view, and decision.get for rule-based decisions. No overlap or ambiguity.
All tools follow a consistent 'noun.verb' pattern with lowercase dot notation (e.g., catalog.list, price.latest, inventory.get). Verbs like 'get', 'list', 'history' are used predictably. No mixing of conventions.
With 11 tools, the set covers the essential commodity data operations (catalog, prices, inventory, positioning, fundamentals, spreads, FX, calendar, snapshots, decisions) without being bloated. Each tool earns its place for a focused data server.
The surface covers the full lifecycle of commodity data access: discovery (catalog), latest values (price.latest, inventory.get, positioning.get, fx.latest), history (price.history), derived values (spread.get), reports (fundamentals.get), scheduling (calendar.get), and aggregated views (snapshot.get, decision.get). No obvious gaps for the stated purpose.
Available Tools
11 toolscalendar.getRelease CalendarARead-onlyIdempotentInspect
List EIA, USDA, and CFTC release calendar entries with cadence, typical Eastern time, and next-hint notes. Free discovery tool — call before scheduling agents around inventory or WASDE prints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| events | Yes | Upcoming / recurring release events |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe read-only and idempotent behavior. The description adds useful context (free discovery tool, call before scheduling) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and contents, second provides usage guidance. 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?
Given no parameters and an output schema, the description fully covers what the tool does and suggests when to use it. No gaps.
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 the description does not need to add parameter info. It mentions output fields (cadence, Eastern time, next-hint), which is helpful for understanding the tool's result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it lists release calendar entries for EIA, USDA, and CFTC with specific fields (cadence, typical Eastern time, next-hint notes). This clearly distinguishes it from sibling tools like inventory.get or fundamentals.get.
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 suggests using it as a discovery tool before scheduling agents, but does not explicitly state when not to use it or compare with other tools. Sibling tools exist, but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
catalog.listList InstrumentsARead-onlyIdempotentInspect
List every commodity instrument in the catalog with sector, unit, primary source, and freshness metadata. Call this first to discover valid codes before price.latest or inventory.get. Free discovery tool — no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| instruments | Yes | Instrument registry rows |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds 'free discovery tool — no payment required', which is behavioral context beyond annotations. However, it does not detail any limitations like rate limits or pagination.
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 concise sentences, each with a distinct role: listing what it does, giving usage guidance, and noting free access. No 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 parameterless tool with an output schema, the description is complete: it explains the field contents, purpose, and connection to sibling tools. Output schema covers structured return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description fully conveys what the tool returns and its purpose, adding meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'list' and identifies the resource as 'every commodity instrument' with specific fields. It distinguishes from siblings by stating 'call this first to discover valid codes before price.latest or inventory.get'.
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 when to use: 'Call this first to discover valid codes before price.latest or inventory.get'. Implies alternatives and provides context with 'Free discovery tool — no payment required'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decision.getDecision PackARead-onlyIdempotentInspect
Build a deterministic decision pack for energy, metals, ags, or all sectors. Returns method, signals with direction/rationale, an embedded snapshot, and a disclaimer — no ML model, rule-based only.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes | Sector for the decision pack. Use all to bundle every sector. |
Output Schema
| Name | Required | Description |
|---|---|---|
| method | Yes | Deterministic method identifier |
| sector | No | Present for single-sector packs |
| sectors | No | Present when sector=all |
| signals | No | Directional signals with rationale |
| snapshot | No | |
| disclaimer | No | Non-advice / methodology disclaimer |
| generated_at | Yes | ISO timestamp when the pack was generated |
| model_version | No | Always null for rule-based packs; reserved field |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which align with a deterministic, non-destructive operation. The description adds value by explicitly stating it is rule-based, not an ML model, and detailing the return structure, providing behavioral context beyond annotations.
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 packs essential information: purpose, sectors, return components, and nature. It is front-loaded with the core action and leaves no room for ambiguity.
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, clear schema, and annotations), the description fully covers what the tool does and what it returns. The presence of an output schema further reduces the need for extensive description, and the provided text is sufficient.
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 covers 100% of parameters with clear enum descriptions. The description adds the clarifying statement 'Use all to bundle every sector,' which enhances understanding of the 'all' option beyond the schema's enum definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: building a deterministic decision pack. It specifies the sectors (energy, metals, ags, all) and the return components (method, signals, snapshot, disclaimer). The clarification that it's rule-based and not ML helps distinguish it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. Sibling tools like calendar.get, fundamentals.get, price.history, etc., cover various data retrieval functions, but there is no mention of context or alternatives for selecting decision.get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fundamentals.getUSDA/USGS FundamentalsARead-onlyIdempotentInspect
Fetch a fundamentals document: USDA WASDE, crop progress, export sales, or USGS mineral summaries. Choose kind based on the ags/metals question you are answering.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Fundamentals report kind. Example: wasde for World Agricultural Supply and Demand Estimates. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Document id |
| kind | Yes | Report kind echoed from the request |
| as_of | Yes | Report as-of date |
| payload | Yes | Kind-specific payload (quality, note, license_tag, freshness_class, and report fields) |
| observed_at | Yes | ISO timestamp when retrieved |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=true) but adds no behavioral details beyond what annotations already provide. It does not disclose any potential side effects, authentication needs, or rate limits, though the read-only nature is confirmed.
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 extremely concise, using only two sentences to convey purpose, examples, and usage guidance. Every word earns its place, and the structure is front-loaded with the action.
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, output schema exists), the description covers the core purpose and parameter selection. It could mention that each kind returns different data, but the output schema likely provides that detail.
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 semantic value by relating the 'kind' parameter to the type of question (ags vs. metals), which goes beyond the schema's simple enumeration. This helps the agent decide which value to use.
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 fetches a fundamentals document and lists specific report types (WASDE, crop progress, export sales, USGS), making the purpose specific and unambiguous. It also hints at usage context by mentioning 'ags/metals question.'
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 to choose the 'kind' based on whether the question is agricultural or metals-related, which helps in selecting the correct enum value. However, it does not mention alternatives or when not to use this tool compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fx.latestLatest FX RateARead-onlyIdempotentInspect
Return the latest FX rate observation for a pair or FRED FX series. Useful alongside commodity prices when converting cash values across currencies.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | FX pair or series id. Example: EURUSD, USDCNY, DTWEXBGS. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Stable observation id |
| name | Yes | Human-readable instrument name |
| unit | Yes | Unit of measure |
| as_of | Yes | As-of date for the observation |
| value | Yes | Observed numeric value |
| inputs | No | Input series ids when derived |
| source | Yes | Primary source provenance |
| derived | Yes | True when value is derived |
| formula | No | Derivation formula when derived |
| quality | Yes | Data quality label |
| raw_hash | No | Hash of raw source payload |
| series_id | Yes | Underlying series id |
| instrument | Yes | Instrument code, e.g. CL |
| provenance | Yes | Retrieval / cache provenance |
| license_tag | Yes | License / redistribution tag |
| observed_at | Yes | ISO timestamp when observed |
| freshness_class | Yes | Freshness class for the series |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to repeat safety traits. It adds no extra behavioral context (e.g., error handling, rate limits), but given annotation coverage, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that contain all necessary information. 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 the simple input schema (one parameter, fully described) and the presence of an output schema, the description is complete. It explains the tool's purpose and usage context adequately.
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 itself describes the 'pair' parameter with examples. The description adds context about being useful for converting cash values across currencies, complementing the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'latest FX rate observation', specifying the input as a pair or FRED FX series. It also distinguishes from sibling tools by mentioning usefulness alongside commodity prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool ('alongside commodity prices when converting cash values across currencies'), but does not explicitly state when to avoid it or compare to other siblings like price.latest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inventory.getEIA InventoryARead-onlyIdempotentInspect
Fetch EIA weekly petroleum inventory levels. Omit series to list all latest inventory points, or pass a series key to get week-over-week change, vs-5y deviation, and a surprise label for that series.
| Name | Required | Description | Default |
|---|---|---|---|
| series | No | Optional EIA inventory series key. Omit to return all latest inventory rows. Example: crude_stocks. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | All latest inventory points when series is omitted |
| vs_5y | No | Deviation vs five-year average when series is provided |
| latest | No | Latest point when a series key is provided |
| wow_change | No | Week-over-week change when series is provided |
| surprise_label | No | Surprise classification when series is provided |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, destructive=false, idempotent=true. Description adds specifics about returned computed fields (week-over-week change, vs-5y deviation, surprise label). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, front-loaded with action and resource. Every sentence 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?
All necessary info: what the tool does, how to use the parameter, what output to expect (especially with output schema present). No gaps 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?
Schema covers 100% of the single parameter, but description enriches it by explaining how omitting vs. providing series changes the output (all latest vs. computed analytics). Adds significant 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?
Clear verb ('Fetch'), specific resource ('EIA weekly petroleum inventory levels'), and distinguishes two usage modes (list all vs. get computed stats). No ambiguity.
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 tells when to omit vs. pass the series key, and what each invocation returns. Lacks explicit 'when not to use' but sibling tools are unrelated, so guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
positioning.getCOT PositioningARead-onlyIdempotentInspect
Return the latest CFTC Commitments of Traders managed-money positioning for an instrument code. Includes long, short, net, and week-over-week net change with source URL.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Instrument code from catalog.list. Example: CL, NG, GC, ZC. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | COT row id |
| mm_net | Yes | Managed-money net contracts |
| mm_long | Yes | Managed-money long contracts |
| mm_short | Yes | Managed-money short contracts |
| instrument | Yes | Instrument code |
| source_url | Yes | CFTC source URL |
| observed_at | Yes | ISO timestamp when observed |
| report_date | Yes | CFTC report date |
| mm_net_change | Yes | Week-over-week change in managed-money net |
| commodity_name | Yes | CFTC commodity name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable detail about the specific data fields returned (long, short, net, week-over-week net change) and a source URL, going beyond annotations.
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 only two sentences, both front-loaded and information-dense. No wasted words; every part adds value (purpose, output fields, data source).
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 parameter set, rich annotations, and presence of an output schema, the description fully covers what the tool does and what to expect. It references the required 'code' from sibling tool catalog.list and specifies output components.
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 provides full coverage for the single parameter (code) including description and examples. The tool description does not add additional semantic meaning for the parameter beyond what the schema states, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('latest CFTC Commitments of Traders managed-money positioning') with clear output fields (long, short, net, change). It is precise and distinct from sibling tools like fundamentals.get or inventory.get.
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 clearly states the tool returns CFTC positioning data for an instrument code, implying it should be used for that specific purpose. However, it does not explicitly exclude alternatives or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price.historyPrice HistoryARead-onlyIdempotentInspect
Return historical observations for an instrument code (up to 500 points). Use after price.latest when you need a short time series for the same code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Instrument code from catalog.list. Example: CL, GC, ZC. | |
| limit | No | Number of historical points to return. Max 500, default 60. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Historical observations, newest first or as stored |
| count | Yes | Number of points returned |
| series_id | Yes | Underlying series id |
| instrument | Yes | Instrument code |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety. The description adds the constraint 'up to 500 points' but does not disclose additional behavioral details like ordering, error handling, or rate limits. With annotations covering the core traits, a 3 is appropriate.
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: the first states the core functionality, the second provides usage guidance. Every sentence is meaningful and front-loaded. 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?
The tool is simple (2 params, required=1), has an output schema, and the annotations cover safety. The description addresses when to use it relative to sibling 'price.latest'. Given the low complexity and available structured information, the description 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?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds context about usage (e.g., 'use after price.latest'), but does not provide new information about parameter values beyond the schema examples. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return', the resource 'historical observations for an instrument code', and includes the constraint 'up to 500 points'. It distinguishes from the sibling 'price.latest' by specifying when to use this tool (after price.latest for a short time series). This satisfies the 'specific verb+resource, distinguishes from siblings' criterion.
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 tells when to use this tool ('Use after price.latest when you need a short time series') and implies a sequence with price.latest. It does not list exclusions or alternative tools for longer series, but it provides clear context for usage, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price.latestLatest PriceARead-onlyIdempotentInspect
Return the latest cash/fundies observation for one instrument code. Use catalog.list to discover codes such as CL, GC, or ZC. Response follows the shared observation contract with provenance and license tags.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Instrument code from catalog.list. Example: CL, GC, ZC. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Stable observation id |
| name | Yes | Human-readable instrument name |
| unit | Yes | Unit of measure |
| as_of | Yes | As-of date for the observation |
| value | Yes | Observed numeric value |
| inputs | No | Input series ids when derived |
| source | Yes | Primary source provenance |
| derived | Yes | True when value is derived |
| formula | No | Derivation formula when derived |
| quality | Yes | Data quality label |
| raw_hash | No | Hash of raw source payload |
| series_id | Yes | Underlying series id |
| instrument | Yes | Instrument code, e.g. CL |
| provenance | Yes | Retrieval / cache provenance |
| license_tag | Yes | License / redistribution tag |
| observed_at | Yes | ISO timestamp when observed |
| freshness_class | Yes | Freshness class for the series |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent. The description adds value by noting the response follows a shared observation contract with provenance and license tags, and uses terms like 'cash/fundies' to clarify data type, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with function, then guidance. Highly efficient.
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 single-parameter tool with an output schema, the description covers purpose, parameter source, and response structure sufficiently. No gaps given 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%, so the schema already explains the parameter well. The description reinforces using catalog.list but does not add new semantic details 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 the tool returns the latest observation for one instrument code, using specific verb 'Return' and resource 'latest cash/fundies observation'. It distinguishes from siblings like price.history by focusing on 'latest' and from catalog.list by referencing it for code discovery.
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 guides the agent to use catalog.list to discover codes, providing clear context. It does not explicitly state when not to use, but the limited scope (latest, one instrument) implicitly contrasts with siblings for historical or multi-instrument data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapshot.getSector SnapshotARead-onlyIdempotentInspect
Build a sector snapshot bundling prices, inventories, spreads, and related fundies for energy, metals, ags, or all sectors. Prefer this over calling many single-observation tools when you need a full sector picture.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes | Sector to snapshot. Use all to receive energy, metals, and ags together. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cot | No | COT rows when relevant |
| as_of | Yes | Snapshot as-of timestamp |
| crush | No | |
| wasde | No | WASDE payload when relevant |
| prices | No | Latest prices for the sector |
| sector | No | Present for single-sector responses |
| sectors | No | Present when sector=all |
| crack_321 | No | |
| inventory | No | Inventory rows when relevant |
| export_sales | No | Export sales when relevant |
| crop_progress | No | Crop progress when relevant |
| freshness_note | No | Freshness summary |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that the tool bundles multiple data types, which is useful context but does not disclose additional behavioral traits (e.g., response size, rate limits). No contradiction with annotations.
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 efficiently state purpose and usage guidance. No extraneous words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one fully-documented parameter, an output schema present, and annotations covering safety, the description sufficiently covers purpose, scope, and when to use. All essential information is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with an enum and description. Description repeats the sector options and clarifies 'all' returns all sectors together, adding slight value but not significantly 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?
Description uses specific verb 'Build' and resource 'sector snapshot', clearly stating it bundles multiple data types (prices, inventories, spreads, fundies) for specific sectors. This distinguishes it from single-observation sibling tools like price.latest, inventory.get, etc.
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 advises to prefer this over calling many single-observation tools for a full sector picture. Provides clear context for when to use ('full sector picture') but does not explicitly list when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spread.getDerived SpreadARead-onlyIdempotentInspect
Compute a derived spread observation: 3-2-1 crack, soybean crush, WTI-Brent basis, or calendar (calendar requires licensed curve data and may return available=false). Prefer crack/crush/basis for live derived values with formula and inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Optional root symbol for calendar spreads. Example: CL. Ignored for crack/crush/basis. | |
| type | Yes | Spread type to compute. Example: crack for 3-2-1 gasoline/distillate crack. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Stable observation id |
| name | No | Human-readable instrument name |
| note | No | Explanation when unavailable or partially degraded |
| root | No | Calendar root when type=calendar |
| unit | No | Unit of measure |
| as_of | No | As-of date for the observation |
| value | No | Observed numeric value |
| inputs | No | Input series ids when derived |
| source | No | Primary source provenance |
| derived | No | True when value is derived |
| formula | No | Derivation formula when derived |
| quality | No | Data quality label |
| raw_hash | No | Hash of raw source payload |
| available | No | False when the spread cannot be computed |
| series_id | No | Underlying series id |
| instrument | No | Instrument code, e.g. CL |
| provenance | No | Retrieval / cache provenance |
| license_tag | No | License / redistribution tag |
| observed_at | No | ISO timestamp when observed |
| legs_quality | No | Per-leg quality when inputs are mixed |
| freshness_class | No | Freshness class for the series |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotent, read-only, non-destructive. Description adds that calendar requires licensed data and may return available=false, providing behavioral nuance beyond annotations.
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 efficient sentences with no wasted words. Front-loaded with action and supported by example list. 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 output schema exists, description adequately covers purpose, types, and a key limitation. Completeness is appropriate for the tool's simplicity, though could briefly mention that calendar spreads use the 'root' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. Description reinforces the enum values with concrete examples (3-2-1 crack, soybean crush, WTI-Brent basis) and adds licensing constraint for calendar root, but does not introduce new structural 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?
Clearly states verb 'compute' and resource 'derived spread observation'. Specifies exact spread types (crack, crush, basis, calendar) and distinguishes calendar from others by noting licensing requirements.
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 recommends crack/crush/basis over calendar for live values, and warns that calendar requires licensed data and may return available=false. Provides clear context for when to use each type, though does not reference sibling tools directly.
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!