Meridian Dispatch

Create an itinerary link for the Meridian Dispatch app

create_itinerary_link

Generate an itinerary import link: turn a day-by-day travel itinerary into a shareable "Add Itinerary to Meridian Dispatch" link. Use it only when the traveller wants a link to share or open elsewhere. To save a trip to the traveller's own account, privately, use create_plan (or edit_plan for one they have): that needs no link and can be deleted. To draft the plan itself, use get_destination, get_dispatch and get_place first and link places with their meridiandispatch.com URLs; for a trip the traveller will take themselves, read get_travel_preferences first (it needs sign-in) and fit the hotels, pace and routing to it. Opening the link on an iPhone with the Meridian Dispatch app shows the trip and adds it to the Plan tab as a new plan, after the traveller picks the first day; anywhere else it opens a web preview of the days. Days are numbered (day 1, 2, 3) or dated, and every day needs a hotel stay or its own city. A dated link opens on its dates, which the traveller can still move. When the dates are not negotiable (a trip built around a festival, a match, a concert or any event on fixed days), date every day and set fixed_dates: the app then adds the trip on exactly those dates with no date picker, and the link's page tells the traveller so. A place given with its meridiandispatch.com page URL arrives with that page's field record. Each call creates a new, public, permanent link that cannot be deleted (not idempotent). Anyone with it sees the trip's dates, towns, stops and hotel names; booking references, emails and phone numbers are removed. Tell the traveller this before making one. Returns the link, ready-made markdown, counts of days and items, and the places matched and not matched to the guides. An invalid itinerary returns an error listing every problem; too many links in an hour returns a rate-limit error.

Input Schema

Name	Required	Description
`car`	No	A rental car the trip needs (a road trip, or days in the countryside). The app adds it as a car rental still to book and draws those days' travel as driving. from_day and to_day are day numbers on both numbered and dated itineraries; to_day may be the morning after the last day. Picked up and returned at airport and airport_home unless pickup or dropoff name other airports.
`days`	Yes	The days in order, each with what to do. Number every day or date every day, not a mix. Every day needs its own city or a stay (in stays) whose check-in to check-out, inclusive, covers it; the error names each day with neither.
`stays`	No	Where the traveller sleeps, by hotel name. Optional: a day not between a stay's check-in and check-out (inclusive) must give its own city, which places it in the app until a hotel is added. check_in_day and check_out_day on a numbered itinerary, check_in and check_out (YYYY-MM-DD) on a dated one.
`title`	Yes	The trip, e.g. "Six days on the Montenegro coast".
`airport`	No	IATA code of the airport to fly into, e.g. "GDN". The app books the flight in to it on day 1 instead of guessing (a country's busiest airport is often the wrong one: Warsaw for Gdańsk).
`summary`	No	One short paragraph shown under the title: what the trip is and why it works.
`fixed_dates`	No	true when the trip only works on its dates, e.g. it is built around an event. Needs a date on every day (not day numbers). The app imports it on those dates and the traveller cannot move them. Leave out for a trip that works any time.
`airport_home`	No	IATA code of the airport to fly home from, when it differs from airport.
`country_code`	Yes	ISO 3166 alpha-2 code of the main country, e.g. "ME".

Output Schema

Name	Required	Description
`url`	No	The link to give the traveller.
`days`	No
`dated`	No
`items`	No
`opens`	No
`title`	No
`markdown`	No
`link_text`	No
`fixed_dates`	No
`unmatched_places`	No	Places that matched nothing in the guides; resend with the proper name to attach a location.
`places_matched_to_guides`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

addedInput schema / properties / airport

Added value: +{
+  "description": "IATA code of the airport to fly into, e.g. \"GDN\". The app books the flight in to it on day 1 instead of guessing (a country's busiest airport is often the wrong one: Warsaw for Gdańsk).",
+  "pattern": "^[A-Za-z]{3}$",
+  "type": "string"
+}

addedInput schema / properties / airport_home

Added value: +{
+  "description": "IATA code of the airport to fly home from, when it differs from airport.",
+  "pattern": "^[A-Za-z]{3}$",
+  "type": "string"
+}

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / days / items / properties / items / items / properties / image

Added value: +{
+  "description": "A photograph of this stop from a Meridian Dispatch page (https://www.meridiandispatch.com/images/...), for a stop with no photo of its own: an event page's picture of the street fair, say. Any other host is refused.",
+  "type": "string"
+}

Changed2 schema fields changedOct 25, 2026

addedInput schema / properties / fixed_dates

Added value: +{
+  "description": "true when the trip only works on its dates, e.g. it is built around an event. Needs a date on every day (not day numbers). The app imports it on those dates and the traveller cannot move them. Leave out for a trip that works any time.",
+  "type": "boolean"
+}

addedOutput schema / properties / fixed_dates
```
Added value: +{}
```

Changed3 schema fields changedOct 25, 2026

changedInput schema / properties / days / description

Previous value: -"The days in order, each with what to do. Number every day or date every day, not a mix."New value: +"The days in order, each with what to do. Number every day or date every day, not a mix. Every day needs its own city or a stay (in stays) whose check-in to check-out, inclusive, covers it; the error names each day with neither."

addedInput schema / properties / days / items / description

Added value: +"One day. Give city unless a stay covers this day."

changedInput schema / properties / days / items / properties / city / description

Previous value: -"Where the traveller is that day, e.g. \"Kotor\"."New value: +"Where the traveller is that day, e.g. \"Kotor\". Required unless a stay in stays covers this day."

Changed3 schema fields changedOct 21, 2026

changedInput schema / properties / stays / description

Previous value: -"Where the traveller sleeps, by hotel name. Required: every day must fall between a stay's check-in and check-out (inclusive), or the app shows that day without its places. check_in_day and check_out_day on a numbered itinerary, check_in and check_out (YYYY-MM-DD) on a dated one."New value: +"Where the traveller sleeps, by hotel name. Optional: a day not between a stay's check-in and check-out (inclusive) must give its own city, which places it in the app until a hotel is added. check_in_day and check_out_day on a numbered itinerary, check_in and check_out (YYYY-MM-DD) on a dated one."

removedInput schema / properties / stays / minItems
```
Removed value: -1
```

changedInput schema / required

Previous value: -[
-  "title",
-  "country_code",
-  "days",
-  "stays"
-]New value: +[
+  "title",
+  "country_code",
+  "days"
+]

Changed28 schema fields changedOct 6, 2026
- addedInput schema / properties / country_code / pattern
```
Added value: +"^[A-Za-z]{2}$"
```
- addedInput schema / properties / days / description
```
Added value: +"The days in order, each with what to do. Number every day or date every day, not a mix."
```
- changedInput schema / properties / days / items / properties / city / description
```
Previous value: -"Where the traveller is that day."New value: +"Where the traveller is that day, e.g. \"Kotor\"."
```
- addedInput schema / properties / days / items / properties / country_code / pattern
```
Added value: +"^[A-Za-z]{2}$"
```
- addedInput schema / properties / days / items / properties / date / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```
- addedInput schema / properties / days / items / properties / items / description
```
Added value: +"The day's places and activities, in order."
```
- addedInput schema / properties / days / items / properties / items / items / properties / category / description
```
Added value: +"The kind of place, e.g. \"Museum\" or \"Beach\"."
```
- addedInput schema / properties / days / items / properties / items / items / properties / kind / description
```
Added value: +"activity (a place or thing to do), restaurant (somewhere to eat) or note (a reminder with no place)."
```
- addedInput schema / properties / days / items / properties / items / items / properties / lat / description
```
Added value: +"Latitude, when there is no meridian_url."
```
- addedInput schema / properties / days / items / properties / items / items / properties / lat / maximum
```
Added value: +90
```
- addedInput schema / properties / days / items / properties / items / items / properties / lat / minimum
```
Added value: +-90
```
- addedInput schema / properties / days / items / properties / items / items / properties / lng / description
```
Added value: +"Longitude, when there is no meridian_url."
```
- addedInput schema / properties / days / items / properties / items / items / properties / lng / maximum
```
Added value: +180
```
- addedInput schema / properties / days / items / properties / items / items / properties / lng / minimum
```
Added value: +-180
```
- changedInput schema / properties / days / items / properties / items / items / properties / meridian_url / description
```
Previous value: -"The meridiandispatch.com page for this place, when there is one."New value: +"The meridiandispatch.com page for this place, when there is one (from search_guides or get_destination). The place then arrives with its location and record."
```
- addedInput schema / properties / days / items / properties / items / items / properties / part_of_day / description
```
Added value: +"When in the day, if there is no exact time."
```
- addedInput schema / properties / days / items / properties / items / items / properties / time / pattern
```
Added value: +"^\\d{2}:\\d{2}$"
```
- addedInput schema / properties / stays / items / properties / check_in / description
```
Added value: +"Dated itinerary: check-in date, YYYY-MM-DD."
```
- addedInput schema / properties / stays / items / properties / check_in / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```
- addedInput schema / properties / stays / items / properties / check_in_day / description
```
Added value: +"Numbered itinerary: the day number of check-in."
```
- addedInput schema / properties / stays / items / properties / check_out / description
```
Added value: +"Dated itinerary: check-out date, YYYY-MM-DD."
```
- addedInput schema / properties / stays / items / properties / check_out / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```
- addedInput schema / properties / stays / items / properties / check_out_day / description
```
Added value: +"Numbered itinerary: the day number of check-out."
```
- addedInput schema / properties / stays / items / properties / city / description
```
Added value: +"The town the hotel is in."
```
- addedInput schema / properties / stays / items / properties / name / description
```
Added value: +"The hotel's name, as booked."
```
- addedInput schema / properties / stays / minItems
```
Added value: +1
```
- addedInput schema / properties / title / minLength
```
Added value: +1
```
- changedOutput schema / (root)
```
Previous value: -nullNew value: +{
+  "properties": {
+    "dated": {},
+    "days": {},
+    "items": {},
+    "link_text": {
+      "type": "string"
+    },
+    "markdown": {
+      "type": "string"
+    },
+    "opens": {
+      "type": "string"
+    },
+    "places_matched_to_guides": {},
+    "title": {
+      "type": "string"
+    },
+    "unmatched_places": {
+      "description": "Places that matched nothing in the guides; resend with the proper name to attach a location.",
+      "type": "array"
+    },
+    "url": {
+      "description": "The link to give the traveller.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
```

Changed3 schema fields changedOct 2, 2026

changedInput schema / properties / stays / description

Previous value: -"Where the traveller sleeps: check_in_day and check_out_day on a numbered itinerary, check_in and check_out (YYYY-MM-DD) on a dated one."New value: +"Where the traveller sleeps, by hotel name. Required: every day must fall between a stay's check-in and check-out (inclusive), or the app shows that day without its places. check_in_day and check_out_day on a numbered itinerary, check_in and check_out (YYYY-MM-DD) on a dated one."

addedInput schema / properties / summary

Added value: +{
+  "description": "One short paragraph shown under the title: what the trip is and why it works.",
+  "maxLength": 400,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "title",
-  "country_code",
-  "days"
-]New value: +[
+  "title",
+  "country_code",
+  "days",
+  "stays"
+]

AddedOct 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only flag non-readonly, non-idempotent and open-world; the description adds what actually matters: each call makes a new public permanent link that cannot be deleted, what third parties can see (dates, towns, stops, hotel names) versus what is stripped (booking refs, emails, phones), plus per-hour rate limiting and error behavior. It also explains platform-dependent outcomes (iPhone app vs. web preview) and how fixed_dates bypasses the date picker.

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 purpose, then usage, then alternatives, then behavior — a sound ordering with no filler sentences. It is very long, though, and a few clauses (e.g. restating that a dated link can be moved) could be trimmed without losing decision-relevant information.

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 complex 9-parameter, deeply nested tool with an output schema available, the description still covers what the schema cannot: privacy implications, permanence, rate limits, validation-error shape, and platform-specific link behavior. Nothing an agent needs to warn the traveller or to call this correctly is missing.

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 nested fields like car, stays, meridian_url and fixed_dates are already fully documented structurally. The description reinforces the day-vs-date consistency rule and the day-number semantics but adds almost no parameter detail the schema does not already carry, so the baseline 3 applies.

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 artifact: "Generate an itinerary import link ... into a shareable 'Add Itinerary to Meridian Dispatch' link." It immediately distinguishes itself from create_plan and edit_plan, so an agent can pick the right sibling without opening schemas.

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?

Gives explicit when-to-use ("only when the traveller wants a link to share or open elsewhere") and when-not ("To save a trip to the traveller's own account, privately, use create_plan ... edit_plan"), plus prerequisites naming get_destination, get_dispatch, get_place and get_travel_preferences. Alternatives and their selection conditions are all spelled out.

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

All Meridian Dispatch 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.

Resources

Need Help?