SiteCheck Trade & Energy

Freight CO2e emissions for a shipment: tonnes × distance ×

logistics_co2_freight_emission

Read-only

Freight CO2e emissions for a shipment: tonnes × distance (km) × the UK Government (DESNZ) 2025 greenhouse-gas conversion factor for the chosen mode — van, HGV, refrigerated HGV, air freight (with or without radiative forcing), rail, tankers or cargo ships by vessel type and size. Returns kg CO2e per matching factor. Uses DESNZ factors (aligned with the GHG Protocol), not the GLEC tool itself. Related tools on this server, for a different need: logistics_freight_forwarder_dir when you need FIATA member freight forwarders by country from FIATA's; logistics_rail_freight_corridor when you need US Class I rail traffic: carloads or intermodal units per. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "mode": "<mode>",
      "tonnes": "<tonnes>",
      "km": "<km>"
    },
    "name": "logistics_co2_freight_emission"
  }
}

Input Schema

Name	Required	Description
`km`	Yes	Distance in km, e.g. 18000 (required)
`mode`	Yes	Transport mode: van, hgv, hgv-refrigerated, air, rail, sea-tanker, cargo-ship (required)
`type`	No	Optional words to pick the vehicle/vessel row, e.g. 'articulated average', 'container ship 8000+', 'long-haul with rf' (default: rows marked Average where published)
`tonnes`	Yes	Cargo weight in tonnes, e.g. 20 (required)

Output Schema

Name	Required	Description	Default
`km`	No
`mode`	No
`count`	No
`source`	No
`tonnes`	No
`results`	No
`tonneKm`	No
`factorSet`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already mark it read-only and open-world, so the bar is lower; the description still adds real value by naming the factor source (DESNZ 2025, GHG Protocol aligned) and disclosing pricing ($0.002 USDC per successful call via x402, failed calls free). It does not explain how the optional 'type' match resolves when no row matches, which is the main residual gap.

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?

The core formula is front-loaded, which is good, but the trailing sibling-tool sentences are truncated mid-phrase ('from FIATA's', 'intermodal units per') and read as boilerplate noise. The pricing sentence is worth keeping; the sibling snippets are not.

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

Completeness4/5

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

For a 4-parameter calculation tool with a full schema and an output schema, the description supplies source provenance, supported modes, cost, and sibling routing — enough to call it correctly. Only the edge case of unmatched 'type' descriptors is left unaddressed.

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; the description adds meaning by expanding 'mode' into a prose list including the radiative-forcing variant for air freight and vessel-type/size selection for ships, which the schema's flat enum-less string listing conveys less fully. It still doesn't explain the row-matching fallback for 'type'.

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?

Names a specific computation (tonnes × km × DESNZ 2025 conversion factor) and the output unit (kg CO2e), and enumerates the supported modes. An agent can tell this is an emissions-calculator tool and not a data-feed tool like its siblings.

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

Usage Guidelines4/5

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

Explicitly routes two adjacent needs elsewhere (logistics_freight_forwarder_dir for FIATA forwarders, logistics_rail_freight_corridor for US Class I rail traffic) and clarifies it uses DESNZ factors rather than GLEC. It does not state when a caller should pick a different emissions source (e.g. energy_epa_flight_emissions), so guidance is clear but not exhaustive.

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

All SiteCheck Trade & Energy tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?