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/5 across 7 of 7 tools scored.
Each tool targets a distinct function: benchmark commodity vs. runs, district history, extraction pipeline (estimate, run, result), and a Q&A tool. No overlapping purposes.
All tool names follow a consistent `category.operation` pattern with lowercase and dots, e.g., benchmark.commodity, extract.estimate, sales.ask.
7 tools is well-scoped for the server's purpose: mineral intelligence, benchmark data, extraction pipeline, and Q&A. Each tool earns its place without excess.
The tool set covers the full lifecycle: benchmark discovery and runs, district history with preview and paid access, extraction pipeline (estimate, run, result), and general Q&A. No obvious gaps.
Available Tools
7 toolsbenchmark.commodityARead-onlyIdempotentInspect
Discovery preview for USGS Mineral Commodity Summaries benchmark data (copper, gold, silver, lithium, cobalt, nickel, manganese, graphite). Returns available field names, on-chain provenance UIDs, and the paid REST endpoint. 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds context about the returned items and the paid endpoint, confirming it is a safe, non-destructive preview. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with clear structure: purpose, what is returned, and payment requirement. It is concise but could combine sentences to be even tighter. No fluff.
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 explains the tool's role as a preview and mentions the paid endpoint, but does not cover all 20 supported commodities or explain the x402 protocol further. Given that an output schema exists, the return format is covered elsewhere, so this is a minor 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 description coverage is 100%, but the description and schema parameter description list only 8 of the 20 enum values from the schema, creating a mismatch that could mislead the agent. The description adds no additional meaning beyond the incomplete list, and the incompleteness is a drawback.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Discovery preview' for USGS mineral commodity benchmarks and specifies that it returns field names, provenance UIDs, and the paid REST endpoint, differentiating it from sibling tools like benchmark.runs which likely return actual runs.
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 implicitly guides usage by indicating that full data requires payment via a separate endpoint, but does not explicitly compare to sibling tools or state when not to use this tool. It could be more explicit about being a discovery step rather than a data retrieval tool.
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.
district.historyARead-onlyIdempotentInspect
Free preview of a mining district record (MRDS-sourced). Returns field inventory, commodity summary, discovery year, and deposit count. 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?
The description adds significant context beyond the annotations: it confirms the free preview nature, lists what is returned, and explains the payment requirement for the full record. This is consistent with readOnlyHint=true and idempotentHint=true, and does not contradict any 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 consists of two concise sentences. The first sentence states the purpose and output; the second provides the alternative for full data. It is front-loaded, with no extraneous 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 the existence of an output schema and annotations, the description provides all necessary context: tool purpose, returned fields, and the condition for accessing full data. It is complete for an agent to decide whether to use this 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 covers all four parameters with descriptions (100% coverage). The description does not add additional semantics, format hints, or examples beyond what the schema provides. 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 a free preview of a mining district record with specific fields (field inventory, commodity summary, discovery year, deposit count). It distinguishes itself from the paid full record endpoint, and none of the sibling tools overlap in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (for a free preview) and when not to (for full record, which requires payment via a different endpoint). It names the alternative: 'GET /api/historical/{country}/{state}/{county}/{district} using x402 on Base.'
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: what commodities are covered, how on-chain provenance works, pricing tiers, x402 payment flow, MCP integration, or the Extract API. 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 (readOnlyHint: true, destructiveHint: false) align with the description's 'Free to call' and 'returns a natural-language answer from a small LLM'—no contradictions. Description adds valuable 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 purpose, no redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and an output schema. Description explains input, behavior, and output completely. 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 description for 'question'. The description adds example topics but no essential new 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's function: answering questions about the API. It lists example topics and specifies the output (natural-language answer). Sibling tools (e.g., extract.*) handle different concerns, distinguishing this 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 indicates it's for general API questions and mentions it's free to call. It doesn't explicitly state when not to use it or contrast with siblings, but the examples and context imply its use case.
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!