Verified CO2e for any transaction, activity, flight, shipment or CBAM import. 200+ countries.
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.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 2.9/5.
Each tool targets a distinct calculation or lookup task: CBAM liability (single and batch), emissions for specific activity types (activity, flight, freight, transaction), and separate lookups for carbon prices, CN codes, emission factors, and activity types. The batch versions are clearly differentiated from their single counterparts, and the CBAM tools are distinct from general emissions tools.
The naming pattern is predominantly verb_noun (calculate_* for calculations, lookup_* for lookups), but 'list_activity_types' uses 'list_' instead of 'lookup_', creating a minor inconsistency. Overall, the naming is predictable and readable.
With 11 tools, the server is well-scoped for its purpose. It provides adequate coverage for emissions calculations across major categories (activity, flight, freight, transaction), CBAM liability in single and batch form, and necessary lookups (carbon prices, CN codes, emission factors, activity types). No tool feels redundant.
The tool surface covers the core domain of carbon emissions calculations and CBAM compliance. It includes prerequisites for CBAM (CN code lookup, carbon price lookup), both single and batch calculations, and a range of emission calculation methods. There are no obvious dead ends or missing critical operations for the stated purpose.
calculate_cbam_batchAInspectCalculate 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.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Default compliance year applied to shipments without their own | |
| shipments | Yes | Array of up to 100 shipments | |
| ets_price_eur_per_tonne | No | Override the live EU ETS price for the whole batch |
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.
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.
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.
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.
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.
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.
calculate_cbam_liabilityAInspectCalculate CBAM (Carbon Border Adjustment Mechanism) embedded emissions and estimated EUR liability for an imported good. Covers Phase 1 sectors: cement, aluminium, iron & steel, fertilisers, hydrogen. Applies the year's phase-in rate (2.5% in 2026, ramping to 100% by 2032) and uses the live EU ETS price. The response gives TWO scenarios under cbam_obligation: 'without_own_mrv' (EU default values incl. a punitive mark-up — for exporters who have not verified their own emissions) and 'with_own_mrv' (verified actual emissions, no mark-up). Pass actual_emissions_tco2e_per_t (verified MRV figure) to populate the with_own_mrv scenario and the saving vs defaults; pass carbon_price_paid_eur_per_tonne to apply the Article 9 deduction (both scenarios) for carbon already priced at origin; pass project=true for a year-by-year forecast of both scenarios through 2034.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | CBAM compliance year (2026-2050). Determines phase-in rate and mark-up tier. | |
| cn_code | Yes | 8-digit EU Combined Nomenclature code, e.g. '25231000' for cement clinkers | |
| project | No | If true, includes a multi-year liability projection through 2034. | |
| weight_tonnes | Yes | Weight of the shipment in metric tonnes | |
| origin_country | Yes | ISO 3166-1 alpha-2 code of the manufacturing country, e.g. 'CN' for China | |
| ets_price_eur_per_tonne | No | Override the live EU ETS carbon price (EUR/tonne CO2e). | |
| actual_emissions_tco2e_per_t | No | Verified actual emission intensity (tCO2e per tonne). If provided, returns an optimization block comparing it against EU default values. | |
| carbon_price_paid_eur_per_tonne | No | Carbon price already paid in the country of origin (EUR/tonne CO2e). Applies the Article 9 deduction. | |
| carbon_price_rebate_eur_per_tonne | No | Rebate/compensation on the origin carbon price (EUR/tonne). Art. 9 requires the claim be net of rebates; deduction uses paid − rebate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it discloses live EU ETS price usage, phase-in rate ramp, punitive mark-up for unverified emissions, Article 9 deduction mechanism, and multi-year projection behavior. These are meaningful behavioral traits not inferable from the schema.
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 dense paragraph, but it is front-loaded with the core purpose and then systematically covers scenarios and parameter effects. Every sentence adds value, though slightly more formatting or bullet structure would improve scannability.
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 9 parameters, no output schema, and no annotations, this description is remarkably complete: it explains the two output scenarios, the phase-in timeline, the price source, deduction logic, parameter-triggered behaviors, and projection capability. It does not elaborate on errors or edge cases, but covers all essential operational aspects.
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?
Although the schema already describes all 9 parameters (100% coverage), the description adds crucial behavioral context: actual_emissions triggers an optimization block, carbon_price_paid applies Article 9, project enables forecasting, and ets_price overrides the live price. This goes well beyond the schema's property descriptions.
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 opens with a clear action verb and resource: 'Calculate CBAM embedded emissions and estimated EUR liability for an imported good.' It further specifies sectors, phase-in rates, and scenario distinction, which distinguishes it from siblings like batch calculations or emissions-only tools.
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 clear guidance on when to pass optional parameters ('Pass actual_emissions...', 'pass carbon_price_paid...', 'pass project=true') and explains the effect of each. However, it does not explicitly name alternatives or exclusions, leaving the choice versus siblings like calculate_cbam_batch implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_emissions_activityCInspectCalculate CO2e emissions for an activity (electricity, fuel combustion, materials, transport, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Reporting year | |
| country | No | ISO 3166-1 alpha-2 country code | GB |
| quantity | Yes | Activity quantity (positive, max 1,000,000) | |
| activity_type | Yes | Activity type slug (e.g. electricity_generated_kwh, natural_gas_kwh) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'calculate' without revealing any operational behavior such as the use of default emission factors, the meaning of the returned value (e.g., total CO2e in kg), or that country defaults to GB. The schema hints at parameters but the description adds no behavioral context beyond the calculation intent.
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, concise sentence that front-loads the primary action and includes helpful examples. Every word serves a purpose and there is no redundant 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?
The tool has four parameters and no output schema, yet the description provides no context about the return value (e.g., units, format), default behaviors (year, country), or how to ensure valid activity_type values. The minimal description is insufficient for a new agent to fully understand the tool's behavior beyond the schema, especially without annotations or sibling usage differentiation.
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 each parameter described, so the baseline is 3. The description adds minimal value by listing example activity types (electricity, fuel combustion, materials, transport) which partially maps to the activity_type parameter, but it does not explain formats, units, or relationships between parameters 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 calculates CO2e emissions for an activity, using a specific verb and resource with examples of activity types. It distinguishes from some siblings (flight, freight, transaction) via the parenthetical list, but does not explicitly mention that it handles single activities only, making a slight distinction gap with calculate_emissions_activity_batch.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention that this handles a single activity while calculate_emissions_activity_batch handles multiple, nor does it contrast with flight/freight/transaction tools. The caller must infer usage from the name and sibling list, which is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_emissions_activity_batchAInspectCalculate CO2e emissions for up to 100 activities in a single request. Each item is resolved in parallel. Items that fail validation or are not found return per-item errors without failing the whole batch.
| Name | Required | Description | Default |
|---|---|---|---|
| calculations | Yes | Array of up to 100 activity calculations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing parallel execution and per-item error handling without failing the batch. It does not, however, mention authentication, rate limits, or the exact success response structure.
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 the core purpose and followed by behavior. Every clause earns its place; 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 covers purpose, batch size, parallelism, and partial-failure behavior, which is substantial for a tool with no annotations and no output schema. The main omissions are a pointer to list_activity_types for valid activity_type slugs and a description of the successful result structure.
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% (id, year, country, quantity, activity_type all documented), so the baseline is 3. The description adds no extra parameter-specific 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 opens with a specific verb-object pair ('Calculate CO2e emissions') and scopes it to a batch of up to 100 activities, clearly distinguishing it from the single-item sibling tool calculate_emissions_activity.
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?
It clearly establishes the batch use case (up to 100 activities, parallel resolution) and the partial-failure mode, making it evident when an agent should choose this over the single-activity tool. However, it does not explicitly name alternatives or state 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.
calculate_emissions_flightBInspectCalculate CO2e emissions for a flight
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin IATA code (e.g. LHR) or latitude,longitude | |
| passengers | No | Number of passengers (default: 1) | |
| cabin_class | No | economy | premium_economy | business | first | |
| destination | Yes | Destination IATA code or UN/LOCODE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Calculate CO2e emissions for a flight.' It does not mention methodology, data sources, assumptions, output format, or any safety/read-only traits. This is essentially a restatement of the tool name.
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 sentence with no wasted words, which is good for conciseness. However, it offers no additional useful structure or detail beyond the bare purpose, so it does not reach a full 5.
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 tool is relatively simple with well-documented parameters, but there is no output schema and no annotations. The description does not explain return values, methodology, or edge cases, leaving some gaps for effective use.
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 description coverage is 100%, so each parameter already has a description. The tool description adds no additional meaning beyond what the schema provides. Baseline 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 calculates CO2e emissions for a flight, using a specific verb and resource. It distinguishes from sibling tools like calculate_emissions_freight and calculate_emissions_activity by specifying 'flight'.
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 usage for flight emissions but does not explicitly state when to use this tool over alternatives. No mention of alternatives or exclusions is present; the guidance is only implicit in the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_emissions_freightAInspectCalculate CO2e emissions for freight transport (sea, road, rail, or air cargo). Supports single-leg and multi-leg intermodal journeys. Locations accept UN/LOCODE (e.g. 'GBSOU'), IATA airport code (e.g. 'LHR'), free-text name (e.g. 'Southampton'), or lat/lon coordinates. For multi-leg journeys provide a legs[] array — weight_kg is shared across all legs.
| Name | Required | Description | Default |
|---|---|---|---|
| legs | No | Multi-leg/intermodal: array of up to 10 legs. When provided, top-level origin/destination/mode are ignored. | |
| mode | No | Transport mode — required for single-leg | |
| origin | No | Origin: UN/LOCODE (e.g. 'GBSOU'), IATA code (e.g. 'LHR'), or free-text name (e.g. 'Rotterdam') | |
| weight_kg | Yes | Cargo weight in kilograms | |
| origin_lat | No | Origin latitude — alternative to origin string | |
| origin_lon | No | Origin longitude — alternative to origin string | |
| destination | No | Destination: UN/LOCODE, IATA code, or free-text name | |
| vehicle_type | No | Vehicle type: sea: container|bulk|general|roro|vehicle_carrier|refrigerated|ropax|crude_tanker|product_tanker|chemical_tanker|lng_tanker|lpg_tanker — road: van — rail: freight_train — air: international|long_haul|short_haul|domestic | |
| destination_lat | No | Destination latitude | |
| destination_lon | No | Destination longitude |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states the calculation goal and the shared weight_kg across legs, but does not mention output units (e.g., kg CO2e), error behavior, or any side effects. For a read-only calculation tool, the omission of return format is a moderate gap.
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, front-loaded with the core purpose, followed by essential usage details and a single clarifying constraint. No wasted words, every sentence 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?
For a tool with 10 params and no output schema, the description covers the key selection and invocation aspects: modes, single vs multi-leg, location formats, and shared weight. It stops short of describing the return value or limitations, but given the schema's thorough parameter documentation, this is reasonably complete.
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%, so the baseline is 3. The description adds meaningful semantics beyond the schema: location types (UN/LOCODE, IATA, free-text, lat/lon) and the note that weight_kg is shared across legs. This helps the agent correctly construct multi-leg requests and understand location input flexibility.
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 begins with a specific verb + resource: 'Calculate CO2e emissions for freight transport' and enumerates supported modes (sea, road, rail, air). This clearly distinguishes it from sibling tools like calculate_emissions_flight (likely passenger air) and calculate_emissions_activity (generic activities).
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 clear usage context: it supports single-leg and multi-leg intermodal journeys, and explains when to use the legs[] array. It does not explicitly name alternative tools for exclusion, but the freight-specific scope and reference to 'multi-leg intermodal' effectively guide selection among the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_emissions_transactionAInspectCalculate CO2e emissions for a business transaction (spend-based)
| Name | Required | Description | Default |
|---|---|---|---|
| mcc | Yes | 4-digit MCC code (e.g. 5812 for restaurants) | |
| sic | No | SIC code (2-5 digits) | |
| isic | No | ISIC code (4 digits) | |
| nace | No | NACE code (e.g. 56.10) | |
| year | No | Reporting year (e.g. 2024) | |
| naics | No | NAICS code (6 digits) | |
| country | Yes | ISO 3166-1 alpha-2 country code (e.g. GB, US) | |
| bea_code | No | BEA sector code (5-7 alphanumeric) | |
| currency | Yes | ISO 4217 currency code (e.g. GBP, USD, EUR) | |
| spend_amount | Yes | Transaction spend amount | |
| display_currency | No | Output currency for display |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the calculation intent but does not mention whether the operation is read-only, has side effects, uses specific emission factor sources, or what the output structure is. This lack of context is a notable gap.
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?
One sentence that is front-loaded with the action and object, with no filler. It is appropriately concise for a simple calculation tool.
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 11 parameters and no output schema, the description could explain which codes are mutually exclusive or how the spend-based method works. However, the schema covers parameter descriptions, and the tool's scope is simple enough that the minimal description may suffice, though additional context about selecting classification codes would improve completeness.
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%, so all parameters have descriptions in the schema. The description adds no additional meaning beyond the schema, just the 'spend-based' hint. Baseline 3 applies.
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 uses a specific verb 'Calculate', resource 'CO2e emissions', and scope 'business transaction (spend-based)'. The parenthetical 'spend-based' distinguishes it from sibling tools like calculate_emissions_activity, flight, and freight, making the 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 term 'spend-based' implies the tool is for transaction spend data, but there is no explicit guidance on when to choose it over alternatives such as calculate_emissions_activity. No exclusions or named alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_activity_typesAInspectList available activity types for emission calculations, optionally filtered by country or category
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Filter by ISO country code (e.g. GB, DE, SG) | |
| category | No | Filter by category (e.g. energy, transport, materials, fuel_combustion) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that filtering is optional, implying all results are returned when no filters are provided, which is useful. However, it omits details about response format, pagination, or error handling on invalid inputs, leaving some gaps.
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, front-loaded sentence with no redundancy. Every word contributes to conveying the tool's purpose and filter capability, making it highly concise and efficient.
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 tool is simple (two optional string params, no output schema) and the description covers purpose and filters. However, it does not specify what fields the returned list contains or explicitly connect to sibling calculation tools, leaving moderate ambiguity about the full context.
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% with both parameters having descriptive examples (e.g., GB, DE, SG for country; energy, transport for category). The description adds no new param-specific meaning beyond what the schema already provides, so the baseline of 3 applies.
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 uses a specific verb 'List' with a clear resource 'activity types' and context 'for emission calculations', making its purpose unmistakable. It also mentions optional filters (country or category), which further distinguishes it from sibling calculation tools.
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 usage for retrieving valid activity types used in emission calculations, but it does not explicitly contrast with alternatives like lookup_emission_factors or provide when/when-not guidance. The context is present but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_cbam_carbon_pricesAInspectLook up the carbon price(s) in a country (World Bank Carbon Pricing Dashboard) as an INDICATIVE starting figure for the carbon_price_paid_eur_per_tonne input on calculate_cbam_liability. Returns instrument name, type (ETS/carbon tax), price in USD and indicative EUR, and year. Not the claimable Article 9 value — the importer must report the price actually paid on their goods with proof. A country with no result has no implemented carbon price (a common reason it is CBAM-exposed).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by instrument: 'ets' or 'carbon tax' | |
| status | No | Default 'implemented'; pass 'all' to include abolished schemes | |
| country | No | ISO 3166-1 alpha-2 country code (or 'EU'), e.g. 'CN', 'KR', 'GB' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return fields (instrument name, type, price in USD/EUR, year), the indicative nature, and the meaning of a missing result. It does not mention rate limits or authentication, but for a read-only lookup tool this is adequate.
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, each earning its place. It is front-loaded with the main action, followed by output details, then critical caveats. No filler or 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 no output schema, the description lists the return fields and adds crucial interpretative context (indicative vs. claimable, no-result meaning). This is sufficient for an agent to select and invoke the tool correctly.
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%, so the baseline is 3. The description does not add extra meaning to the input parameters beyond what the schema already provides; it focuses on the output and usage context. No further credit is warranted.
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 opens with a specific verb and resource: 'Look up the carbon price(s) in a country (World Bank Carbon Pricing Dashboard)'. It clearly distinguishes itself by linking to a specific input on calculate_cbam_liability and explicitly stating it is not the Article 9 claimable value, setting it apart from potential sibling lookups.
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?
Explicit when-to-use guidance is provided: 'as an INDICATIVE starting figure for the carbon_price_paid_eur_per_tonne input on calculate_cbam_liability'. It also gives a when-not: 'Not the claimable Article 9 value', and explains that no result means no implemented carbon price, which is vital context for interpreting the tool's output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_cbam_cn_codesAInspectLook up / search EU Combined Nomenclature (CN) codes for CBAM. Find the 8-digit code for a product, check whether it is currently subject to CBAM (cbam_phase1=true) and which sector, then pass the cn_code to calculate_cbam_liability.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search by code prefix or description, e.g. 'steel', 'cement', '7206' | |
| limit | No | Max results (default 100, max 1000) | |
| sector | No | Filter: cement | aluminium | iron_steel | fertilisers | hydrogen | |
| cbam_only | No | Default true (CBAM Phase 1 codes only). Pass false to search all 9,812 CN 2026 codes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the core behavior: searching by code or description, finding the 8-digit code, and determining CBAM status and sector. However, it does not mention return format, error handling, pagination, or rate limits, leaving some gaps in transparency.
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, comprising two sentences that front-load the purpose and then outline the workflow. Every clause adds value, from 'look up / search' to 'pass the cn_code to calculate_cbam_liability', with 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 the tool's simplicity and a rich schema, the description is largely complete. It communicates the search process and implied result fields (code, CBAM status, sector). The lack of an output schema means the return structure is not explicitly described, but the description still provides enough context for basic 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 input schema covers all 4 parameters with 100% description coverage, including examples and defaults. The description adds only the workflow context of passing cn_code to calculate_cbam_liability, which is useful but does not enhance parameter-level semantics beyond what the schema already provides.
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: looking up EU CN codes for CBAM, finding the 8-digit code, checking CBAM phase 1 status and sector, and passing the code to calculate_cbam_liability. This specific verb+resource combination distinguishes it from siblings like lookup_cbam_carbon_prices and lookup_emission_factors.
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 clear context for when to use this tool: as the precursor to calculate_cbam_liability, for checking CN codes and CBAM status. It implicitly excludes other lookup tools by focusing on CN code search, but does not explicitly name alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_emission_factorsBInspectLook up emission factors by classification code (MCC, NAICS, ISIC, SIC, NACE, BEA) or activity type
| Name | Required | Description | Default |
|---|---|---|---|
| mcc | No | 4-digit MCC code | |
| sic | No | SIC code (2-5 digits) | |
| isic | No | ISIC code (4 digits) | |
| nace | No | NACE code | |
| naics | No | NAICS code (6 digits) | |
| country | Yes | ISO 3166-1 alpha-2 country code | |
| bea_code | No | BEA code | |
| currency | No | Currency for spend-based lookup | |
| activity_type | No | Activity type slug | |
| activity_unit | No | Activity unit | |
| activity_quantity | No | Activity quantity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'look up' suggests a read-only operation, it does not disclose what happens when multiple codes are supplied, the return format, error behavior, or any auth requirements. Minimal 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?
A single sentence that front-loads the verb and resource, lists the codes efficiently, and contains zero filler. Perfectly sized for the purpose.
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 11 parameters, no annotations, and no output schema, the description only lists lookup criteria. It does not state that country is required, explains how to combine codes with currency or activity_quantity, or describe the expected result. The tool is complex, and the description is too thin.
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 the schema already documents each parameter. The description adds a high-level grouping of codes and activity type but does not explain how they interrelate (e.g., precedence, whether either a code or activity_type is required). 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 uses a specific verb ('look up') and resource ('emission factors'), and enumerates the classification codes (MCC, NAICS, ISIC, SIC, NACE, BEA) plus activity type. This clearly distinguishes it from sibling calculation tools.
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 use for retrieving emission factors, which contrasts with the calculate_* siblings, but it does not explicitly name alternatives or state when to use this tool over them. No exclusions or when-not-to-use guidance is given.
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.
No comments yet. Be the first to start the discussion!