Skip to main content
Glama

Get CBAM default emission values

cbam_get_default_values
Read-onlyIdempotent

Returns official CBAM default embedded emissions (tCO2e per tonne) for a CN/TARIC code, origin country and year, from the Commission's implementing act, with markup, gross EUR per tonne and the certificate price used. Use it to estimate CBAM cost for a product; use cbam_get_certificate_price for the price alone and cbam_list_countries to see which countries have their own table. Inputs: cn (required, CN/TARIC code or prefix, 2 to 10 digits, spaces and dots ignored, e.g. 7208 or 2523900010), country (optional, two-letter ISO code such as IN, default OTHER; UNKNOWN selects the Annex IV precursor values) and year (optional, 2026 to 2100, default the current year). A prefix expands to at most 100 matches; truncated says rows were left out. Output: matches[] with code, description, direct emissions, markup, gross EUR per tonne, plus certificate_price and regulation sources. Indirect emissions and electricity are excluded. A code outside CBAM returns the error not_a_cbam_good. Values are bundled from the cited acts, not live CBAM Registry figures. Covers 283 CN codes and 121 country tables from Implementing Regulation (EU) 2026/1740, which replaced the 2025/2621 annexes; mark-up 10% for 2026, 20% for 2027, 30% from 2028; 1% for fertilisers. Terms: read-only; MCP calls are never charged. Without a key, metered routes give 10 successful answers a day free, as short samples (up to 3 records, without file proof, history or paging cursor) where a paid HTTP address exists (unmetered routes are unlimited); errors do not count. On the paid HTTP routes, errors are free, and so are empty answers except a sanctions name search with no match when every loaded list it checks is fresh (lists not loaded yet are named in the answer). An optional API key keeps its prepaid-credit policy. When the free answers run out, the error names the HTTP alternative.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cn": "<cn>"
    },
    "name": "cbam_get_default_values"
  }
}

Input Schema

NameRequiredDescriptionDefault
cnYesCN/TARIC code or prefix, 2 to 10 digits after removing spaces and dots; e.g. 7208 or 2523900010
yearNoFour-digit year, 2026 to 2100 inclusive, e.g. 2026; defaults to current UTC year (at least 2026)
countryNoOrigin: two-letter ISO code (case-insensitive), e.g. IN, or OTHER (default), or UNKNOWN for Annex IV

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, but the description adds substantial context beyond them: data is bundled from cited implementing acts rather than live CBAM Registry figures, indirect emissions and electricity are excluded, a prefix expands to at most 100 matches with truncation flagged, and non-CBAM codes return the error not_a_cbam_good. It also discloses the coverage scope (283 CN codes, 121 country tables) and the mark-up schedule.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded paragraph and the core call information comes first, which is good. However the tail drifts into metering boilerplate that does not help select or invoke this tool, including an aside about 'a sanctions name search with no match' that belongs to an entirely different tool family.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only lookup with no output schema, the description covers inputs, defaults, output shape (matches[] fields plus certificate_price and regulation sources), known error codes, and the key limitation that values are bundled rather than live. An agent has everything needed to call it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: prefix expansion behaviour with a 100-match cap, that spaces and dots are ignored, and that country=UNKNOWN selects the Annex IV precursor values rather than a country table. The year range and default are repeated from the schema rather than extended, which keeps it off a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb and resource ('Returns official CBAM default embedded emissions (tCO2e per tonne)') and enumerates the exact inputs that select them (CN/TARIC code, origin country, year). It explicitly distinguishes itself from the two CBAM siblings, cbam_get_certificate_price and cbam_list_countries, so an agent can route without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the primary use case ('use it to estimate CBAM cost for a product') and then names both alternatives with the condition that selects each: cbam_get_certificate_price 'for the price alone' and cbam_list_countries 'to see which countries have their own table'. That is explicit when-to-use and when-to-use-something-else guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.