TouristPads

Issue the official quote

request_quote

Idempotent

Issues the official numbered TouristPads quote for a confirmed order and emails it with its PDF to the customer from info@touristpads.com. Returns the quote number, the total and the link where the customer confirms and pays.

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": {
      "items": "<items>",
      "delivery_date": "<delivery_date>",
      "delivery_time": "<delivery_time>",
      "collection_date": "<collection_date>",
      "collection_time": "<collection_time>",
      "first_name": "<first_name>",
      "last_name": "<last_name>",
      "company": "<company>",
      "email": "<email>",
      "phone": "<phone>"
    },
    "name": "request_quote"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	The quote is emailed here.
`items`	Yes	What to rent. A stand is one line with its iPad (e.g. ipad-102-floorstand).
`phone`	Yes
`company`	Yes
`message`	No	Anything else the customer wants us to know (venue, event, special requests).
`last_name`	Yes
`first_name`	Yes
`apps_per_ipad`	No	Apps or files we pre-install on each iPad (0 = none).
`delivery_date`	Yes	YYYY-MM-DD, Singapore date.
`delivery_time`	Yes	24-hour HH:MM, between 06:00 and 23:00.
`apps_per_phone`	No	Apps or files we pre-install on each phone (0 = none).
`collection_date`	Yes	YYYY-MM-DD, Singapore date.
`collection_time`	Yes	24-hour HH:MM, between 06:00 and 23:00.
`steel_cable_locks`	No	Add a steel cable lock for every table-stand unit.
`after_hours_charge_agreed`	No	Whether the customer agreed to the after-hours charge on this order.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description still adds real behavioural value by disclosing that an external email is sent to the customer and that a numbered quote plus a customer-facing payment link is produced. It doesn't say whether re-issuing creates a second quote number (despite idempotentHint=true) or whether quotes can be revoked.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the first states the action and its external effect, the second states the return values. No filler, and the action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the mutation, its external side effect, and the return payload, which is enough for an agent to call a 15-parameter tool correctly given a 73%-covered schema. Gaps remain on failure modes (invalid email, unavailable dates) and on whether repeated calls create duplicate quotes.

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 73%, so the schema already explains email, items, the time formats, apps-per-device, cable locks, and the after-hours agreement. The description adds no parameter meaning at all — it doesn't explain the delivery/collection window constraint, what 'confirmed order' means in terms of required fields, or the after-hours agreement semantics. Baseline 3 for a mostly documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: issues the official numbered TouristPads quote, emails the PDF, and returns the quote number, total, and payment link. 'For a confirmed order' implicitly separates it from the price_rental sibling, but that separation is never made explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for a confirmed order' implies a prerequisite that the order has already been priced and confirmed, which hints at the sequencing with price_rental. There is no explicit when-to-use/when-not statement, no warning against using it for tentative enquiries, and no named alternative.

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

All TouristPads 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?