Meridian Dispatch

Suggest a correction to a Meridian Dispatch page

suggest_edit

Send the Meridian Dispatch desk a correction to one of its pages. Use it when the traveller tells you something on a meridiandispatch.com page is wrong or out of date (a place has closed, moved, been renamed, changed its hours or now needs booking). Pass a source_url when the traveller gives one or one supports what they said. Do not use it for opinions, reviews or style. To read a page first, use get_place, get_destination or get_dispatch. Quote current_text exactly as it appears on the page (or in this server's answer about it); a quote that is not found is refused. Nothing changes immediately: the desk verifies every suggestion against its own sources before editing. Returns whether the suggestion was received and its id; the same suggestion sent twice is recorded once. A page that is not on meridiandispatch.com, a quote not on the page, or too many suggestions in an hour (per conversation, per address or per page) returns an error saying which.

Input Schema

Name	Required	Description
`url`	Yes	The meridiandispatch.com page to correct, as returned in source.url or canonical_url.
`field`	No	What kind of fact is wrong: status (closed, reopened), hours, location, access (booking, tickets, transport), dates (an event), name, description, or other.
`reason`	Yes	Why it is wrong, e.g. "The traveller says it closed in spring 2026" or "The official site lists new hours".
`source_url`	No	Optional: a page that supports the correction, ideally the place's own website. It speeds review.
`current_text`	Yes	The wrong text, quoted exactly from the page or from this server's answer about it.
`proposed_text`	Yes	What it should say instead, as plain text. Facts only, no prices.

Output Schema

Name	Required	Description
`id`	No
`next`	No	What happens to the suggestion now.
`page`	No
`received`	No
`duplicate`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 19, 2026

removedInput schema / properties / basis

Removed value: -{
-  "default": "traveller",
-  "description": "Who found the error: \"traveller\" (they told you) or \"own_research\" (a source you read contradicts the page; source_url is then required).",
-  "enum": [
-    "traveller",
-    "own_research"
-  ],
-  "type": "string"
-}

changedInput schema / properties / source_url / description

Previous value: -"A page that supports the correction, ideally the place's own website. Required when basis is \"own_research\"; otherwise optional but it speeds review."New value: +"Optional: a page that supports the correction, ideally the place's own website. It speeds review."

addedOutput schema / properties / duplicate
```
Added value: +{
+  "type": "boolean"
+}
```

AddedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: nothing changes immediately and the desk verifies against its own sources, exact-quote matching is enforced and refused if not found, duplicate suggestions are recorded once, and specific error conditions are enumerated (off-domain page, unmatched quote, per-conversation/address/page hourly rate limits). The dedup statement sits in mild tension with idempotentHint=false, but since the description also establishes that repeat sends can produce errors, this reads as nuance rather than a direct contradiction of the declared safety profile.

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?

Nine sentences is long, but each earns its place: eligibility, exclusions, alternatives, quote rule, verification model, return value, error semantics. The critical routing information (what it is, when to use, when not to) is front-loaded before the mechanics.

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 and the description still summarizes the return (received flag plus id), and it covers the failure modes an agent must anticipate. For a 6-parameter, 4-required mutation with no destructive risk, nothing needed for correct invocation 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 enforcement semantics the schema does not carry: current_text must be quoted 'exactly as it appears on the page (or in this server's answer about it)' and a quote that is not found is refused, plus guidance on when to supply source_url. That meaningfully extends the parameter documentation.

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 ('Send the Meridian Dispatch desk a correction to one of its pages') and immediately distinguishes itself from the sibling suggest_place by naming the target organization and the correction workflow. An agent can tell what this does 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?

Explicit trigger ('when the traveller tells you something on a meridiandispatch.com page is wrong or out of date') with concrete examples, an explicit exclusion ('Do not use it for opinions, reviews or style'), and named alternatives for reading first ('use get_place, get_destination or get_dispatch'). This is exactly the when/when-not/alternative pattern.

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?