plumbing-booking

Submit New Customer Form

submit_customer_info

Destructive

After asking Have you used us before?, use for NEW customers only after they approve full name, address, email, phone and where they found us. Include the customer-approved issue_description when the service or symptoms are already known. Saves an in-area customer; outside database coverage saves a lead with the supplied description for office review and never books a job. For a Massachusetts address outside the area that lead is also flagged for an ASAP office callback (office_callback_requested:true), so do not call request_out_of_area_callback afterwards. Say the description was saved only when issue_description_saved is true; in-area booking notes are saved later with request_booking. Lead submissions can notify the office and send a transactional SMS acknowledgment; they do not authorize marketing texts.

Input Schema

Name	Required	Description
`name`	Yes	Full first and last name
`email`	Yes	Customer email address as given; never invent it.
`phone`	Yes	Customer mobile number in any common US format; the booking SMS code goes here later.
`address`	Yes	Full service address: street, optional unit, city, two-letter state and five-digit ZIP (ZIP+4 accepted). The ZIP decides service-area coverage.
`confirmed`	Yes	Customer submitted or approved the new customer form, including any supplied issue description
`heard_about_us`	Yes	Where the customer found Johnson Bros; ask, never infer from the platform
`issue_description`	No	Customer-approved service and reported symptoms, if already provided. Preserved in outside-area office lead notes; do not invent a diagnosis. Optional so contact-only intake still works.

Output Schema

Name	Required	Description
`booked`	Yes
`status`	Yes
`message`	Yes
`success`	Yes
`next_step`	Yes
`record_id`	No	Saved office lead reference, when applicable.
`error_code`	No
`request_id`	Yes	Public operation receipt for support; never a provider customer ID.
`review_sandbox`	No
`in_service_area`	Yes
`in_massachusetts`	No	Outside-area leads only: whether the service ZIP is in Massachusetts.
`issue_description_saved`	No	True only after a supplied issue description was saved with an office-review lead. Customer creation alone does not save booking notes.
`office_callback_requested`	No	True when the outside-area lead was flagged for an ASAP office callback (Massachusetts addresses).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 21, 2026

addedInput schema / properties / address / description

Added value: +"Full service address: street, optional unit, city, two-letter state and five-digit ZIP (ZIP+4 accepted). The ZIP decides service-area coverage."

addedInput schema / properties / email / description

Added value: +"Customer email address as given; never invent it."

addedInput schema / properties / phone / description

Added value: +"Customer mobile number in any common US format; the booking SMS code goes here later."

Changed2 schema fields changedSep 25, 2026

addedOutput schema / properties / in_massachusetts

Added value: +{
+  "description": "Outside-area leads only: whether the service ZIP is in Massachusetts.",
+  "type": "boolean"
+}

addedOutput schema / properties / office_callback_requested

Added value: +{
+  "description": "True when the outside-area lead was flagged for an ASAP office callback (Massachusetts addresses).",
+  "type": "boolean"
+}

Changed4 schema fields changedSep 14, 2026

addedOutput schema / properties / next_step
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / record_id

Added value: +{
+  "description": "Saved office lead reference, when applicable.",
+  "type": "string"
+}

addedOutput schema / properties / request_id

Added value: +{
+  "description": "Public operation receipt for support; never a provider customer ID.",
+  "format": "uuid",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "success",
-  "status",
-  "in_service_area",
-  "booked",
-  "message"
-]New value: +[
+  "request_id",
+  "next_step",
+  "success",
+  "status",
+  "in_service_area",
+  "booked",
+  "message"
+]

Changed3 schema fields changedSep 14, 2026

changedInput schema / properties / confirmed / description

Previous value: -"Customer submitted or approved the new customer form"New value: +"Customer submitted or approved the new customer form, including any supplied issue description"

addedInput schema / properties / issue_description

Added value: +{
+  "description": "Customer-approved service and reported symptoms, if already provided. Preserved in outside-area office lead notes; do not invent a diagnosis. Optional so contact-only intake still works.",
+  "maxLength": 4000,
+  "type": "string"
+}

addedOutput schema / properties / issue_description_saved

Added value: +{
+  "description": "True only after a supplied issue description was saved with an office-review lead. Customer creation alone does not save booking notes.",
+  "type": "boolean"
+}

AddedSep 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare a destructive, open-world, non-idempotent write, and the description adds substantial context beyond that: it never books a job on outside-area leads, flags MA leads with office_callback_requested:true, triggers an office notification and transactional SMS acknowledgment without marketing consent, and conditions the 'saved' message on issue_description_saved being true. This is exactly the behavioral detail an agent needs and cannot get from 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?

The description is long but dense with actionable conditionals and is front-loaded with the key eligibility rule. Most sentences carry distinct operational information (coverage branch, callback flag, SMS vs marketing, save confirmation), though it borders on over-packed.

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 an output schema exists, return values need not be explained, yet the description still ties the agent to a specific output flag (issue_description_saved). For a complex multi-branch intake tool with nested address and 6 required params, nothing material 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 documents every field and its format. The description adds workflow meaning to issue_description ('include when the service or symptoms are already known') and the approval gate on confirmed, but it does not extend field-level semantics much beyond the schema, so the baseline 3 applies.

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 ('Saves an in-area customer; outside database coverage saves a lead') and scopes it precisely to NEW customers after the 'Have you used us before?' question. It distinguishes itself from siblings by naming request_booking and request_out_of_area_callback and explaining how this tool relates to them.

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 when-to-use ('for NEW customers only after they approve...'), when to include the optional field, and when NOT to use the alternative ('do not call request_out_of_area_callback afterwards' for MA out-of-area leads). The routing between booking, lead, and callback paths is fully spelled out.

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

All plumbing-booking 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?