HandledIQ: find and book home service

Hold a time and text the link

hold_time

DestructiveIdempotent

Holds one open time from a quote for 10 minutes and has the shop text the person one link to book it. Use it only once the person has picked a price and a time, given their name and US mobile number, and said to go ahead. Side effect: the shop sends one text to that number. Nothing is booked until the person taps Book on the shop's page, where they also type their street address; you cannot book for them. Calling again with the same choice while the time is held sends no second text. The quote_id may come from any shop find_help or get_quote gave.

Input Schema

Name	Required	Description
`name`	Yes	The person's name, as they gave it.
`mobile`	Yes	The person's US mobile number, with its area code, as they gave it. The shop texts it once.
`time_id`	Yes	One of the quote's times, by its time_id.
`quote_id`	Yes	The quote_id price gave.
`option_id`	Yes	One of the quote's prices, by its option_id.

Output Schema

Name	Required	Description
`said`	Yes
`state`	Yes
`visit`	No	The booked visit as it stands now: its time, its tech, and what has happened since the yes.
`change`	No	A change the person's assistant asked for once booked: a cancel (done at once, free under the shop's terms), or a move (the shop texted the person a link, and done once they picked a new time).
`quote_id`	Yes
`held_until`	No
`minutes_left`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 21, 2026

changedInput schema / properties / mobile / description

Previous value: -"The person's US mobile number, with its area code. The shop texts it once."New value: +"The person's US mobile number, with its area code, as they gave it. The shop texts it once."

changedInput schema / properties / name / description

Previous value: -"The person's name."New value: +"The person's name, as they gave it."

removedInput schema / properties / street

Removed value: -{
-  "description": "The street address of the house, with its number.",
-  "type": "string"
-}

removedInput schema / properties / unit

Removed value: -{
-  "description": "Optional. The unit or apartment.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "quote_id",
-  "option_id",
-  "time_id",
-  "name",
-  "mobile",
-  "street"
-]New value: +[
+  "quote_id",
+  "option_id",
+  "time_id",
+  "name",
+  "mobile"
+]

Changed1 schema field changedOct 21, 2026

addedOutput schema / properties / change

Added value: +{
+  "description": "A change the person's assistant asked for once booked: a cancel (done at once, free under the shop's terms), or a move (the shop texted the person a link, and done once they picked a new time).",
+  "properties": {
+    "asked": {
+      "enum": [
+        "cancel",
+        "move"
+      ],
+      "type": "string"
+    },
+    "asked_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "done": {
+      "type": "boolean"
+    },
+    "texted_at": {
+      "format": "date-time",
+      "type": "string"
+    }
+  },
+  "required": [
+    "asked",
+    "asked_at",
+    "done"
+  ],
+  "type": "object"
+}

First observedOct 12, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the mutation/safety profile is partly given. The description adds real context beyond them: exactly one text is sent, nothing is actually booked until the person taps Book and enters their own address, and re-calling with the same choice sends no second text. It does not explain what the destructiveHint actually entails (e.g. the time is blocked from others during the hold), which is the one remaining gap.

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?

Front-loaded with the action and duration, then preconditions, then side effects and edge cases. Every sentence carries distinct information; nothing is filler or repeated from the 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?

With five required params, full schema coverage, an output schema, and annotations, the description fills the remaining gaps an agent needs: preconditions, the one-text side effect, the idempotent repeat behavior, and the fact that booking happens outside this tool. Nothing material 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 provenance the schema lacks: quote_id may come from any shop find_help or get_quote returned, and option_id/time_id are framed as selections from that quote. This meaningfully helps cross-tool chaining rather than restating 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?

States a specific verb, resource and scope: hold one open time from a quote for 10 minutes and trigger a single booking-link text. It is immediately distinguishable from siblings like get_quote, booking_status, or cancel_booking, and it names those related tools when explaining where quote_id comes from.

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 preconditions: use only once the person has picked a price and time, supplied name and US mobile, and said to go ahead. It also states a hard exclusion ('you cannot book for them') and explains the repeat-call case, so the agent knows both when and when not to call.

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

All HandledIQ: find and book home service 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?