Aluminum MCP Servers: LME, Premiums, and Alloy Intelligence
Aluminum prices and purchasing decisions rarely start and end with an exchange print. Companies need to know what aluminum costs at the relevant commercial point:
- The underlying LME price
- The applicable regional premium (example: Midwest Premium)
- The material form
- Any defined commercial adders
MetalMiner’s aluminum MCP server returns those components as separate structured values. An AI agent can then build a delivered aluminum cost instead of mistaking a benchmark for an invoice-equivalent number.
That distinction decides whether a downstream number can be trusted. The LME aluminum price measures the exchange component. The Midwest Premium measures a separate regional component. Neither represents the full price of metal arriving at a plant.
The calling application explicitly combines them, preserves their provenance, and then adds contract-specific conversion, freight, duty, scrap, or fabrication terms. Those adders, not the market data, separate a benchmark from a landed cost.
Why Must One Call Return Components Instead of a Blended Number?
Because the two components move independently, merging them hides where cost variance came from. The most common aluminum-pricing error labels an LME value as “aluminum price” and treats it as payable. The reverse error is equally damaging: using a premium-inclusive quotation as a universal benchmark for aluminum. A single figure cannot tell a planner whether cost moved on the exchange or in the regional physical market.
A component-preserving response keeps the economic roles explicit:
- LME field: the global exchange-linked base-metal component.
- Premium field: the regional physical-market component.
- Calculated total: only the sum of those two, on a stated basis.
A purchasing system can then map each component to the corresponding supplier-agreement term, or flag the calculation as incomplete when a required term is absent.
That mapping is where the design pays off. An LME-indexed clause and a premium clause reprice through different mechanisms, so a contract exposed to both needs each to be tracked separately. Typed fields also let an AI agent ask the right follow-up question.
If a user requests “delivered 6061 sheet cost,” the agent should not invent a conversion charge or freight rate. It should return the components it has, name the missing commercial inputs, and distinguish a benchmark subtotal from a contract-ready delivered cost.
How Should an Agent Request Those Components for Aluminum Prices?
As a price package for a defined requirement, such as primary aluminum into the Midwest Premium on a three-month basis in a selected unit and currency. The response returns the LME and regional-premium components as separate typed values, each with its own unit, currency, observation date, series identity, and basis.
The result may also include a calculated all-in market component, but that field stays derivative: it names the formula and the two source values behind it. An application can then audit the result, restate it in another unit, or substitute a specific term.
For a U.S. primary-aluminum inquiry, the market-component calculation is:
All-in market component = LME aluminum price + (Midwest Premium × 2,204.62)
The formula holds when the LME value is expressed in U.S. dollars per metric ton and the Midwest Premium in U.S. cents or dollars per pound. The application must normalize units before addition. A field expressed in $ / lb cannot be added directly to one expressed in $ / metric ton. An unnormalized addition does not round the number; it distorts it.
What Does a Component-Preserving Response Look Like?
Two non-substitutable fields, each with explicit units and provenance. The example below is illustrative schema, not production documentation: field names, endpoint names, authentication syntax, and response nesting require confirmation, and placeholders stand in for unverified values.
{
"tool": "[CONFIRM: aluminum_delivered_cost]",
"arguments": {
"region": "US Midwest",
"pricing_basis": "LME 3-month",
"product_form": "primary aluminum",
"currency": "USD",
"unit": "metric_ton",
"as_of_date": "[CONFIRM: YYYY-MM-DD]"
}
}
{
"as_of": "[CONFIRM: timestamp]",
"request_basis": {
"region": "US Midwest",
"pricing_basis": "LME 3-month",
"currency": "USD",
"unit": "metric_ton"
},
"lme_price": {
"value": "[CONFIRM: numeric value]",
"currency": "USD",
"unit": "metric_ton",
"series": "LME aluminum three-month",
"observation_date": "[CONFIRM: date]"
},
"regional_premium": {
"value": "[CONFIRM: numeric value]",
"currency": "USD",
"unit": "pound",
"series": "U.S. Midwest Premium",
"observation_date": "[CONFIRM: date]"
},
"calculated_market_component": {
"value": "[CONFIRM: numeric value]",
"currency": "USD",
"unit": "metric_ton",
"formula": "lme_price + regional_premium * 2204.62",
"includes": ["LME aluminum", "Midwest Premium"],
"excludes": [
"conversion",
"fabrication",
"freight",
"taxes",
"duties",
"buyer-specific contract adjustments"
]
},
"data_quality": {
"series_status": "[CONFIRM: field/value]",
"calculation_status": "[CONFIRM: field/value]"
}
}
The JSON nesting is not the essential requirement. The separation of lme_price and regional_premium is. The excludes list does the same work, naming what still stands between this subtotal and the landed number. The calling application performs the conversion, records the formula, and maintains that list.
Which Aluminum Data Can the Agent Reach?
Coverage begins with the LME three-month aluminum benchmark and the U.S. Midwest Premium series, retaining alloy- and product-specific detail where the data support it. MetalMiner carries both series as active, with history back to 2010 for LME aluminum and 2013 for the U.S. Midwest Premium futures series. Exact start dates, coverage rules, and entitlement behavior belong in the production schema.
The broader aluminum universe also includes alloy- and form-specific series. MetalMiner’s data covers aerospace aluminum across 7050, 7075, and 7475 in bar, sheet, and plate forms, plus 6063 billet in India. Alloy specifications and forms are commercial products, not arithmetic variations of primary aluminum. An agent should resolve a requested alloy series directly where available. It should never derive an alloy price from an assumed spread, which breaks down exactly when the market moves.
The same discipline applies across MetalMiner’s major metals coverage:
- Steel: distinguish hot rolled coil from downstream products.
- Copper: preserve the exchange benchmark and any relevant regional basis.
- Stainless: avoid collapsing nickel exposure, alloy surcharges, and finished-product pricing into one unsupported number.
- Critical minerals: product form, such as concentrate, chemical, metal, or precursor, can define the market itself.
Which Tools Does the Server Expose?
A narrow set of composable tools rather than one catch-all endpoint, each returning a stable, documented schema. The names below are proposed labels and must be reconciled with the final implementation.
Region is commercial material, not decorative metadata. “United States” is not interchangeable with “U.S. Midwest,” Rotterdam, or Japan, because each names a different delivery point. Alloy and product_form should be optional only for a primary-metal benchmark. When a query names the 7075 plate, the server should not silently fall back to an undifferentiated LME value without declaring the fallback.
How Does the Server Handle History and Forecasts?
Historical series support daily, weekly, and monthly retrieval where the series permits, with a user-selected date range, currency, and unit. The response should identify whether it returns raw observations, an aggregated summary, or both, and should preserve source-series status. A degraded series requires different application behavior than an active one. An agent that silently reuses a stale observation carries it into every figure built on it.
Forecasts belong on the page as a separate forward-looking surface, not a continuation of observed price history. Forecast coverage varies by series. The LME aluminum and Midwest Premium three-month futures series each show forecast capability, as do certain aerospace aluminum series. Final documentation should specify which forecast products, horizons, confidence outputs, and access tiers the MCP Server exposes.
How Is the Client Configured and Authenticated?
Only as engineering confirms it. Do not publish a protocol, endpoint, header, or token pattern before that point. The block below is a documentation template for a hosted MCP connection.
{
"mcpServers": {
"metalminer-aluminum": {
"transport": "[CONFIRM: streamable-http | sse | stdio]",
"url": "[CONFIRM: hosted MCP endpoint]",
"headers": {
"Authorization": "Bearer ${METALMINER_API_KEY}"
}
}
}
}
Document each of these precisely, and only after compatibility testing:
- Supported clients: Claude desktop, Claude Code, Cursor, VS Code extensions, or internal agent frameworks.
- Authentication mechanism: API keys, OAuth, organization-scoped tokens, IP allowlisting, or another method.
- Secret handling: token rotation and whether secrets stay local to the client configuration.
Quickstart
- Obtain credentials through [Get API Key].
- Add the confirmed MCP configuration to the chosen client.
- Ask for a defined commercial basis: “Return LME aluminum and the Midwest Premium for a U.S. Midwest primary-aluminum purchase in USD per metric ton.”
- Confirm the response includes separate LME and premium fields, with dates, units, and sources.
- Provide buyer-specific conversion, freight, or contract terms only if you need a full delivered-cost calculation.
- For alloy requirements, specify alloy and form, such as 7075 plate, rather than generic “aluminum.”
FAQ
Which Premium Regions Does the MetalMiner Aluminum MCP Server Cover?
MetalMiner’s available aluminum premium series include U.S. Midwest, Rotterdam, and Japan in the current data catalog. Final documentation should state the exposed regions, whether each supports spot and/or forward pricing, and its quote basis.
How Often Does the Data Refresh?
[CONFIRM: refresh cadence by series and by tool.] The documentation should distinguish the source observation date from the MCP response timestamp. Those are different fields and should not be conflated.
How Much History Is Available?
MetalMiner metadata shows LME aluminum history from 2010 and U.S. Midwest Premium futures history from 2013 for the active series identified above. [CONFIRM: retention policy, raw-history entitlement, and maximum query window.]
What Are the Rate Limits?
[CONFIRM: requests-per-minute, concurrency limit, burst behavior, quota model, and error-response format.] Rate-limit documentation should include a retry recommendation and a machine-readable error code.
What Happens When a Region Is Not Specified?
The server should not assume the Midwest Premium. It should return the requested LME benchmark where appropriate, mark the regional premium as unresolved, or return [CONFIRM: region-required validation response]. Defaulting to a regional premium creates a false estimate of delivered cost.
Build an Aluminum Agent That Keeps the Price Components Honest
Aluminum purchasing requires more than a benchmark lookup. It requires knowing what the benchmark represents, what the regional premium represents, and which commercial terms sit outside the market-data response.
An agent built from separate components can tell a planner which part of the cost moved and which contract clause corresponds to it. One built on a blended number can only report that something changed. MetalMiner’s aluminum MCP server supports the first case, and the same rigor extends to steel, copper, stainless, and critical-minerals workflows.