Sootcase freight CO2e

Route changes that lower emissions

recommend_routes

Read-onlyIdempotent

For each shipment, tries road legs on rail, inland waterway and short sea, air legs by sea or rail, other sea ports, (when a load is given) fuller loads, and on the same route larger, electric and bio-LNG trucks (GLEC v3.3 default values, only where GLEC gives them); each kind is in one of the GLEC Framework's five reduction areas; calculates each alternative with the same method as the shipment (GLEC v3.3, ISO 14083) and returns those lower than now, best first, with totals per kind and per lane, the sources of the rules and the limitations. Rules (defaults, settable): road legs over 300 km (EU Transport White Paper 2011); rail, waterway or sea part over 100 km in a straight line, road to a waterway or sea port within 150 km, nearest rail terminal (Directive 92/106/EEC). New rail, waterway and sea legs run between terminals with road to the nearest one; each terminal handling counts GLEC v3.3's intermodal terminal value per container (not at airports or Ro-Ro terminals). It knows nothing about transit times, costs or whether a service runs: tell the user, and that results are scenarios, not reported emissions. The website's Recommendations page (/recommend) lets the user filter and pick interactively.

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": "recommend_routes"
  }
}

Input Schema

Name	Required	Description	Default
`settings`	No
`shipments`	Yes	The shipments. Without an API key the public service takes up to 100 per call; with one, up to 10,000.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / settings / properties / kinds / items / enum

Previous value: -[
-  "road_to_rail",
-  "road_to_waterway",
-  "road_to_short_sea",
-  "air_to_sea",
-  "air_to_rail",
-  "other_port",
-  "fuller_loads"
-]New value: +[
+  "road_to_rail",
+  "road_to_waterway",
+  "road_to_short_sea",
+  "air_to_sea",
+  "air_to_rail",
+  "other_port",
+  "fuller_loads",
+  "larger_truck",
+  "electric_truck",
+  "bio_lng_truck"
+]

Changed3 schema fields changedOct 30, 2026

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"
+]
```

Changed1 schema field changedOct 29, 2026

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"
+}

Changed2 schema fields changedOct 29, 2026

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"
+}

Changed1 schema field changedOct 29, 2026

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."

Changed1 schema field changedOct 28, 2026

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"
+}

AddedOct 24, 2026

TDQS

A4/5.0

Behavior5/5

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

The description discloses substantial behavior beyond the readOnly/idempotent annotations: the GLEC v3.3 and ISO 14083 methods, settable default thresholds, terminal handling treatment, and the crucial caveat that results are scenarios and ignore transit times, costs, and service availability. No contradiction with annotations is present.

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 description is information-dense and front-loads the core behavior, but it is a single long paragraph with a very long opening sentence. The content is relevant, yet the structure makes it harder to scan than necessary for an agent.

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?

Given the tool's complexity, lack of an output schema, and limited annotations, the description is complete enough: it explains what is returned, how alternatives are calculated, key defaults and rules, terminal handling, and important limitations. An agent has enough context to call it appropriately and warn the user about scope.

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?

The description adds meaning for several settings by explaining default thresholds, the kinds tried, fuller-load conditions, and GLEC rule sources. With schema coverage at 50%, it compensates usefully, though it does not explain every setting such as terminal selection or source.

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 states a specific action: it tries lower-emission alternatives for each shipment and returns those that are better than the current option, best first. It is clearly a recommendation tool, but it does not explicitly distinguish itself from siblings like calculate_shipment or compare_scenario.

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 implied by the detailed explanation of what alternatives are tried and what limitations exist. However, there is no explicit statement of when to use this tool versus calculate_shipment, compare_scenario, or emissions_report, and no when-not guidance beyond the limitation notes.

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

All Sootcase freight CO2e 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?