AssayChain — Mineral Intelligence (USGS and Field Runs)
Server Details
USGS commodity benchmarks, attested field run logs, and mining/geologic district data for AI agents. Nine data endpoints gated by x402 ($0.10 USDC on Base). Tools: get_commodity_benchmark (gold, silver, copper, and 17 more critical minerals), get_ultrasound_run_data (on-chain EAS-attested gravity-separation field runs), district.history (MRDS-sourced deposit and assay history by country/state/district), and ask_sales_agent. No API keys — pay per call in USDC.
- 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/5 across 19 of 19 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose covering different facets of mineral intelligence: operations, benchmarks, extraction, supply chain, etc. Even similar tools like benchmark.commodity, benchmark.runs, and benchmark.sample are clearly differentiated by their described functionality.
Naming is mixed: some tools use snake_case (e.g., active_operations, blm_claims_data), while others use dot notation (e.g., benchmark.commodity, extract.run). This inconsistency could confuse agents accustomed to a single pattern.
With 19 tools, the set is somewhat large but well-scoped for the domain. Each tool addresses a specific need without redundancy, though some users might find the number high for a single server.
The tool set covers a broad range of mineral intelligence topics: operations, benchmarks, criticality, supply chain, ESG, extraction, and more. Missing are tools for user management or bulk comparisons, but the core domain is well-covered.
Available Tools
19 toolsactive_operationsBInspect
Active US mining operations for a given critical mineral. Returns operator, location, mine type, and capacity. $0.25 per query.
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | Yes | Commodity slug (e.g., copper, gold, lithium) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions the tool returns specific fields and cost, but fails to indicate whether it is read-only, requires authorization, or has rate limits. This is insufficient for an agent to assess side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and output, with no wasted words. The cost is mentioned succinctly. Perfectly concise for the information conveyed.
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 return fields and cost, which is adequate for a simple query tool without an output schema. However, it misses potential constraints like pagination or maximum results, leaving some completeness gap.
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 the commodity parameter clearly described as a slug. The description adds context about the tool's return fields and US scope, but does not enhance parameter semantics beyond what the schema already provides.
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 active US mining operations for a given critical mineral, specifying output fields like operator, location, mine type, and capacity. This differentiates it from sibling tools such as 'benchmark.commodity' or 'supply_share'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only includes a cost hint ($0.25 per query) but does not specify prerequisites, exclusions, or recommendations for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
benchmark.commodityARead-onlyIdempotentInspect
Discovery preview for USGS Mineral Commodity Summaries benchmark data — 20 critical minerals: copper, gold, silver, lithium, cobalt, nickel, manganese, graphite, antimony, gallium, germanium, platinum_group, rare_earths, tellurium, tin, titanium, tungsten, uranium, vanadium, zinc. Returns available field names, on-chain provenance UIDs, and the paid REST endpoint. Data is useful as one structured, EAS-attested input for supply-chain due diligence, UFLPA sourcing evidence, EU Battery Regulation 2023/1542 disclosure, and CBAM/CSDDD compliance research. Full data (grade cutoffs, spot pricing, recovery benchmarks, production statistics) requires $0.10 USDC via GET /api/benchmark/{commodity} using the x402 protocol on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | Yes | Mineral commodity slug. One of: copper, gold, silver, lithium, cobalt, nickel, manganese, graphite. |
Output Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | |
| payment | Yes | |
| commodity | Yes | |
| provenance | Yes | |
| paid_endpoint | Yes | REST endpoint for the full paid response. |
| schema_version | Yes | |
| available_fields | Yes | Top-level field names present in the full paid response. |
| publication_date | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds that it is a preview, lists return items, and explains payment requirement for full data, offering useful behavioral context.
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 verbose with compliance use cases that may not be essential; it front-loads purpose but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers what the tool returns and the steps to access full data, though it lacks details on return format or endpoint usage.
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 the parameter with incomplete enum list, but the description provides the full 20-mineral list and contextualizes the parameter's role in the benchmark data lookup.
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 field names, provenance UIDs, and a paid endpoint for benchmark data, but does not explicitly differentiate from sibling tools like benchmark.runs or benchmark.sample.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is a discovery preview and mentions the full data requires payment, but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
benchmark.runsARead-onlyIdempotentInspect
Discovery preview for attested mineral-processing field run logs. Covers multiple rig modalities (mini-Duke elutriation, ultrasound-assisted grooved-tray gravity separation, and future rigs) under the same on-chain schema. Returns run count, run IDs, date range, and the paid REST endpoint. Full run data (feed parameters, tray geometry, ultrasound frequency where applicable, recovery rates, EAS attestation UIDs) requires $0.10 USDC via GET /api/benchmark/ultrasound-grooved-tray using the x402 protocol on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| attested_only | No | If true, count and list only runs that carry an on-chain EAS attestation UID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| payment | Yes | |
| run_ids | Yes | Run ID list (YYYY-MM-DD-NNN format), newest first. |
| date_range | Yes | |
| total_runs | Yes | Total run records matching the filter. |
| paid_endpoint | Yes | REST endpoint for the full paid response. |
| attested_count | Yes | Runs that have an on-chain EAS attestation UID. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (readOnlyHint, destructiveHint, idempotentHint). It discloses that the tool returns a preview (not full data), mentions the paid endpoint for detailed data, and explains the scope (multiple rig modalities, on-chain schema). This provides a clear behavioral profile that aligns with the safe, read-only nature indicated by 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 relatively concise at four sentences, covering key information without redundancy. It front-loads the tool's purpose and enumerates return values. Minor improvement could be made by structuring the paid endpoint info more cleanly, but overall it is well-organized and to the point.
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 presence of an output schema and the tool's role as a preview, the description provides all necessary context: what it returns, what it omits (full data requires payment), and the modalities covered. It addresses the user's likely need to understand the scope and limitations of the preview, making it complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description for the single parameter 'attested_only' (schema coverage 100%). The tool description does not add any further meaning or usage guidance for this parameter beyond what the schema already states. Therefore, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as a 'discovery preview' for mineral-processing run logs, listing exactly what it returns (run count, IDs, date range, paid endpoint) and differentiates from the full data endpoint by noting the $0.10 USDC requirement. The verb 'returns' and resource 'run logs' are specific, and the sibling context is addressed by contrasting with the paid endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: as a preview before paying for full data. It explicitly states that full run data requires payment via a different endpoint, guiding users to use this tool for summary information. However, it does not explicitly mention when not to use it or list alternatives, though the context of a preview is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
benchmark.sampleARead-onlyIdempotentInspect
Free sample of the benchmark data shape for any supported commodity. Returns the full field hierarchy with real field names, units, string labels, and nested structure — but all numeric values are replaced with '<number: paid>'. Use this to understand exactly what fields you will receive from the paid benchmark.commodity endpoint before spending $0.10 USDC. Includes provenance fields (attestation_uid, source_cid, result_cid) and the paid REST endpoint URL.
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | Yes | Mineral commodity slug. One of: copper, gold, silver, lithium, cobalt, nickel, manganese, graphite, antimony, gallium, germanium, platinum_group, rare_earths, tellurium, tin, titanium, tungsten, uranium, vanadium, zinc. |
Output Schema
| Name | Required | Description |
|---|---|---|
| sample | Yes | Full field hierarchy with numeric values replaced by '<number: paid>'. |
| payment | Yes | |
| commodity | Yes | |
| paid_endpoint | Yes | |
| schema_version | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds key behavioral details: numeric values are replaced, and the output includes provenance fields and the paid REST endpoint 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?
Three sentences deliver all essential information without fluff. The description is front-loaded with the core promise and includes additional context efficiently.
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 present), the description fully covers its purpose, behavior, and usage context. It is complete and leaves 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?
Schema coverage is 100% with a clear enum and description for the 'commodity' parameter. The description adds no new parameter details beyond what's in the schema, warranting the baseline score.
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 that it provides a free sample of benchmark data shape with real field names but replaced numeric values. It explicitly differentiates from the paid benchmark.commodity endpoint, making its purpose unambiguous.
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 instructs to use this tool to understand fields before spending on the paid endpoint, providing clear when-to-use guidance. It does not state when not to use it, but the context implies it is only for preview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
blm_claims_dataAInspect
BLM LR2000 mining claims data by state and county. Returns active lode/placer/millsite counts for US mining counties. $0.25 per query.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | US state code (e.g., NV, AZ, CA) | |
| county | Yes | County name slug (e.g., Elko, Pima) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost ($0.25 per query) and output type (counts), which is important for usage decisions. No annotations exist, so description carries full burden. Could mention if results are cached or any usage limits, but adequate.
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 fluff, front-loaded with purpose and key details. 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 no output schema, description explains return type (counts). Context signals show simple params. Only minor gap: no mention of error handling or response format beyond counts.
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 two clear parameters. Description adds minimal meaning beyond schema (e.g., state code format, county slug), which is acceptable for simple parameters.
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 provides BLM LR2000 mining claims data by state and county, returning active lode/placer/millsite counts. It distinguishes from sibling tools like 'active_operations' or 'commodity' benchmarks, which cover different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied for retrieving mining claims counts by location, but no explicit guidance on when to use this tool versus alternatives like 'supply_share' or 'criticality.crosscheck'. Missing exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
china_trade_controlBRead-onlyIdempotentInspect
China export restriction check for restricted minerals (gallium, germanium, graphite, antimony, tungsten, tellurium, rare earths). Returns restricted status, effective date, and source. Full data requires $0.25 USDC via GET /api/trade-controls/{commodity} using x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | Yes | Mineral commodity slug. |
Output Schema
| Name | Required | Description |
|---|---|---|
| payment | Yes | |
| commodity | Yes | |
| restricted | Yes | |
| paid_endpoint | Yes | |
| restriction_date | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent. Description adds output details (status, date, source) and payment requirement, which is beyond annotations but not extensive.
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 with essential info front-loaded. No filler.
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?
Output schema exists, so return details aren't needed. But the description omits that it covers all 20 minerals and lacks usage context relative to siblings. Payment info is a plus.
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% param details with enum and description. However, the description's narrow list of restricted minerals ('gallium, germanium...') contradicts the full schema enum (20 minerals), potentially misleading the agent.
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 checks China export restrictions for specific minerals and returns status, date, and source. It distinguishes from siblings like supply_share, but doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Mentions payment but not when-not or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
corpus.searchARead-onlyIdempotentInspect
Free lexical search (BM25-lite) across all 199 EAS-attested files: 20 USGS critical-mineral commodity benchmarks + 179 US/MX mining district records. Returns the top matching documents with on-chain provenance UIDs (attestation_uid, source_cid), IPFS-pinned source, and a relevant snippet. Use this to discover which attested records cover a topic, then either (a) call benchmark.commodity / district.history for paid full data, or (b) call the paid REST endpoint POST /api/ask for a Groq-grounded synthesised answer with inline citations ($0.10 USDC via x402 on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional filter to restrict the corpus to commodities or districts only. | |
| query | Yes | Free-text query — e.g. 'arsenic penalty copper smelter', 'gallium export controls China', 'silver veins Philipsburg Montana'. | |
| top_k | No | Number of hits to return (1–20). |
Output Schema
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| query | Yes | |
| corpus | Yes | |
| payment | Yes | |
| paid_endpoints | Yes |
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. The description adds value by detailing the algorithm (BM25-lite) and output fields (attestation_uid, source_cid, IPFS-pinned source, snippet), but does not disclose further behavioral traits like rate limits or error cases. Still adds 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?
The description is a single paragraph of three sentences, front-loading the purpose and corpus, then explaining use cases. Every sentence is necessary and no redundant information; it is efficiently structured.
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 has 3 parameters and an output schema (confirmed), the description adequately covers what the tool does, what it returns (top documents with provenance UIDs, snippet), and how to proceed. It does not need to elaborate on return values as the output schema exists.
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 baseline is 3. The description adds value with example queries and clarifies semantics for 'kind' and 'top_k', but does not introduce new information beyond the schema's own descriptions. The examples provide practical usage context, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states a 'free lexical search (BM25-lite)' over a specific corpus of 199 EAS-attested files, distinguishing it from sibling tools like benchmark.commodity and district.history which provide paid full data. The verb 'search' and resource 'attested corpus' are clear and specific.
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 gives explicit guidance: 'Use this to discover which attested records cover a topic, then either (a) call benchmark.commodity / district.history for paid full data, or (b) call the paid REST endpoint...' This provides when to use and when to use alternatives, along with a clear workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
criticality.crosscheckARead-onlyIdempotentInspect
Multi-jurisdiction critical mineral classification for 20 commodities. Returns crosscheck status for US DoD, EU Critical Raw Materials Act, IEA Critical Minerals, and Japan METI lists — plus number of jurisdictions rating the mineral as critical. Full data requires $0.25 USDC via GET /api/criticality/{commodity} using x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | Yes | Mineral commodity slug. |
Output Schema
| Name | Required | Description |
|---|---|---|
| payment | Yes | |
| commodity | Yes | |
| criticality | Yes | |
| paid_endpoint | Yes | |
| jurisdictions_rating_critical | Yes |
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. The description adds that the tool returns crosscheck status and jurisdiction count, and importantly discloses the payment requirement for full data, which is 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?
Two sentences, front-loaded with the primary purpose, no unnecessary words. Every sentence adds value: the first explains the core function, the second provides critical payment context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one enum parameter) and the presence of an output schema (not shown but noted), the description adequately covers the tool's functionality and constraints, including the monetized data access.
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 a clear enum and description. The description does not add extra meaning to the 'commodity' parameter beyond mentioning '20 commodities', but the schema already suffices.
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 performs a multi-jurisdiction crosscheck for 20 critical mineral commodities, listing specific lists (US DoD, EU CRMA, IEA, Japan METI) and the output (crosscheck status plus jurisdiction count). This is specific and distinguishes it from sibling tools like china_trade_control or supply_share.
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 includes a critical usage guideline: full data requires a $0.25 USDC payment via a specific endpoint and method. While it doesn't explicitly state when not to use this tool versus others, the specificity of multi-jurisdiction crosscheck implies appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
district.historyARead-onlyIdempotentInspect
Free preview of a US or Mexico mining district record (MRDS-sourced). Returns field inventory, commodity summary, discovery year, and deposit count. Useful for domestic-sourcing due diligence (DoD/DFC project assessments, UFLPA country-of-origin research), historic production context, and mining project developer research. Full record (deposits[], geology, sources[], history narrative) requires $0.50 USDC via GET /api/historical/{country}/{state}/{county}/{district} using x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | State/province code, e.g. 'MT', 'NV', 'SON' | |
| county | Yes | County or equivalent name, e.g. 'Missoula' | |
| country | Yes | ISO 3166-1 alpha-2 country code, e.g. 'US', 'CA', 'MX' | |
| district | Yes | District name or slug, e.g. 'Coloma' or 'Helena' |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| state | Yes | |
| county | Yes | |
| country | Yes | |
| payment | Yes | |
| district | Yes | |
| has_history | Yes | |
| deposit_count | Yes | |
| paid_endpoint | Yes | |
| discovery_year | Yes | |
| attestation_uid | Yes | |
| available_fields | Yes | |
| development_status | Yes | |
| district_alt_names | Yes | |
| primary_commodities | Yes | |
| secondary_commodities | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying it's a 'free preview' and what it returns, reinforcing non-destructive, read-only nature. No contradiction.
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. First sentence packs purpose and return content. Second sentence provides context and upgrade path. Front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and a simple return (field inventory, commodity summary, discovery year, deposit count), the description covers everything a tool user needs to know. Output schema exists but description summarizes content 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?
Schema description coverage is 100%, so baseline is 3. The description does not add new semantics beyond the schema descriptions for country, state, county, district. It provides context that these are for US or Mexico, but that is implied by examples.
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 provides a 'free preview' of a mining district record and lists specific returned data: field inventory, commodity summary, discovery year, deposit count. This distinguishes it from sibling tools which cover benchmarks, search, extracts, and sales.
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 describes use cases: domestic-sourcing due diligence (DoD/DFC project assessments, UFLPA country-of-origin research), historic production context, and mining project developer research. Also mentions the paid alternative for full record, guiding when to upgrade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
earth_mri_focus_areasCInspect
USGS Earth MRI focus area data by state. Returns completed and planned geophysical/geochemical surveys. $0.25 per query.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | US state code (e.g., NV, AZ, CA) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions cost per query but says nothing about rate limits, authentication, side effects, or data freshness. Minimal disclosure.
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, no wasted words. However, including the cost might be considered extraneous for the core purpose, but it is still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description provides the basic purpose but lacks details on return format or what exactly 'focus area data' contains. Adequate but incomplete.
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% (the one parameter is documented in schema). The description does not add meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns USGS Earth MRI focus area data by state and specifies it returns completed and planned surveys. However, it does not explicitly distinguish from sibling tools like 'geophysics_surveys', which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no mention of prerequisites or limitations. The only usage hint is 'by state', but no explicit when/when-not advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
esg_profileARead-onlyIdempotentInspect
Multi-dimension ESG intelligence for critical minerals. Returns recycling metrics (recycling rate, old/new scrap split, EOL recovery), carbon intensity by producing country (industry-average LCA values from ICMM, IEA, Ecoinvent), and regulatory exposure (EU CBAM, EU Battery Passport, IRA §45X, SEC climate rule). Sustainability analysts, compliance officers, and carbon-accounting agents use this for ESG due diligence. Full data for all 20 commodities requires $0.50 USDC via GET /api/esg/{commodity} using x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | Yes | Mineral commodity slug. |
Output Schema
| Name | Required | Description |
|---|---|---|
| payment | Yes | |
| commodity | Yes | |
| paid_endpoint | Yes | |
| key_carbon_note | Yes | |
| recycling_rate_pct | Yes | |
| key_regulatory_note | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds transparency by disclosing the payment requirement ($0.50 USDC for full data) and specifying the API endpoint and protocol (x402 on Base). This goes beyond standard annotation coverage.
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 front-loaded with the main purpose, followed by data types, user roles, and payment details. Each sentence adds value, though the payment information could be integrated more succinctly. Overall, it is well-structured and not overly verbose.
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 a simple input schema (one parameter) and an output schema present, the description adequately covers what the tool does, expected users, and a key constraint (payment). No critical gaps are apparent for an ESG data lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'commodity' (enum with 20 options, described as 'Mineral commodity slug.'). The tool description does not add any further explanation about the parameter's meaning or usage, so it does not compensate beyond the schema 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 clearly states it returns 'recycling metrics, carbon intensity by producing country, and regulatory exposure' for critical minerals, making the verb ('returns') and resource ('ESG intelligence') explicit. It distinguishes itself from sibling tools focused on benchmarks, criticality, or trade controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions target users ('sustainability analysts, compliance officers, and carbon-accounting agents') and a payment requirement, but provides no guidance on when to use this tool versus alternatives like criticality.crosscheck or benchmark.commodity. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract.estimateARead-onlyInspect
Free probe + price quote for paid structured-data extraction from a public document URL (pdf_digital, pdf_scanned, image, csv, txt). Returns estimate_id, source_type, page/row count, quality_floor grade (A/B/C/D), cost_breakdown {est_input_tokens, est_output_tokens, model_cost_usdc, margin_x, price_usdc}, and 15-min expires_at. Use the estimate_id with extract.run to pay via x402 USDC on Base. Honest grading: jobs returned as grade D receive an 80% auto-refund.
| Name | Required | Description | Default |
|---|---|---|---|
| source_url | Yes | Public http(s) URL of the document to estimate. Max 10 MB. | |
| source_type | No | Optional hint. Server auto-detects from MIME type if omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | No | |
| error | No | |
| pages | No | |
| expires_at | No | |
| estimate_id | No | |
| source_type | No | |
| status_code | No | |
| quality_floor | No | Expected grade: A, B, C, or D. |
| cost_breakdown | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations stating safe read, the description reveals an auto-refund policy for grade D jobs and a 15-minute expiration, adding significant behavioral context not captured by 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 concise, front-loaded with purpose, and each sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fully explains return values including pricing and refund policy, leaving no gaps in understanding the tool's behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all parameters with descriptions; the description reinforces the supported source types and auto-detection, but adds no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a free probe and price quote for structured-data extraction from public document URLs, listing supported types and return fields. It distinguishes itself from sibling tools like extract.run by specifying the use of estimate_id for payment.
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 tells the agent to use the estimate_id with extract.run to pay via x402 USDC, clarifying its role as a preliminary step. It does not explicitly state when not to use it, but the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract.resultARead-onlyIdempotentInspect
Fetch the structured extraction result for a previously paid job. Returns job_id, grade (A/B/C/D), and the assay-extract-v0.1 result document (samples, doc_type, lab, report_date, OPSEC-rounded coords, raw_text). Requires the HMAC token from result_url. Result TTL is 24 h after the paid run completes.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | HMAC token from result_url (the ?token=... query param). | |
| job_id | Yes | The job_id (same value as estimate_id) returned by the paid run. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| grade | No | |
| job_id | No | |
| result | No | |
| status_code | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds critical context: token authentication requirement and 24-hour TTL. No contradictions 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 deliver complete guidance. First sentence states action and outputs; second covers prerequisites and constraints. 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?
Given output schema exists, description appropriately covers prerequisites, return fields, and TTL. No gaps for this retrieval 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?
Both parameters have full schema descriptions. The description adds relational context: token is from result_url, job_id equals estimate_id. This aids correct invocation beyond schema alone.
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 'Fetch the structured extraction result for a previously paid job' and lists specific return fields. Distinguishes from siblings like extract.run (executes job) and extract.estimate (cost estimate) by focusing on result retrieval.
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 clear prerequisites (requires HMAC token from result_url) and temporal constraint (TTL 24h). Does not explicitly list when not to use, but the context strongly implies it's only for completed paid jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract.runARead-onlyIdempotentInspect
Returns invocation guidance for executing a paid extraction job after extract.estimate. Payment is x402 USDC on Base, amount equals cost_breakdown.price_usdc from the estimate (clamped onto the 5-tier ladder: $0.10 / $0.50 / $1.00 / $2.50 / $5.00). Result delivery: job_id + result + grade (A/B/C/D) + result_url. Grade D triggers 80% auto-refund. MCP cannot carry the X-PAYMENT header, so this tool returns the endpoint + price; execute the paid POST directly with an x402 client (x402-fetch, x402-axios).
| Name | Required | Description | Default |
|---|---|---|---|
| estimate_id | Yes | The estimate_id returned by extract.estimate. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| model | Yes | |
| ladder | Yes | Allowed price tiers in USDC. |
| method | Yes | |
| status | Yes | |
| payment | Yes | |
| endpoint | Yes | Full URL of the paid REST endpoint to POST to. |
| expires_at | Yes | |
| price_usdc | Yes | Exact price for this estimate, or null if unknown. |
| estimate_id | Yes | |
| supported_source_types | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool does not execute the job, returns guidance only, includes payment ladder details, result grade D triggers 80% auto-refund, and accounts for MCP limitations. Complements annotations (readOnlyHint, idempotentHint, destructiveHint) with rich behavioral context.
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?
Concise yet comprehensive: covers purpose, payment mechanism, result format, refund policy, and execution steps without redundancy. Well-structured and 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?
Given the tool's complexity, full schema coverage, and existence of output schema, the description provides complete guidance: workflow step, payment details, result delivery, and MCP limitation. No gaps for agent decision-making.
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% for the single parameter (estimate_id) with a clear description. The tool description adds context that price comes from the estimate, but does not substantially enhance parameter meaning 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 invocation guidance for a paid extraction job after extract.estimate, distinguishing it from sibling tools like extract.estimate and extract.result.
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 instructs when to use (after extract.estimate) and how to proceed: get endpoint and price, then execute a paid POST directly with an x402 client, since MCP cannot carry the payment header.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geophysics_surveysBInspect
Historical geophysical survey metadata for US mining districts. Returns aeromag, gravity, EM, and radiometric survey details. $0.25 per query.
| Name | Required | Description | Default |
|---|---|---|---|
| district | Yes | District slug (e.g., philipsburg, ajo, bingham) |
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 gives a high-level overview but does not disclose behavioral traits such as data freshness, potential for empty results, or any side effects. The description is too brief to inform the agent about important behaviors.
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, consisting of two sentences that convey the essential information without waste. It includes pricing, making it efficient for an agent to parse.
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 required parameter, no output schema, no nested objects), the description is largely complete. It could mention the response format or data availability, but it is adequate for basic usage.
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 parameter 'district', which includes a description. The tool description does not add meaningful additional context beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns historical geophysical survey metadata for US mining districts, listing aeromag, gravity, EM, and radiometric survey details. It is specific about the resource and action, but does not explicitly distinguish from sibling tools such as district.history or earth_mri_focus_areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description includes pricing ($0.25 per query) but does not specify when to use this tool vs alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sales.askARead-onlyInspect
Ask anything about this API: commodities covered, how on-chain provenance works, pricing tiers, x402 payment flow, MCP integration, or the Extract API. Also ask how to use this data as input for UFLPA compliance, EU Battery Regulation 2023/1542 sourcing disclosures, CBAM/CSDDD supply-chain research, or DoD/DFC domestic mineral sourcing assessments. Free to call. Returns a natural-language answer from a small LLM grounded on the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question about the API, what it sells, or how to access it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | LLM model used to generate the answer. |
| answer | Yes | Natural-language answer from the sales agent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, signaling a safe, open-ended query. The description adds that it returns natural-language answers from a small LLM grounded on docs, and is free to call, which goes beyond the annotations without contradicting them.
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 well-structured, front-loaded with the core purpose, and lists examples in a clear list-like fashion. It is slightly verbose with the compliance examples but remains easy to parse and free of 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?
Given the tool's simplicity (single parameter, no complex behavior) and the presence of an output schema (though not shown), the description provides adequate context: it explains the return type (natural-language answer), lists use cases, and notes it's grounded in documentation. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'question' described. The description enriches this by providing a wide range of example topics and compliance use cases, giving the agent a better sense of valid inputs beyond the schema's minimal 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 states the tool's purpose: answering questions about the API on various topics like commodities, provenance, pricing, and compliance uses. It distinguishes itself from sibling tools (e.g., benchmark.commodity, extract.run) by being a general Q&A agent rather than a specific data retrieval or extraction tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete examples of when to use the tool (compliance regulations, API questions) and states it's free to call. However, it does not explicitly exclude use cases better suited to sibling tools, leaving the agent to infer 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.
stockpile_levelARead-onlyIdempotentInspect
US Defense Logistics Agency (DLA) strategic stockpile check for 20 minerals. Returns whether held, quantity tonnes, and DLA stockpile status (active/disposed/not_held). Defense-contractor supply-chain agents use this to gauge DoD mineral security. Full data requires $0.25 USDC via GET /api/stockpile/{commodity} using x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | Yes | Mineral commodity slug. |
Output Schema
| Name | Required | Description |
|---|---|---|
| held | Yes | |
| status | Yes | |
| payment | Yes | |
| commodity | Yes | |
| paid_endpoint | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses payment requirement ($0.25 USDC via x402 on Base) and API endpoint, adding significant behavioral context beyond annotations. Aligns with readOnly, idempotent, and non-destructive hints.
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 front-loaded sentences convey purpose, output, target users, and payment details without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, comprehensive annotations, and existing output schema, the description fully covers tool behavior, use case, and special requirements.
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 enum and description. Description adds no extra semantic meaning beyond confirming '20 minerals' matches the enum list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks DLA stockpile for a mineral, returns held status, quantity, and stockpile status. It differentiates from sibling tools by focusing on DLA strategic stockpile.
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?
Identifies target users (defense-contractor supply-chain agents) and use case (gauge DoD mineral security), providing clear context. However, no explicit when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
supply_resilienceARead-onlyIdempotentInspect
Supply chain resilience score + scenario analysis for 20 critical minerals (graphite, cobalt, lithium, gallium, etc.). Returns a 0-100 score, vulnerability level, 5-factor breakdown (supply concentration, allied production, export restrictions, stockpile coverage, geopolitical criticality), and 3 scenario tests (China export ban, DLA depletion, allied disruption). Procurement agents and supply-chain strategists use this for vulnerability triage. Full data requires $0.50 USDC via GET /api/resilience/{commodity} using x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | Yes | Mineral commodity slug. |
Output Schema
| Name | Required | Description |
|---|---|---|
| payment | Yes | |
| commodity | Yes | |
| paid_endpoint | Yes | |
| resilience_level | Yes | |
| resilience_score | Yes |
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. The description adds behavioral context: it requires payment, returns a 0-100 score, vulnerability level, breakdown, and scenario tests. No contradictions 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?
Description is front-loaded with the main purpose and outputs, followed by usage and cost. It is somewhat long but every sentence adds value. Could be slightly more concise, but overall effective structure.
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 single parameter and presence of an output schema, the description covers key outputs, cost, and use case. It does not mention error handling or pagination but that's acceptable for a simple tool. Completeness is good for its 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 coverage is 100% with one parameter 'commodity' having an enum and description. The description lists some minerals but does not add significant meaning beyond the schema. Baseline 3 is appropriate because schema already provides clear semantics.
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 supply chain resilience score and scenario analysis for 20 critical minerals, with specific outputs (0-100 score, vulnerability level, 5-factor breakdown, scenario tests). While it lists target users and outputs, it does not explicitly differentiate from sibling tools like china_trade_control or stockpile_level, but the purpose is still very specific.
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?
Mentions target users (procurement agents, supply-chain strategists) and a payment requirement ($0.50 USDC via x402), but does not specify when to avoid this tool or provide alternatives among siblings. No exclusions or context for 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.
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!