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 when the traveller has a day-by-day plan and wants it in the Meridian Dispatch app, or asks for a link to their trip. It is the only tool that creates anything; the others only read. To draft the plan itself, use get_destination, get_dispatch and get_place first and link places with their meridiandispatch.com URLs. 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. A place given with its meridiandispatch.com page URL arrives with that page's field record. Each call creates a new, public, permanent link (not idempotent): booking references, emails and phone numbers are removed. 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

TableJSON Schema

Name	Required	Description
`days`	Yes	The days in order, each with what to do. Number every day or date every day, not a mix.
`stays`	Yes	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.
`title`	Yes	The trip, e.g. "Six days on the Montenegro coast".
`summary`	No	One short paragraph shown under the title: what the trip is and why it works.
`country_code`	Yes	ISO 3166 alpha-2 code of the main country, e.g. "ME".

Output Schema

TableJSON 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
`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.

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.8/5.0

Behavior5/5

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

Annotations already declare readOnly=false, idempotent=false, openWorld=true, but the description adds substantive behavior beyond them: each call creates a new public permanent link, PII (booking references, emails, phone numbers) is stripped, per-hour link rate limiting, invalid itineraries return an error listing every problem, and what happens on iPhone vs web. That is exactly the extra context annotations cannot carry.

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 purpose and routing in the first two sentences, then behavior. It is dense and long, but nearly every sentence carries non-redundant information (PII removal, rate limit, error shape, iPhone behavior); only the return-value sentence is arguably redundant given the output schema exists.

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 5-parameter, nested, non-idempotent creation tool with an output schema, the description covers purpose, routing, side effects, PII handling, rate limits, error behavior, and platform-specific outcomes. Nothing an agent needs to call it correctly is missing, and return values need not be detailed since an output schema exists.

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 coverage is 100%, so baseline is 3, but the description adds cross-parameter meaning the schema does not: number every day or date every day but never mix, every day must fall between a stay's check-in/check-out, and a place supplied with its meridiandispatch.com URL arrives with that page's field record. These relational constraints go beyond the per-field descriptions.

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 and resource (generate an itinerary import link, turning a day-by-day itinerary into a shareable 'Add Itinerary to Meridian Dispatch' link) and it explicitly positions itself against siblings: 'It is the only tool that creates anything; the others only read.' An agent can distinguish it from get_destination/get_place 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 the trigger condition (traveller has a day-by-day plan and wants it in the app, or asks for a trip link) and names the alternative workflow for drafting (use get_destination, get_dispatch, get_place first). Explicit when-to-use plus when-to-use-something-else.

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?