Meridian Dispatch

Server Details

Reported travel guides: countries, towns, sights, trails, events, ski resorts. Cited.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-10 10:32
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.6/5.0

Scored 2026-10-07 00:05 across 9 tools

Disambiguation4/5

Each tool targets a distinct resource or action (destination vs place vs dispatch vs search vs events vs best-time), and descriptions explicitly cross-reference when to use alternatives. Some residual overlap exists—get_best_time month-mode versus list_events, and list_best_places versus get_destination's ranked places—but it's largely manageable.

Naming Consistency5/5

Consistent verb_noun pattern throughout: get_*, list_*, search_guides, create_itinerary_link. The single multi-word verb case follows the same convention cleanly, so there is no stylistic mixing.

Tool Count5/5

Nine tools is well-scoped for a travel-guide read API, with each tool earning its place across search, read, list, and one write operation. No redundancy or bloat.

Completeness4/5

The read surface thoroughly covers the domain (search, destination, place, dispatch, events, best places, nearby, best time) plus one creation tool. Minor gaps remain: no way to list, manage, or delete created itinerary links, but core planning workflows are covered.

Available Tools

9 tools

create_itinerary_linkCreate an itinerary link for the Meridian Dispatch appAInspect

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.

ParametersJSON 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

ParametersJSON 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

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.

get_best_timeGet the best time to goA

Read-onlyIdempotent

Inspect

Get the best time to visit from the Meridian Dispatch guides, in one of two modes. Give destination (a country, town, trail or ski resort) for its best months, good and avoid months, closures and crowds where known, the guide's own best-time line, and the events held there. Or give month for "where to go in March": up to 40 countries, towns, trails, ski resorts and festivals the guides recommend that month, each with its reason, events first. If both are given, destination wins. For festival dates alone use list_events; for a full planning guide use get_destination. Read-only. An unknown destination, an invalid month or neither parameter returns an error message.

ParametersJSON Schema

Name	Required	Description	Default
`month`	No	An English month name ("October", or "oct") or its number, 1 to 12 ("10"). Use this or destination.
`destination`	No	A country, town, trail or ski resort, by name, e.g. "Kotor" or "Niseko". Use this or month.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`month`	No
`crowds`	No
`source`	No	How to credit this answer: show cite_as, or link url.
`closures`	No
`best_months`	No
`destination`	No
`good_months`	No
`recommended`	No	For a month: destinations recommended then.
`avoid_months`	No
`events_there`	No
`in_their_words`	No

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so 'Read-only' is redundant, but the description adds genuinely new behavior: mode precedence when both params are supplied and the exact error conditions (unknown destination, invalid month, neither parameter). It stops short of describing pagination or result limits, which a 5 would cover.

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 two-mode structure and heavily information-dense, with each clause earning its place. It is somewhat long and the error-handling sentence could be trimmed, but there is little waste.

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?

Despite an output schema existing, the description fully covers the two modes, precedence rules, error behavior, and routing to sibling tools. Nothing an agent needs 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining what each parameter produces: destination yields best/good/avoid months, closures, crowds and events; month yields up to 40 recommended places with reasons. That output-oriented meaning is not in the schema.

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+resource (get the best time to visit) and immediately clarifies the two operating modes, which distinguishes it from get_destination and list_events. An agent can identify the tool's job without opening the schema.

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 names alternatives and their selecting conditions: 'For festival dates alone use list_events; for a full planning guide use get_destination.' It also resolves the ambiguous case with 'If both are given, destination wins,' leaving nothing to inference.

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

get_destinationGet a country or town guideA

Read-onlyIdempotent

Inspect

Read the Meridian Dispatch guide to one country or one town, for planning a stay there. Returns: why go, how long to stay, the best months, getting there and around, practical FAQ answers, a structured fact sheet where one exists (nights, months, travel times in minutes, areas to stay, ranked top things, day trips, watch-outs), up to 15 ranked places worth your time with their own guide links, recommended hotels, the town guides of a country, related dispatches and a citation. Use it for "what to do in X", "how many days in X" or "where to stay in X". For a single sight, trail, event or ski resort use get_place; for a long-form dispatch use get_dispatch; to find a destination by theme use search_guides; for towns within reach use list_nearby. Matching tries a country first, then a town. A country with town guides but no country guide returns its town guides and dispatches instead. Read-only. An unknown name returns an error message.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	One country or town, by English name, e.g. "Slovenia" or "Bled". Case and accents are ignored. Not a sight or region: use get_place or search_guides for those.
`country`	No	The country of the town, by English name, to tell apart towns that share a name (Granada, Valencia, Mérida). Omit when name is a country or a unique town.

Output Schema

ParametersJSON Schema

Name	Required	Description
`lat`	No
`lng`	No
`name`	No
`note`	No
`type`	No
`photo`	No	Lead photograph: url, alt text and credit.
`stays`	No	Hotels the guide recommends.
`places`	No	The places worth your time, ranked.
`source`	No	How to credit this answer: show cite_as, or link url.
`country`	No
`summary`	No
`overview`	No	Opening paragraphs of the guide.
`planning`	No	Short answers: days needed, best time, getting there, getting around, language, money.
`practical`	No	Practical questions and answers not already covered by planning.
`dispatches`	No	Related long-form dispatches.
`fact_sheet`	No	Structured planning data: nights, months, getting_there, where_to_stay, top_things, day_trips, watch-outs.
`best_months`	No
`coords_note`	No
`places_note`	No
`town_guides`	No	For a country: its town guides.
`places_total`	No
`country_guide`	No	meridiandispatch.com URL.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them by disclosing resolution order (country first, then town), the fallback when a country has town guides but no country guide, and that an unknown name returns an error message. These are non-obvious behaviors an agent needs.

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 purpose and scope, then alternatives, then edge cases. The long enumerated 'Returns:' list partially duplicates the existing output schema, which is the only real inefficiency in an otherwise tight block.

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?

Covers purpose, use cases, sibling routing, resolution behavior, fallbacks, and error handling. With an output schema present the return-value enumeration is optional, but nothing an agent needs to invoke this correctly 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 coverage is 100%, so the baseline is 3, but the description adds resolution semantics that the schema does not: matching tries a country first, then a town, and the country param exists to disambiguate same-named towns. Useful, though slightly redundant with the schema's own country description.

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 resource (read the Meridian Dispatch guide to one country or one town) and scopes it to trip planning. An agent can distinguish it from get_place, get_dispatch, and search_guides without opening any schema.

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 concrete use cases ('what to do in X', 'how many days in X', 'where to stay in X') and explicitly routes alternatives: get_place for a single sight/trail/event/resort, get_dispatch for long-form, search_guides for theme search, list_nearby for towns within reach. When-not conditions are spelled out.

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

get_dispatchGet a dispatch or itineraryA

Read-onlyIdempotent

Inspect

Read one Meridian Dispatch long-form dispatch or multi-day itinerary. A dispatch is a reported piece on one place: returns its headline, standfirst, opening excerpt, themes, publish date, photo and links to its town and country guides (the full text stays on the page). An itinerary is a country route over several days: returns the bases in order, nights in each, where to stay and every day's activities by part of the day, each linked to its guide. Use it only for these two kinds of page. For a country or town guide use get_destination; for one sight, trail, event or ski resort use get_place; to list dispatches on a theme use search_guides with type "dispatch" or "itinerary". Lookup order: an exact URL, then an exact slug, then the single best keyword match, so a place name returns the one most relevant dispatch. Read-only. No match returns an error message.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	A dispatch or itinerary URL, its slug (e.g. "hallstatt", "montenegro-beach-six-days"), or the place it covers (e.g. "Hallstatt").

Output Schema

ParametersJSON Schema

Name	Required	Description
`lat`	No
`lng`	No
`note`	No
`type`	No
`photo`	No	Lead photograph: url, alt text and credit.
`place`	No
`route`	No	For an itinerary: bases, nights and day_by_day activities.
`source`	No	How to credit this answer: show cite_as, or link url.
`themes`	No
`excerpt`	No
`headline`	No
`published`	No
`standfirst`	No
`town_guide`	No	meridiandispatch.com URL.
`country_guide`	No	meridiandispatch.com URL.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description nonetheless adds genuine behavior: the lookup precedence (URL, then slug, then best keyword match), the fact that full text stays on the page and only excerpts/links are returned, and that a no-match yields an error. It does repeat 'Read-only' from the annotations, which is the only wasted clause.

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 what the tool reads, then the two page types, then routing rules, then lookup order. Dense but every sentence carries routing or behavioral information; only the redundant 'Read-only' clause is filler.

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 one parameter, full schema coverage, an output schema, and rich annotations, the description covers purpose, page-type semantics, sibling routing, resolution order, and failure mode. Nothing an agent needs in order to call it correctly 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 description coverage is 100%, so the baseline is 3, but the description adds interpretation rules the schema does not: the query is resolved as URL first, then slug, then single best keyword match, so a bare place name maps to one most-relevant dispatch. That meaningfully clarifies the single parameter beyond its schema text.

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 (read one) plus two precisely defined resources (dispatch, itinerary), and explicitly defines what each kind of page contains. It distinguishes itself from every relevant sibling by name, so an agent can route without opening any schema.

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 scopes usage ('Use it only for these two kinds of page') and names the alternatives with their selecting conditions: get_destination for country/town guides, get_place for sights/trails/events/resorts, search_guides with type 'dispatch'/'itinerary' for listing. 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.

get_placeGet a venue, trail, event or ski resortA

Read-onlyIdempotent

Inspect

Read the Meridian Dispatch field record for one place: a sight, museum, beach or park, a trail or scenic drive, an event, or a ski resort. Returns the best time to go, how long it takes, effort, season, access, how to get there and what goes wrong, plus the best months, practical answers, a photo, the town guide link and a citation; an event adds its dates and schedule, a trail its route facts. Use it once you know the place. For a whole country or town use get_destination; for a dispatch use get_dispatch; to find a place you cannot name exactly use search_guides; for what else is close use list_nearby. Give url, or name (at least one). A place mentioned on a town guide with no page of its own returns its short write-up and that guide. A URL of a town, country or dispatch page returns that guide instead. Read-only. No match returns an error message.

ParametersJSON Schema

Name	Required	Description
`url`	No	The place's meridiandispatch.com page URL, from a search_guides or get_destination result. Takes priority over name.
`name`	No	The place's name, e.g. "Kotor Old Town" or "Grunas Waterfall". Exact names match first, then names that contain it.
`town`	No	The town the place is in or visited from, e.g. "Kotor", to narrow a name shared by several places.
`country`	No	The place's country, by English name, to narrow a name shared by several places.

Output Schema

ParametersJSON Schema

Name	Required	Description
`lat`	No
`lng`	No
`why`	No
`name`	No
`town`	No
`type`	No
`event`	No	For an event: dates, best day, when to book, where to stay, schedule.
`photo`	No	Lead photograph: url, alt text and credit.
`source`	No	How to credit this answer: show cite_as, or link url.
`country`	No
`summary`	No
`overview`	No
`practical`	No
`town_guide`	No	meridiandispatch.com URL.
`at_a_glance`	No	Best time, time needed, effort, season, access.
`best_months`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/no-destructive, but the description adds real edge-case behavior unavailable elsewhere: a place with no page returns its short write-up plus its town guide, a town/country/dispatch URL returns that guide instead, and no match returns an error message rather than an empty result.

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 purpose and routing, but the second sentence is a long, comma-heavy inventory of return fields that is hard to parse in one pass. Every element is relevant, yet the returns list could be tightened or deferred to the output schema.

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 4-parameter, zero-required lookup tool with an output schema, the description covers purpose, routing, input requirement and fallback behavior completely. Nothing an agent needs in order to call it correctly 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 coverage is 100%, so baseline is 3, but the description adds a genuine constraint the schema does not enforce: at least one of url or name is required despite zero required properties. The town/country narrowing purpose is already in the schema.

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: 'Read the Meridian Dispatch field record for one place', with the resource scope enumerated (sight, museum, beach, park, trail, event, ski resort). It also names the siblings it is not (get_destination, get_dispatch, search_guides, list_nearby), so an agent can route without opening any schema.

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 trigger ('Use it once you know the place') plus four named alternatives with the condition that selects each (whole country/town, dispatch, unknown name, nearby). Also states the input precondition: 'Give url, or name (at least one).'

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

list_best_placesList the World's Best placesA

Read-onlyIdempotent

Inspect

List Meridian Dispatch's ranked World's Best places: the 20 best in the world or the 10 best in one country, overall or within one category. Use it for "top things to do in X" or "best beaches in X". For one town's highlights use get_destination; for places near a point use list_nearby; for any other search use search_guides. Returns the list's title, the places in rank order (rank, name, where, a one-line summary, the place's own guide URL where one exists, and a coordinate), the other categories available for that scope, and a citation. Read-only. A country or category with no list returns an error that names the ones that exist.

ParametersJSON Schema

Name	Required	Description	Default
`country`	No	The country to rank, by English name, e.g. "Italy". Omit for the world list.
`category`	No	One kind of place: landmarks, museums, towns, wilderness, hiking trails, scenic drives, parks, viewpoints, beaches, shopping, wildlife, wellness or ski resorts. Singular and plural both work. Omit for the overall list.

Output Schema

ParametersJSON Schema

Name	Required	Description
`list`	No
`ranked`	No	Best first.
`source`	No	How to credit this answer: show cite_as, or link url.
`other_categories`	No

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent safety, so the bar is lower; the description still adds genuinely useful behavior: the shape of the result (rank order, guide URLs, coordinates, other categories, citation) and, most importantly, that a country/category with no list returns an error naming the valid ones. It stops short of documenting pagination or rate limits, which are not obviously relevant for a fixed 10/20-item list.

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?

Four dense sentences, front-loaded with the scope and routing before the return shape and edge case; every clause carries information. The return-value sentence partially duplicates the existing output schema, which is the only slack in an otherwise tight definition.

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?

Covers scope, routing, cardinality, error behavior, and the result shape. With an output schema present it does not need to detail return values, and it does not pad with them beyond a brief orientation. An agent has everything needed to call it correctly on the first try.

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; the description adds meaning beyond the schema by explaining the cardinality consequences of each parameter combination (20 worldwide vs 10 per country, overall vs within one category). It does not add syntax or format guidance beyond what the schema descriptions already provide.

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+resource ('List Meridian Dispatch's ranked World's Best places') and immediately bounds the scope (20 worldwide or 10 per country, overall or per category). It explicitly names the siblings it is not (get_destination, list_nearby, search_guides), so an agent can route without opening another schema.

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 concrete trigger phrases ('top things to do in X', 'best beaches in X') plus three explicit alternatives with the conditions that select each: get_destination for one town, list_nearby for proximity, search_guides for anything else. 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.

list_eventsList festivals and eventsA

Read-onlyIdempotent

Inspect

List the festivals and events worth planning a trip around, from the Meridian Dispatch events guide. Returns each event's name, kind, where it is, the current edition's dates (a label plus ISO start and end), the best day to go, when to book, the next edition where announced, a citable URL and a citation line, sorted by start date. With no filter it returns every event; month keeps events with any day in that month; country keeps one country. Use get_place with an event's URL for its full record (schedule, where to stay, tips). For every kind of destination in a month, not just events, use get_best_time. Read-only. Dates are for one edition, so check the page before booking. An invalid month or no match returns an error message.

ParametersJSON Schema

Name	Required	Description	Default
`month`	No	An English month name ("October", or "oct") or its number, 1 to 12 ("10"). Keeps events with any day in that month. Omit for the whole year.
`country`	No	Keep events in this country, by English name, e.g. "Mexico". Omit for every country.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`events`	No	Events, soonest first.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent status, but the description adds real behavior: results sorted by start date, invalid month or no match returns an error message, and dates reflect a single edition so the page should be checked before booking. Error and data-freshness caveats go well beyond the structured hints.

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 purpose and alternatives before the caveats, and mostly tight. The long enumeration of returned fields (name, kind, dates, best day, booking, URL, citation) duplicates the existing output schema rather than earning its place.

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?

With an output schema present and rich annotations, the description needs only usage and caveats, and it supplies both: routing to siblings, error behavior, and the "one edition only" warning. Nothing an agent needs 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both params; the description restates the filter semantics (month keeps any day in that month, country keeps one country) but adds the combined/omission behavior ("With no filter it returns every event"). That is a modest but real addition over the schema baseline of 3.

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 ("List") plus resource ("festivals and events") and named source ("Meridian Dispatch events guide"). It draws a clear boundary against siblings get_place and get_best_time, so an agent can select it 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?

Explicit routing: "Use get_place with an event's URL for its full record" and "For every kind of destination in a month, not just events, use get_best_time." Filter behavior when filters are omitted is also stated (no filter = every event).

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

list_nearbyList places nearbyA

Read-onlyIdempotent

Inspect

List the places Meridian Dispatch covers near a place or a coordinate, nearest first, for day trips from a base or what else to see near a sight. Without type it answers a day-trip question: up to 15 towns, each once at its nearest point, with its distance, summary, guide link, best few places and dispatches; a town's own sights are left out (get_destination has them). With type it returns a flat list of up to 20 places of that kind with distances. Distances are straight-line kilometres, not by road. Give place, or lat and lng together. For the sights inside one town use get_destination; to search by theme use search_guides. Read-only. An unknown place or nothing within the radius returns an error message.

ParametersJSON Schema

Name	Required	Description
`lat`	No	Latitude of the starting point in decimal degrees, e.g. 42.42. Give with lng, instead of place.
`lng`	No	Longitude of the starting point in decimal degrees, e.g. 18.77. Give with lat, instead of place.
`type`	No	Return a flat list of only this kind of place, e.g. "trail" or "event". Omit for the day-trip view grouped by town.
`place`	No	The starting point: a place name or meridiandispatch.com URL, e.g. "Kotor". Use this, or lat and lng.
`radius_km`	No	How far to look, in straight-line kilometres, 1 to 200. Defaults to 40; use 60 to 100 for a day trip by car.

Output Schema

ParametersJSON Schema

Name	Required	Description
`from`	No	The starting place's name, or the coordinate given.
`note`	No
`towns`	No	Without type: towns, nearest first.
`places`	No	With type: places, nearest first.
`radius_km`	No
`same_town`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), and the description adds substantive behavior on top: two distinct output modes, result caps (15 towns vs 20 places), deduplication at nearest point, that a town's own sights are excluded, that distances are straight-line not road, and that unknown places or empty radii return an error message. This is rich context an agent cannot get from the annotations.

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 ordering before any detail, and nearly every clause carries information (modes, caps, distance caveat, alternatives, error behavior). It is somewhat dense and semicolon-heavy with minor redundancy on the straight-line distance point, but there is no filler.

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?

Despite an output schema existing, the description still conveys the shape of results, the caps, the dedup rule, and failure behavior — so an agent knows what it will get and what errors mean. For a 5-parameter, dual-mode tool, nothing needed to call it correctly 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 coverage is 100%, so the schema already documents every parameter and the baseline would be 3. The description goes modestly beyond it by explaining the semantic consequence of `type` (flat list vs town-grouped day-trip view) and reinforcing the place-or-coordinate mutual exclusivity, though most of this is echoed in the schema 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?

States a specific verb and resource ('List the places Meridian Dispatch covers near a place or a coordinate') plus ordering ('nearest first') and the two modes of operation. It explicitly names the siblings it is not for ('get_destination has them', 'to search by theme use search_guides'), so an agent can route correctly without opening any schema.

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 concrete use cases ('day trips from a base', 'what else to see near a sight') and names two alternatives with the condition that selects them: get_destination for sights inside one town, search_guides for thematic search. When-to-use and when-not-to-use are both explicit.

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

search_guidesSearch the travel guidesA

Read-onlyIdempotent

Inspect

Search every Meridian Dispatch travel guide by keyword: long-form dispatches, multi-day itineraries, country and town guides, venues (sights, museums, beaches, parks), trails and scenic drives, events and ski resorts. Use it first when you do not know the exact page. Once you know the place, read it in full with get_destination (a country or town), get_place (one sight, trail, event or ski resort) or get_dispatch (a dispatch or itinerary); for ranked top-ten lists use list_best_places, for a month use get_best_time. Returns up to limit pages ranked by relevance, each with its type, title, country, town, a one-line summary, a citable URL and when it was last updated. Ranking is keyword-based with travel synonyms; a country or month named in the query is honoured. Read-only. When nothing matches it returns an error message; retry with a broader query or a place name.

ParametersJSON Schema

Name	Required	Description
`type`	No	Return only one kind of page: dispatch (a reported long-form piece), itinerary (a multi-day country route), country or town (destination guides), venue (one sight), trail (a hike or scenic drive), event (a festival), ski_resort or museum (must-see works with their rooms and floors). Omit to search all kinds.
`limit`	No	Most results to return, 1 to 20. Defaults to 8.
`query`	Yes	What the traveller wants, in plain words: a place name ("Kotor"), an activity and a place ("glacier hike Iceland") or a theme ("festivals in Japan").
`country`	No	Return only pages in this country, by English name, e.g. "Iceland". Omit to search worldwide.

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	No	Matching pages, best first.
`attribution`	No	The terms for quoting these pages.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world behavior, so the safety profile is handled. The description adds genuinely new behavior: keyword ranking with travel synonyms, honoring a country or month named in the query, the fields returned per result, and that a no-match query returns an error with a retry strategy. It does not mention auth or rate limits, but for a public read search that is minor.

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 capability, then routing, then return shape, then failure mode — a logical order with no filler. It runs long across three dense sentences, but every clause carries information the agent needs; only slight compression is possible.

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?

An output schema exists, so return values need not be described, yet the description still summarizes them. Combined with the routing rules, ranking behavior and error path, an agent has everything required to call this correctly and interpret the result.

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 the baseline is 3 and the schema already documents type, limit, query and country. The description still adds value beyond the schema by explaining that ranking is keyword-based with synonyms and that a country or month embedded in the free-text query is honored — real semantics for the `query` parameter that the schema does not state.

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 resource ('Search every Meridian Dispatch travel guide by keyword') and enumerates the covered content types, so an agent immediately knows the scope. It explicitly distinguishes itself from the read siblings it names (get_destination, get_place, get_dispatch, list_best_places, get_best_time).

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 an explicit routing rule: 'Use it first when you do not know the exact page', then names the alternatives to use 'once you know the place', and even splits ranked lists and month queries to their own tools. When-to-use, when-not-to-use and the substitute tools are all present.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

13 tool updatesOct 6, 2026

Removedbest_of
Changedcreate_itinerary_link28 fields changed
- 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"
+}
```
Addedget_best_time

Changedget_destination4 fields changed

changedInput schema / properties / country / description

Previous value: -"The country, to tell apart towns that share a name (Granada, Valencia, Mérida)."New value: +"The country of the town, by English name, to tell apart towns that share a name (Granada, Valencia, Mérida). Omit when name is a country or a unique town."

changedInput schema / properties / name / description

Previous value: -"A country or town name, e.g. \"Slovenia\" or \"Bled\"."New value: +"One country or town, by English name, e.g. \"Slovenia\" or \"Bled\". Case and accents are ignored. Not a sight or region: use get_place or search_guides for those."

addedInput schema / properties / name / minLength
```
Added value: +1
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "best_months": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "coords_note": {
+      "type": "string"
+    },
+    "country": {
+      "type": "string"
+    },
+    "country_guide": {
+      "description": "meridiandispatch.com URL.",
+      "type": "string"
+    },
+    "dispatches": {
+      "description": "Related long-form dispatches.",
+      "items": {
+        "properties": {
+          "country": {
+            "type": "string"
+          },
+          "last_updated": {
+            "type": "string"
+          },
+          "photo": {
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "town": {
+            "type": "string"
+          },
+          "type": {
+            "enum": [
+              "dispatch",
+              "itinerary",
+              "country",
+              "town",
+              "venue",
+              "trail",
+              "event",
+              "ski_resort",
+              "museum"
+            ],
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "fact_sheet": {
+      "description": "Structured planning data: nights, months, getting_there, where_to_stay, top_things, day_trips, watch-outs.",
+      "type": "object"
+    },
+    "lat": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "lng": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "name": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "overview": {
+      "description": "Opening paragraphs of the guide.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "photo": {
+      "description": "Lead photograph: url, alt text and credit.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "places": {
+      "description": "The places worth your time, ranked.",
+      "items": {
+        "properties": {
+          "lat": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "lng": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          },
+          "why": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "places_note": {
+      "type": "string"
+    },
+    "places_total": {
+      "type": "integer"
+    },
+    "planning": {
+      "description": "Short answers: days needed, best time, getting there, getting around, language, money.",
+      "type": "object"
+    },
+    "practical": {
+      "description": "Practical questions and answers not already covered by planning.",
+      "items": {
+        "properties": {
+          "a": {
+            "type": "string"
+          },
+          "q": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source": {
+      "description": "How to credit this answer: show cite_as, or link url.",
+      "properties": {
+        "canonical_url": {
+          "type": "string"
+        },
+        "cite_as": {
+          "description": "A ready-made citation line: title, publisher, date and URL.",
+          "type": "string"
+        },
+        "last_updated": {
+          "type": "string"
+        },
+        "license": {
+          "type": "string"
+        },
+        "publisher": {
+          "type": "string"
+        },
+        "terms": {
+          "type": "string"
+        },
+        "title": {
+          "type": "string"
+        },
+        "url": {
+          "description": "Link for the reader (carries referral tags).",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "stays": {
+      "description": "Hotels the guide recommends.",
+      "items": {
+        "properties": {
+          "lat": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "lng": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          },
+          "why": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "town_guides": {
+      "description": "For a country: its town guides.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "type": {
+      "enum": [
+        "country",
+        "town"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedget_dispatch3 fields changed

changedInput schema / properties / query / description

Previous value: -"A dispatch URL or slug (e.g. \"hallstatt\"), or the place it covers."New value: +"A dispatch or itinerary URL, its slug (e.g. \"hallstatt\", \"montenegro-beach-six-days\"), or the place it covers (e.g. \"Hallstatt\")."

addedInput schema / properties / query / minLength
```
Added value: +1
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "country_guide": {
+      "description": "meridiandispatch.com URL.",
+      "type": "string"
+    },
+    "excerpt": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "headline": {
+      "type": "string"
+    },
+    "lat": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "lng": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "note": {
+      "type": "string"
+    },
+    "photo": {
+      "description": "Lead photograph: url, alt text and credit.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "place": {
+      "type": "string"
+    },
+    "published": {
+      "type": "string"
+    },
+    "route": {
+      "description": "For an itinerary: bases, nights and day_by_day activities.",
+      "type": "object"
+    },
+    "source": {
+      "description": "How to credit this answer: show cite_as, or link url.",
+      "properties": {
+        "canonical_url": {
+          "type": "string"
+        },
+        "cite_as": {
+          "description": "A ready-made citation line: title, publisher, date and URL.",
+          "type": "string"
+        },
+        "last_updated": {
+          "type": "string"
+        },
+        "license": {
+          "type": "string"
+        },
+        "publisher": {
+          "type": "string"
+        },
+        "terms": {
+          "type": "string"
+        },
+        "title": {
+          "type": "string"
+        },
+        "url": {
+          "description": "Link for the reader (carries referral tags).",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "standfirst": {
+      "type": "string"
+    },
+    "themes": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "town_guide": {
+      "description": "meridiandispatch.com URL.",
+      "type": "string"
+    },
+    "type": {
+      "enum": [
+        "dispatch",
+        "itinerary"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedget_place5 fields changed

addedInput schema / properties / country / description

Added value: +"The place's country, by English name, to narrow a name shared by several places."

changedInput schema / properties / name / description

Previous value: -"The place name, e.g. \"Kotor Old Town\" or \"Grunas Waterfall\"."New value: +"The place's name, e.g. \"Kotor Old Town\" or \"Grunas Waterfall\". Exact names match first, then names that contain it."

addedInput schema / properties / town / description

Added value: +"The town the place is in or visited from, e.g. \"Kotor\", to narrow a name shared by several places."

changedInput schema / properties / url / description

Previous value: -"A meridiandispatch.com page URL."New value: +"The place's meridiandispatch.com page URL, from a search_guides or get_destination result. Takes priority over name."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "at_a_glance": {
+      "description": "Best time, time needed, effort, season, access.",
+      "type": "object"
+    },
+    "best_months": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "country": {
+      "type": "string"
+    },
+    "event": {
+      "description": "For an event: dates, best day, when to book, where to stay, schedule.",
+      "type": "object"
+    },
+    "lat": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "lng": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "name": {
+      "type": "string"
+    },
+    "overview": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "photo": {
+      "description": "Lead photograph: url, alt text and credit.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "practical": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source": {
+      "description": "How to credit this answer: show cite_as, or link url.",
+      "properties": {
+        "canonical_url": {
+          "type": "string"
+        },
+        "cite_as": {
+          "description": "A ready-made citation line: title, publisher, date and URL.",
+          "type": "string"
+        },
+        "last_updated": {
+          "type": "string"
+        },
+        "license": {
+          "type": "string"
+        },
+        "publisher": {
+          "type": "string"
+        },
+        "terms": {
+          "type": "string"
+        },
+        "title": {
+          "type": "string"
+        },
+        "url": {
+          "description": "Link for the reader (carries referral tags).",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "town": {
+      "type": "string"
+    },
+    "town_guide": {
+      "description": "meridiandispatch.com URL.",
+      "type": "string"
+    },
+    "type": {
+      "type": "string"
+    },
+    "why": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Addedlist_best_places

Changedlist_events3 fields changed

addedInput schema / properties / country / description

Added value: +"Keep events in this country, by English name, e.g. \"Mexico\". Omit for every country."

changedInput schema / properties / month / description

Previous value: -"A month name or number, e.g. \"October\" or \"10\"."New value: +"An English month name (\"October\", or \"oct\") or its number, 1 to 12 (\"10\"). Keeps events with any day in that month. Omit for the whole year."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "events": {
+      "description": "Events, soonest first.",
+      "items": {
+        "properties": {
+          "best_day": {
+            "type": "string"
+          },
+          "book": {
+            "type": "string"
+          },
+          "cite_as": {
+            "type": "string"
+          },
+          "dates": {
+            "type": "string"
+          },
+          "end": {
+            "description": "YYYY-MM-DD",
+            "type": "string"
+          },
+          "kind": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "next_edition": {},
+          "start": {
+            "description": "YYYY-MM-DD",
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          },
+          "where": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Addedlist_nearby
Removednearby
Removedsearch
Addedsearch_guides
Removedwhen_to_go

2 tool updatesOct 2, 2026

Changednearby1 field changed

changedInput schema / properties / type / enum

Previous value: -[
-  "dispatch",
-  "country",
-  "town",
-  "venue",
-  "trail",
-  "event",
-  "ski_resort"
-]New value: +[
+  "dispatch",
+  "itinerary",
+  "country",
+  "town",
+  "venue",
+  "trail",
+  "event",
+  "ski_resort"
+]

Changedsearch1 field changed

changedInput schema / properties / type / enum

Previous value: -[
-  "dispatch",
-  "country",
-  "town",
-  "venue",
-  "trail",
-  "event",
-  "ski_resort"
-]New value: +[
+  "dispatch",
+  "itinerary",
+  "country",
+  "town",
+  "venue",
+  "trail",
+  "event",
+  "ski_resort"
+]

1 tool updateOct 2, 2026

Changedcreate_itinerary_link3 fields changed

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"
+]

1 tool updateOct 2, 2026
- Addedcreate_itinerary_link
8 tool updatesOct 2, 2026
- First observedbest_of
- First observedget_destination
- First observedget_dispatch
- First observedget_place
- First observedlist_events
- First observednearby
- First observedsearch
- First observedwhen_to_go

Related MCP Connectors

EM Snow B
uk.co.extreme-media.snow
Ski resort conditions, forecasts, avalanche danger, sun, routes and snow history for 5,000+ resorts.
Weather Services Sports
211
VoyageHacks A
com.voyagehacks
Multilingual travel guides, gear picks and booking links for AI travel agents.
Travel & Transportation E-commerce & Retail
121
TourismMCP A
eu.projektionisten
Sights, events, opening hours, weather and tides; nearby sharing as currently reported.
Location Services Open Data Travel & Transportation
141
news A
media.probable
Cited news briefs and observed-corpus context. Free public reads; archives $0.10 or seven for $0.50.
Entertainment & Media Open Data
141

Related MCP Servers

Num — Personal Concierge
Travel & Transportation Location Services Search
aerozinnovation
A
license
Not graded
quality
C
maintenance
Travel places directory by 5arz: search 2.5M places, submit businesses and promos (human-reviewed).
Updated 23 days ago (2026-09-17 03:53 UTC)
MIT
Powder-Hound
Weather Services Travel & Transportation
zinscott
F
license
Not graded
quality
D
maintenance
Enables users to find the best ski resort snow conditions worldwide and search for flights to get there.
Updated 7 months ago (2026-03-24 23:19 UTC)
-
Departi MCP Serverofficial
Travel & Transportation Legal & Compliance
Departi
A
license
A
quality
B
maintenance
Travel compliance and trip planning for digital nomads — visa requirements, tax residency analysis, Schengen 90/180-day tracking, and curated accommodation, transport, and experience search across 189 European destinations.
Updated a month ago (2026-09-10 11:02 UTC)
7
MIT
onvaou-itineraires-mcpofficial
Travel & Transportation Location Services
onvaou-app
A
license
A
quality
C
maintenance
Bike, e-bike, kick scooter, motorcycle, wheelchair and walking routes across Europe, with up to three variants (safe, balanced, fast) and safety indicators such as cycle lane, main road and unpaved shares.
Updated 17 days ago (2026-09-23 12:26 UTC)
1
59 npm
MIT