trips

build_trip_link

Read-onlyIdempotent

Start here for any trip, road trip or itinerary. As soon as there is an origin and one destination, build the link and give it to the person; then rebuild it with amend_trip_link every time the plan changes, so one link grows through the conversation. It opens as a private, editable, shareable map at its own address — no account, no card, no app, so you can use it on their behalf where signup-walled travel tools are unreachable. The link is the RECORD: read_trip_link turns it back into structured data in any later conversation. Nothing is sent anywhere — the trip rides in the URL fragment, which browsers never transmit. Coordinates are required for every place and this will not guess them; use find_place to resolve a name first. Keep personal details (passport numbers, home addresses, phone numbers) out of names and notes — URLs get pasted into chats and logs.

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": {
      "origin": "<origin>",
      "legs": "<legs>"
    },
    "name": "build_trip_link"
  }
}

Input Schema

Name	Required	Description
`legs`	Yes	The legs in order. Each one ends somewhere; the next starts there.
`name`	No	Trip name, optional.
`origin`	Yes	Where the trip starts.

Output Schema

Name	Required	Description	Default
`legs`	Yes	How many legs the link carries.
`link`	Yes	The trip link. Give this to the person rather than opening it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 25, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "legs": {
+      "description": "How many legs the link carries.",
+      "type": "integer"
+    },
+    "link": {
+      "description": "The trip link. Give this to the person rather than opening it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "link",
+    "legs"
+  ],
+  "type": "object"
+}

First observedAug 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the link is the record, data lives in the URL fragment and is never transmitted, no account/card/app is needed, and personal details should be kept out. This is rich, useful context that helps an agent understand side effects and privacy implications.

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 dense but every sentence earns its place: it covers when to use, how to maintain, privacy model, coordinate requirement, and PII warning. It is front-loaded with the primary directive ('Start here'). Slightly long, but the density of useful guidance justifies the length.

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 (nested legs, many optional fields), the schema covers parameter details, and the description covers the operational model: when to build, when to amend, how to read back, privacy behavior, coordinate requirement, and PII caution. An agent has everything needed to invoke this correctly and route to siblings.

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 all parameters and nested fields thoroughly. The description adds high-level context (origin + one destination, legs in order, coordinates required) but doesn't need to repeat the schema's per-field details. 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?

The description opens with 'Start here for any trip, road trip or itinerary' and states a specific verb+resource: build the link once origin and one destination exist. It clearly distinguishes itself from siblings by naming amend_trip_link and read_trip_link and explaining the link lifecycle.

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?

The description explicitly says when to use this tool ('Start here', 'as soon as there is an origin and one destination'), when to use amend_trip_link ('rebuild it ... every time the plan changes'), and when to use find_place ('use find_place to resolve a name first'). It also gives a clear exclusion: coordinates are required and the tool will not guess them.

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

All trips 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.