Skip to main content
Glama

calculate_cbam_batch

Calculate CBAM liability for up to 100 shipments in one request and return a portfolio-level summary (total embedded tCO2e, total certificates, total EUR liability). Ideal for pricing a whole shipment manifest or product catalogue. Per-item ok/not_covered/error — one bad item doesn't fail the batch. Each shipment supports actual_emissions_tco2e_per_t and carbon_price_paid_eur_per_tonne.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoDefault compliance year applied to shipments without their own
shipmentsYesArray of up to 100 shipments
ets_price_eur_per_tonneNoOverride the live EU ETS price for the whole batch

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden. It discloses the summary output structure, per-item ok/not_covered/error statuses, and supported fields. Lacks explicit mention of auth/rate limits, but for a calculation tool the behavioral disclosure is solid.

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

Conciseness5/5

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

Three sentences, each adding distinct value: batch capability, use case, and key supported fields. Front-loaded with the core purpose, no redundant wording.

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?

No output schema exists, but the description explicitly lists return value components: total embedded tCO2e, total certificates, total EUR liability, and per-item statuses. This is sufficient for a batch calculation tool with clear input schema.

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

Parameters3/5

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

Schema has 100% coverage for all 3 parameters. Description only reiterates actual_emissions_tco2e_per_t and carbon_price_paid_eur_per_tonne without adding new meaning beyond schema. Baseline 3 applies because schema does the heavy lifting.

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?

Description uses a specific verb and resource: 'Calculate CBAM liability for up to 100 shipments in one request', clearly distinguishing from single-shipment siblings. It also states the output is a portfolio-level summary, reinforcing the batch scope.

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?

Provides explicit ideal-use context: 'Ideal for pricing a whole shipment manifest or product catalogue'. It also explains batch fault-tolerance behavior ('one bad item doesn't fail the batch'), which is a key differentiator from single-item tools.

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.

Resources