aitrips.io

trip_transport_add

Add a transport item (train, bus, taxi, tube, ferry, walk) or flight to a trip. ALWAYS use this instead of trip_item_add for transport. Both origin and destination are required, ensuring routes display correctly on the map.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`date`	No	Date of travel (YYYY-MM-DD)
`notes`	No	Additional notes
`status`	No	Booking status	IDEA
`tripId`	Yes	Trip ID
`currency`	No	Currency code (e.g., GBP, USD, EUR)
`operator`	No	Transport operator (e.g., "GWR", "British Airways", "Eurostar")
`timezone`	No	IANA timezone for departure time (e.g., "Europe/London"). Defaults to trip timezone. Auto-detected from origin coords when omitted.
`bookingUrl`	No	Booking URL
`arrivalDate`	No	Arrival date (YYYY-MM-DD) for overnight or multi-day transport. Must be >= date. Omit for same-day journeys.
`arrivalTime`	No	Arrival time (HH:MM)
`description`	No	Additional details (e.g., "Direct train, ~1 hour journey")
`timezoneEnd`	No	IANA timezone for arrival time (e.g., "America/New_York"). Defaults to departure timezone. Auto-detected from destination coords when omitted. Only needed when arrival is in a different timezone.
`costEstimate`	No	Estimated cost
`departureTime`	No	Departure time (HH:MM)
`transportType`	Yes	Type of transport
`linked_item_id`	No	Optional ID of the destination trip item this transport links TO. Links the transport to its destination for deterministic ordering and stale detection.
`originLocation`	Yes	Departure location name (e.g., "London Paddington Station"). Will be geocoded automatically.
`costIsPerPerson`	No	Is cost per person?
`bookingReference`	No	Booking reference
`destinationLocation`	Yes	Arrival location name (e.g., "Oxford Station"). Will be geocoded automatically.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 23, 2026

addedInput schema / properties / arrivalDate

Added value: +{
+  "description": "Arrival date (YYYY-MM-DD) for overnight or multi-day transport. Must be >= date. Omit for same-day journeys.",
+  "type": "string"
+}

addedInput schema / properties / linked_item_id

Added value: +{
+  "description": "Optional ID of the destination trip item this transport links TO. Links the transport to its destination for deterministic ordering and stale detection.",
+  "type": "string"
+}

changedInput schema / properties / timezone / description

Previous value: -"IANA timezone for departure/arrival times (e.g., \"Europe/London\"). Defaults to trip timezone."New value: +"IANA timezone for departure time (e.g., \"Europe/London\"). Defaults to trip timezone. Auto-detected from origin coords when omitted."

addedInput schema / properties / timezoneEnd

Added value: +{
+  "description": "IANA timezone for arrival time (e.g., \"America/New_York\"). Defaults to departure timezone. Auto-detected from destination coords when omitted. Only needed when arrival is in a different timezone.",
+  "type": "string"
+}

changedInput schema / properties / transportType / enum

Previous value: -[
-  "train",
-  "bus",
-  "taxi",
-  "ferry",
-  "car",
-  "flight",
-  "tube",
-  "metro",
-  "walk"
-]New value: +[
+  "train",
+  "bus",
+  "taxi",
+  "ferry",
+  "car",
+  "flight",
+  "tube",
+  "metro",
+  "walk",
+  "cycle",
+  "scooter",
+  "tram"
+]

First observedSep 1, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, so the description must clarify mutation behavior. It adds that origin/destination are required for map routing display, which is a useful behavioral note. However, it doesn't disclose side effects, potential failures, or how the transport item relates to other trip items beyond the linked_item_id parameter. The description carries some burden but could be richer.

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?

The description is two sentences, front-loaded with the core purpose and the crucial 'ALWAYS use this instead of trip_item_add' instruction. There is zero waste; every word contributes to selection and usage guidance.

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

Completeness3/5

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

With 20 parameters and no output schema, the description is brief. It adequately covers the high-level purpose and the key differentiator from trip_item_add. However, it doesn't mention any preconditions (e.g., trip must exist), return behavior, or edge cases like flights vs other transport. The schema handles parameter details, but the description could offer more context about how transport items integrate with trip items (e.g., linking). It's adequate but not thorough.

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 all 20 parameters already have descriptions. The description mentions that origin and destination are required, which is already in the schema's required list, so it adds no new semantic value. It doesn't clarify any parameter interactions or formats beyond what the schema provides. Baseline of 3 is appropriate when schema covers all parameters.

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?

The description clearly states the tool adds a transport item (listing types) or flight to a trip, with a specific verb and resource. It distinguishes itself from trip_item_add by explicitly naming it as the alternative, so an agent can select it correctly without ambiguity.

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?

The description gives explicit guidance: 'ALWAYS use this instead of trip_item_add for transport', which is a strong directive. It also mentions that origin and destination are required for correct map display, providing context on when to use it. However, it doesn't explicitly state when NOT to use it (e.g., for non-transport items), though the ALWAYS note effectively covers that.

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

All aitrips.io 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.

trip_transport_add

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources