mcp

Save a Tell & Go quote and have a person follow up

save_quote

Idempotent

Send a stay the traveller is considering (property, dates, party, the total you showed them) to the Tell & Go team, with the traveller's email (and phone if they want a call or WhatsApp), so a person follows up with them about it. Use it when the traveller is not ready to book now but wants the quote kept or wants help with it. It does not book, reserve or hold anything. ONLY call this after the traveller explicitly agreed to be contacted by Tell & Go about this request: ask first, in their language, and send consent.contact=true with consent.statement (the words they agreed to) and consent.obtained_from. Never call it on an assumed, implied or earlier consent, and never for someone else. consent.marketing stays false unless they separately agreed to receive offers. A person on the Tell & Go team replies, usually within a few hours (not around the clock). Nothing is booked, held or charged, and the price is not held: never tell the traveller otherwise. Relay message_for_user from the result.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "email": "<email>",
      "property_id": "<property_id>",
      "check_in": "<check_in>",
      "check_out": "<check_out>",
      "consent": "<consent>"
    },
    "name": "save_quote"
  }
}

Input Schema

Name	Required	Description
`name`	No	Optional traveller name.
`email`	Yes	The traveller's email address, exactly as they gave it to you. Never guess or reuse one from elsewhere.
`notes`	No	Optional notes for the team, in the traveller's words (room preference, occasion, best time to call).
`phone`	No	Optional phone/WhatsApp number in E.164 format (e.g. +447700900123), only if the traveller gave it and wants to be called or messaged.
`adults`	No	Number of adults (optional).
`consent`	Yes	Required record of the traveller's explicit agreement to be contacted. Ask first; never assume or infer it.
`check_in`	Yes	Check-in date YYYY-MM-DD.
`quote_id`	No	Optional quote_id from get_quote for this stay.
`check_out`	Yes	Check-out date YYYY-MM-DD.
`journey_id`	No	Continuity handle returned as journey_id in previous Tell & Go tool results. Always pass the most recent journey_id you have received in this conversation.
`property_id`	Yes	Property id or slug exactly as search_stays / get_quote returned it.
`quoted_total`	No	Optional total you showed the traveller (from get_quote). Informational only: it is not held and will be re-checked.
`children_ages`	No	Ages of children (optional).
`quoted_currency`	No	ISO 4217 currency of quoted_total, e.g. USD. Required with quoted_total.

Output Schema

Name	Required	Description
`intent`	No	save_quote or request_callback.
`status`	Yes	'received'.
`lead_id`	Yes	Reference for this request.
`property`	No	The resolved property (id, slug, name), or null.
`journey_id`	Yes	Continuity handle. Pass it back as journey_id on the next Tell & Go tool call. Treat it as confidential: it also unlocks get_booking for bookings made under it.
`next_steps`	No	reply_by, expected_reply and commitment: what the traveller should expect.
`deduplicated`	No	True when an identical request was already received; nothing new was created.
`consent_recorded`	No	The consent stored with the request.
`message_for_user`	Yes	Relay this to the traveller as written.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

changedInput schema / properties / consent / properties / marketing / description

Previous value: -"Optional, default false. True only if the traveller separately agreed to receive Tell & Go offers by email."New value: +"Ignored: this server never records marketing consent, because it cannot verify it. Leave it out."

changedOutput schema / properties / journey_id / description

Previous value: -"Continuity handle. Pass it back as journey_id on the next Tell & Go tool call."New value: +"Continuity handle. Pass it back as journey_id on the next Tell & Go tool call. Treat it as confidential: it also unlocks get_booking for bookings made under it."

AddedOct 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover idempotency, non-destructiveness and open-world reach, yet the description still adds substantive behavior: a human replies within hours (not round-the-clock), nothing is booked, held or charged, the price is not held and gets re-checked, and the agent must relay message_for_user from the result. The only minor gap is that the 'several hours' SLA is qualitative, with no statement about failure modes or what happens if consent record is malformed.

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 action and payload, then the gating rule, then the non-booking disclaimers — a sensible order for a safety-critical tool. It runs long and repeats the no-booking/no-price-hold point twice ('does not book, reserve or hold anything' and 'Nothing is booked, held or charged, and the price is not held'), which is defensible emphasis but is still duplication.

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 the description needn't explain return values, and it correctly focuses on the hard parts: consent collection, the non-booking guarantee, the human follow-up SLA, and the instruction to relay message_for_user. Nothing an agent needs to invoke this correctly and safely 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 the schema already carries the per-field meaning, making 3 the baseline. The description adds consent semantics that are genuinely useful, but it also drifts from the schema on consent.marketing: the description says it 'stays false unless they separately agreed to receive offers', while the schema says the field is ignored entirely and should be left out — that discrepancy adds confusion rather than meaning.

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 concrete verb and resource ('Send a stay the traveller is considering ... to the Tell & Go team') and enumerates the payload (property, dates, party, total, email/phone). It also draws the boundary explicitly — 'It does not book, reserve or hold anything' — which separates it from booking-oriented siblings like prebook_stay and start_booking.

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 triggering condition ('when the traveller is not ready to book now but wants the quote kept or wants help with it'), an explicit prohibition ('Never call it on an assumed, implied or earlier consent, and never for someone else'), and the required pre-step of asking in the traveller's language. The when/when-not pair is unusually complete.

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

All mcp 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.