Skip to main content
Glama

read_trip_link

Read-onlyIdempotent

Use when someone gives you a this trip, btw link and you need to know what is actually in it — to summarise the plan, answer a question about it, add a stop, or convert it to something else. Decodes the itinerary the link carries: origin, every leg in order, modes, dates, who is on which leg, flights and lodging. Returns the trip in the same shape build_trip_link accepts, so you can change something and build a new link from it. Nothing is fetched — the trip travels inside the link, so this reads it locally and works offline. Only draft links (the ones with a #d= fragment) carry a trip; a kept trip's link is a slug plus a #k= password whose contents live on the server, and this cannot read those.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linkYesThe trip link, e.g. https://thistripbtw.us/new#d=… — the whole URL is fine, or just the fragment.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
legsYes
tripYesThe trip, in exactly the shape build_trip_link takes — so it can be rebuilt or amended without translation.
summaryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "legs": {
      +      "type": "integer"
      +    },
      +    "summary": {
      +      "type": "string"
      +    },
      +    "trip": {
      +      "description": "The trip, in exactly the shape build_trip_link takes — so it can be rebuilt or amended without translation.",
      +      "properties": {
      +        "legs": {
      +          "items": {
      +            "properties": {
      +              "craft": {
      +                "description": "A small craft that travels WITH them — a bike on the car, a canoe on the roof.",
      +                "enum": [
      +                  "Bike",
      +                  "Canoe",
      +                  "Kayak"
      +                ],
      +                "type": "string"
      +              },
      +              "date": {
      +                "description": "YYYY-MM-DD. Optional — an undated leg keeps its place in the order.",
      +                "type": "string"
      +              },
      +              "flight": {
      +                "description": "Flight number if you have it, e.g. UA328. Never invent one.",
      +                "type": "string"
      +              },
      +              "lodging": {
      +                "description": "Where they stay at this destination — hotel, cabin, a friend's couch.",
      +                "type": "string"
      +              },
      +              "mode": {
      +                "description": "How they travel this leg. Defaults to drive.",
      +                "enum": [
      +                  "drive",
      +                  "fly",
      +                  "train",
      +                  "ferry",
      +                  "water",
      +                  "bike",
      +                  "walk"
      +                ],
      +                "type": "string"
      +              },
      +              "note": {
      +                "description": "Anything worth remembering about this leg. Optional.",
      +                "type": "string"
      +              },
      +              "stayNote": {
      +                "description": "Anything about the stay. Only meaningful alongside lodging.",
      +                "type": "string"
      +              },
      +              "subtype": {
      +                "description": "More precise than mode when you know it: own/rental/rv/taxi for drive, commercial/private for fly, canoe/kayak/sail for water.",
      +                "enum": [
      +                  "own",
      +                  "rental",
      +                  "rideshare",
      +                  "taxi",
      +                  "bus",
      +                  "rv",
      +                  "commercial",
      +                  "private",
      +                  "heli",
      +                  "intercity",
      +                  "commuter",
      +                  "subway",
      +                  "tram",
      +                  "passenger",
      +                  "carferry",
      +                  "sail",
      +                  "motor",
      +                  "canoe",
      +                  "kayak",
      +                  "walk",
      +                  "hike",
      +                  "run",
      +                  "ebike"
      +                ],
      +                "type": "string"
      +              },
      +              "to": {
      +                "description": "Where this leg ends.",
      +                "properties": {
      +                  "lat": {
      +                    "description": "Latitude, -90 to 90.",
      +                    "type": "number"
      +                  },
      +                  "lng": {
      +                    "description": "Longitude, -180 to 180.",
      +                    "type": "number"
      +                  },
      +                  "name": {
      +                    "description": "How a person would say it, e.g. \"Moab, UT\".",
      +                    "type": "string"
      +                  }
      +                },
      +                "required": [
      +                  "lat",
      +                  "lng"
      +                ],
      +                "type": "object"
      +              },
      +              "who": {
      +                "description": "Who travels this leg, if you know — e.g. [\"Mel\",\"Sam\"]. Lets the trip show who was where.",
      +                "items": {
      +                  "type": "string"
      +                },
      +                "type": "array"
      +              }
      +            },
      +            "required": [
      +              "to"
      +            ],
      +            "type": "object"
      +          },
      +          "type": "array"
      +        },
      +        "name": {
      +          "type": "string"
      +        },
      +        "origin": {
      +          "properties": {
      +            "lat": {
      +              "description": "Latitude, -90 to 90.",
      +              "type": "number"
      +            },
      +            "lng": {
      +              "description": "Longitude, -180 to 180.",
      +              "type": "number"
      +            },
      +            "name": {
      +              "description": "How a person would say it, e.g. \"Moab, UT\".",
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "lat",
      +            "lng"
      +          ],
      +          "type": "object"
      +        }
      +      },
      +      "required": [
      +        "origin",
      +        "legs"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "trip",
      +    "legs"
      +  ],
      +  "type": "object"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond these by explaining 'Nothing is fetched — the trip travels inside the link, so this reads it locally and works offline' and clarifying the draft-vs-kept limitation. This enriches the agent's understanding of behavior without contradicting any annotation.

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?

The description is a single paragraph but well-structured: usage first, then what it returns, then behavioral note, then limitation. Every sentence adds information, but it's slightly longer than strictly necessary—though each part serves a purpose, so it remains appropriate. Front-loading the use case ensures the agent finds the key decision point quickly.

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 single-parameter tool with an output schema and strong annotations, the description fully covers what the tool does, when to use it, its offline nature, and its limitation with kept trips. The agent can safely decide whether to invoke this or use a sibling, and knows exactly what input to provide and what to expect. Nothing essential is missing.

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 covers the link parameter with example URL and acceptance of whole URL or fragment. The description adds critical semantics: the link must be a draft link (#d= fragment) to carry a trip, and that it reads locally. With schema coverage at 100%, the baseline is 3; the additional draft-link constraint and offline behavior elevate it to 4.

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 opens with a specific verb ('read') and resource ('trip link'), then elaborates on what it decodes: origin, legs, modes, dates, who is on which leg, flights, lodging. It immediately differentiates from siblings by stating that draft links carry a trip while kept trips do not, and by naming `build_trip_link` and `read_kept_trip` as related but distinct tools. This leaves no ambiguity about the tool's role.

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

Usage Guidelines5/5

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

Explicitly instructs when to use: 'Use when someone gives you a this trip, btw link and you need to know what is actually in it' and lists common purposes. It also states the negative case: 'Only draft links... carry a trip... this cannot read those' which implicitly routes the agent to `read_kept_trip` for kept trips. This is clear when-to-use and when-not-to-use guidance.

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.