Skip to main content
Glama

View trip itinerary

trip_details
Read-onlyIdempotent

Get detailed information about a specific trip. The text response includes the trip summary plus a chronological list of every segment (flights, hotels, activities, etc.) with each segment_id, so you can chain directly to segment_details, segment_update, segment_delete, or flight_status_for_segment without another search. Also includes traveler count. For full per-segment details, use segment_details with the returned segment_id. Use sections and segment_types to filter the response.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trip_idYesThe unique identifier of the trip to fetch details for
sectionsNoOptional: filter which sections to include in the response. Values: 'segments', 'travelers'. Default: all sections.
segment_typesNoOptional: filter segments by type. Values: Flight, Lodging, CarRental, Train, Transfer, Ferry, EventTicket, Parking, Activity, Note, Poll. Default: all types.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tripNo
canEditNo
capabilitiesNo
contractVersionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real value beyond them: it discloses the shape of the response (trip summary, chronological segment list with segment_ids, traveler count) and the chaining affordance that saves a follow-up search. No auth, error, or rate-limit notes, so it isn't exhaustive.

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?

Front-loaded with the primary action and response contents, then chaining guidance, then filters. Efficient overall, though the segment_details routing is stated twice (once in the chain list, once as a separate sentence), which is mild redundancy.

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?

For a read-only detail tool with an output schema and full annotation coverage, the description supplies everything needed to select and call it correctly: scope, response contents, downstream chaining, and filter parameters.

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 documents trip_id, sections, and segment_types with their allowed values. The description restates them as response filters without adding syntax or default semantics beyond what the schema says; baseline 3 is appropriate.

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?

States a specific verb and resource ('Get detailed information about a specific trip') and immediately disambiguates from the sibling that overlaps most, segment_details, plus trip-level list tools. An agent can pick it without opening the schema.

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 the agent: use the returned segment_id to chain into segment_details, segment_update, segment_delete, or flight_status_for_segment, and 'for full per-segment details, use segment_details.' It doesn't state when-not to use it versus trips_list or trips_hub, so it stops short of full coverage.

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