Skip to main content
Glama

Emissions report over many shipments

emissions_report
Read-onlyIdempotent

Calculates shipments and returns a report with the basic content ISO 14083 asks for at the level of transport services (GLEC v3.3 Section 2 Ch.1): coverage and failures, totals split into TTW and WTT, intensity, per mode and hub type, energy carriers, data quality (primary/modelled/default shares, sources, models), distance adjustments, and notes. Returned as Markdown and as structured data.

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": {
      "shipments": "<shipments>"
    },
    "name": "emissions_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNoReport title
period_toNoEnd of the period covered, YYYY-MM-DD
referenceNoWhere supporting information can be found
shipmentsYesThe shipments. Without an API key the public service takes up to 100 per call; with one, up to 10,000.
declare_isoNoAdd the ISO 14083:2023 conformity statement. Only when the user explicitly confirms that their data collection and boundaries conform.
period_fromNoStart of the period covered, YYYY-MM-DD
organisationNoOrganisation the report is for
add_road_legsNoAdd road legs where the legs don't join up (gaps over 5 km), and to a port or terminal when a sea, rail or river leg starts or ends off its network (default true). Added legs are marked in the result.
scope3_categoryNoGHG Protocol scope 3 category of this transport for the user's company: 4 if it pays for the transport (inbound or outbound), 9 for its sold products moved by transport it doesn't pay for. Ask; leave out if unknown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / shipments / items / properties / legs / items / properties / cargo_type
      Added value: +{
      +  "description": "Optional: this leg's GLEC cargo category, instead of the shipment's (same values as the shipment's cargo_type)",
      +  "type": "string"
      +}
  2. Changed4 schema fields changed
    • changedInput schema / properties / shipments / items / properties / legs / items / properties / fuel / properties / factor / properties / ttw_kg_per_unit / description
      Previous value: -"Tank-to-wheel kg CO2e per unit (part of WTW)"New value: +"Tank-to-wheel kg CO2e per unit (part of WTW; 0 only for electricity). Required: ask the user if missing"
    • changedInput schema / properties / shipments / items / properties / legs / items / properties / fuel / properties / factor / required
      Previous value: -[
      -  "unit",
      -  "wtw_kg_per_unit",
      -  "source"
      -]New value: +[
      +  "unit",
      +  "wtw_kg_per_unit",
      +  "ttw_kg_per_unit",
      +  "source"
      +]
    • changedInput schema / properties / shipments / items / properties / legs / items / properties / own_factor / properties / ttw_g_per_tkm / description
      Previous value: -"Tank-to-wheel g CO2e per tonne-km (part of WTW)"New value: +"Tank-to-wheel g CO2e per tonne-km (part of WTW; 0 only when no fuel is burnt in the vehicle, e.g. electric). Required: ask the user if missing"
    • changedInput schema / properties / shipments / items / properties / legs / items / properties / own_factor / required
      Previous value: -[
      -  "wtw_g_per_tkm",
      -  "source"
      -]New value: +[
      +  "wtw_g_per_tkm",
      +  "ttw_g_per_tkm",
      +  "source"
      +]
  3. Changed3 schema fields changed
    • addedInput schema / properties / shipments / items / properties / legs / items / properties / fuel / properties / factor
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "The fuel supplier's own emission factor, instead of the dataset's (fuel is then just its name).",
      +  "properties": {
      +    "biogenic_co2_kg_per_unit": {
      +      "description": "Biogenic CO2 per unit, reported apart (optional)",
      +      "type": "number"
      +    },
      +    "source": {
      +      "description": "Who gives the factor, and for what",
      +      "type": "string"
      +    },
      +    "ttw_kg_per_unit": {
      +      "description": "Tank-to-wheel kg CO2e per unit (part of WTW)",
      +      "type": "number"
      +    },
      +    "unit": {
      +      "description": "Unit of amount, e.g. l, kg, kWh",
      +      "type": "string"
      +    },
      +    "wtw_kg_per_unit": {
      +      "description": "Well-to-wheel kg CO2e per unit",
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "unit",
      +    "wtw_kg_per_unit",
      +    "source"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / shipments / items / properties / legs / items / properties / own_factor
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "The carrier's or the user's own intensity for this leg (primary data), instead of a default value. Only with a figure the user gave; never estimate one.",
      +  "properties": {
      +    "distance_basis": {
      +      "description": "Distance type the intensity is per tonne-km of; leave out if it matches the leg's",
      +      "enum": [
      +        "sfd",
      +        "gcd",
      +        "actual"
      +      ],
      +      "type": "string"
      +    },
      +    "source": {
      +      "description": "Who measured it, and for what (e.g. the carrier's report and year)",
      +      "type": "string"
      +    },
      +    "ttw_g_per_tkm": {
      +      "description": "Tank-to-wheel g CO2e per tonne-km (part of WTW)",
      +      "type": "number"
      +    },
      +    "wtw_g_per_tkm": {
      +      "description": "Well-to-wheel g CO2e per tonne-km",
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "wtw_g_per_tkm",
      +    "source"
      +  ],
      +  "type": "object"
      +}
    • changedInput schema / properties / shipments / items / properties / legs / items / required
      Previous value: -[
      -  "mode",
      -  "vehicle_type"
      -]New value: +[
      +  "mode"
      +]
  4. Changed1 schema field changed
    • addedInput schema / properties / shipments / items / properties / cargo_type
      Added value: +{
      +  "description": "Optional, GLEC v3.3 cargo or load category: container, temperature_controlled, light, heavy, or for European rail cars, chemicals, coal_steel, building_materials, manufactured_products, cereals, truck_trailer_on_train, trailer_on_train. Picks GLEC's value for it where GLEC has one for the leg's vehicle; otherwise the vehicle's own value (the leg's note says which).",
      +  "type": "string"
      +}
  5. Changed2 schema fields changed
    • changedInput schema / properties / shipments / items / properties / hubs / description
      Previous value: -"Hub stops: hub_type transshipment, storage_transshipment, warehouse or liquid_bulk_terminal (add _mixed for ambient and temperature-controlled sites); GLEC v3.3 Table 3 values per tonne."New value: +"Hub stops: hub_type transshipment, storage_transshipment, warehouse or liquid_bulk_terminal (add _mixed for ambient and temperature-controlled sites), per tonne; intermodal_terminal or intermodal_terminal_temperature_controlled, per container (give containers). GLEC v3.3 Table 3."
    • addedInput schema / properties / shipments / items / properties / hubs / items / properties / containers
      Added value: +{
      +  "description": "Containers handled, for intermodal terminals",
      +  "type": "number"
      +}
  6. Changed1 schema field changed
    • changedInput schema / properties / shipments / items / properties / hubs / description
      Previous value: -"Hub stops (transhipment, storage); needs a dataset with hub factors."New value: +"Hub stops: hub_type transshipment, storage_transshipment, warehouse or liquid_bulk_terminal (add _mixed for ambient and temperature-controlled sites); GLEC v3.3 Table 3 values per tonne."
  7. Changed2 schema fields changed
    • addedInput schema / properties / scope3_category
      Added value: +{
      +  "description": "GHG Protocol scope 3 category of this transport for the user's company: 4 if it pays for the transport (inbound or outbound), 9 for its sold products moved by transport it doesn't pay for. Ask; leave out if unknown.",
      +  "enum": [
      +    4,
      +    9
      +  ],
      +  "type": "integer"
      +}
    • addedInput schema / properties / shipments / items / properties / legs / items / properties / repositioning_km
      Added value: +{
      +  "description": "Trucks: km driven empty for this trip (to the pickup or back), shared over the truck's load like empty running. Without a load, the shipment is taken as the whole load.",
      +  "type": "number"
      +}
  8. Changed2 schema fields changed
    • changedInput schema / properties / shipments / items / properties / container_load / description
      Previous value: -"With teu: a container load profile defined by the dataset, instead of teu_net_tonnes"New value: +"With teu, instead of teu_net_tonnes: average (10 t), light (6 t) or heavy (14.5 t) per TEU, from the GLEC Framework"
    • changedInput schema / properties / shipments / items / properties / teu / description
      Previous value: -"Containers in TEU, instead of weight_kg; needs teu_net_tonnes"New value: +"Containers in TEU, instead of weight_kg; with teu_net_tonnes, or alone for GLEC's average of 10 t per TEU"
  9. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, closed-world profile, so the description's job is to add operational context — and it does: it discloses that results come back as both Markdown and structured data, and the schema text reveals throughput limits (100 shipments unauthenticated, 10,000 with a key) and that auto-added road legs are flagged in the result. Remaining gaps are minor, e.g. how failures are surfaced in the payload.

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

Conciseness4/5

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

Two sentences, front-loaded with the action and the standard, followed by a dense but purposeful content list that maps to real report sections. The mid-sentence enumeration is long, yet nearly every item carries information an agent would otherwise have to guess; little is wasted.

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?

With nine parameters, deep nesting, and no output schema, the description's enumeration of report sections is what tells an agent what to expect back, so the missing output schema costs little. It falls short of 5 only because the calling-time essentials — bulk limits, key requirements, entry-dropping behavior — sit in schema text rather than the description.

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 description coverage is 100%, so the schema already carries full parameter meaning, and the description adds essentially nothing parameter-specific beyond what is encoded there. Baseline 3 applies: the description's added value is about the report's content, not about argument semantics.

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

Purpose4/5

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

The description names a specific verb and output ('Calculates shipments and returns a report') and enumerates the report's contents — coverage, TTW/WTT totals, intensity, mode/hub breakdowns, data quality, distance adjustments — tying it to ISO 14083 and GLEC v3.3. That makes the resource unmistakable. What it lacks is an explicit disambiguation from the sibling calculate_shipments/calculate_shipment tools, so an agent must infer the split from 'report' alone.

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

Usage Guidelines3/5

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

Usage is only implied: the description is framed around ISO 14083 conformance reporting, which suggests use when a conformity-style report is wanted rather than a single footprint. There is no statement of when NOT to use it, no pointer to calculate_shipments, and no prerequisites such as API key needs at the top level (that appears only inside the shipments parameter description).

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