thistripbtw-mcp

amend_trip_link

Read-onlyIdempotent

Update an existing trip link when plans change—add, edit, replace, rename, or remove legs and return the updated link, so one link grows with the trip.

Instructions

Update a trip link you already built — add legs, change one leg's fields, replace them all, rename, or drop one — and get the new link back. Use this instead of building a fresh link every time the plan changes, so the person holds one link that grows. To change ONE leg (its lodging, date, note, who is on it) use update rather than resending every leg through legs. Takes a draft link (#d=) plus the changes; no network, no password, the trip is inside the link. For a KEPT trip (#k=) use add_to_kept_trip.

Input Schema

TableJSON Schema

Name	Required	Description
`add`	No	Legs to APPEND after the last one.
`legs`	No	REPLACES every leg. Omit to keep them.
`link`	Yes	The existing draft link, whole URL or just the #d= fragment.
`name`	No	New trip name.
`origin`	No	New starting point.
`remove`	No	Drop leg number N (1-based). Applied after add/legs/update.
`update`	No	Change fields on existing legs without resending the rest. Each item names a leg (1-based) and the fields to set; a field set to null is cleared. Applied after add/legs, before remove.

Output Schema

TableJSON Schema

Name	Required	Description
`legs`	Yes
`link`	Yes	The trip link. Give this to the person rather than opening it.
`changed`	Yes	What this call actually altered.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.3.5Sep 30, 2026

changedInput schema / properties / remove / description

Previous value: -"Drop leg number N (1-based). Applied after add/legs."New value: +"Drop leg number N (1-based). Applied after add/legs/update."

addedInput schema / properties / update

Added value: +{
+  "description": "Change fields on existing legs without resending the rest. Each item names a leg (1-based) and the fields to set; a field set to null is cleared. Applied after add/legs, before remove.",
+  "items": {
+    "properties": {
+      "leg": {
+        "description": "Which leg, 1-based.",
+        "type": "integer"
+      },
+      "set": {
+        "description": "The fields to change — any leg field: to, mode, date, note, who, lodging, stayNote, flight, subtype, craft.",
+        "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": [],
+        "type": "object"
+      }
+    },
+    "required": [
+      "leg",
+      "set"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "changed": {
+      "description": "What this call actually altered.",
+      "properties": {
+        "added": {
+          "type": "integer"
+        },
+        "name": {
+          "type": "boolean"
+        },
+        "origin": {
+          "type": "boolean"
+        },
+        "removed": {
+          "type": "boolean"
+        },
+        "replaced": {
+          "type": "boolean"
+        },
+        "updated": {
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    },
+    "legs": {
+      "type": "integer"
+    },
+    "link": {
+      "description": "The trip link. Give this to the person rather than opening it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "link",
+    "legs",
+    "changed"
+  ],
+  "type": "object"
+}

Addedv1.0.2Sep 12, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description adds real context beyond them: no network call, no password, the trip lives inside the link, and only draft (#d=) links are accepted. It does not, however, note that `legs` wholesale replacement discards anything not resent, which is the one behaviorally risky operation here.

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 core action and the five mutation modes, then routing and preconditions. Dense but every clause carries information; the only mild friction is backticked `update`/`legs`, which are parameters but read like tool names.

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 7-parameter nested mutation tool with an output schema, annotations covering the safety profile, and 100% schema coverage, the description supplies the missing layer—when to use it, what it returns, and offline/self-contained semantics—without duplicating return-value detail.

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 description coverage is 100%, so the per-parameter baseline is 3, but the description adds routing semantics the schema does not: it states which parameter to reach for in which editing scenario and clarifies that add/legs/update/remove compose. It stops short of explaining ordering or conflict rules in prose.

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?

Specific verb+resource with an explicit enumeration of the mutations supported (append legs, edit one leg, replace all, rename, drop one) and the returned artifact (the new link). It also differentiates itself from siblings by naming add_to_kept_trip and steering away from build_trip_link for incremental changes.

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?

Explicit when-to-use ("use this instead of building a fresh link every time the plan changes"), when-not (kept trips → add_to_kept_trip), and an internal routing rule for single-leg edits via `update` vs full resend via `legs`. Nothing is left to inference.

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

Deploy Server