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.4/5 across 9 of 9 tools scored. Lowest: 3.7/5.
Each tool targets a distinct data type or action: benchmarks for commodities/runs/sample, corpus for full-text search, district for history, extract for document processing steps, and sales for Q&A. No functional overlap.
Uses dot notation with category prefixes (benchmark, corpus, district, extract, sales). Within each category, naming is consistent (e.g., benchmark.commodity, benchmark.runs; extract.estimate, extract.result). Minor mixing of verb/noun across categories (sales.ask vs district.history) but still predictable.
9 tools cover the core workflows: data discovery (benchmark, district, corpus), document extraction (estimate, run, result), and API guidance (sales). Well-scoped for the domain without bloat.
Provides a complete workflow: free previews to evaluate data, paid endpoints for full data, extraction from documents with estimation and result retrieval, and a Q&A tool for API usage. No obvious gaps for the stated purpose.
Available Tools
9 toolsbenchmark.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.
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.
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.
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.
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.
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!