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

TableJSON Schema

Name	Required	Description
`name`	Yes	Full first and last name
`email`	Yes
`phone`	Yes
`address`	Yes
`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

TableJSON 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.

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.9/5.0

Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: outside-area submissions become leads for office review, never book a job, Massachusetts out-of-area leads trigger an office callback flag, and lead submissions may send transactional SMS but do not authorize marketing texts. These side effects are critical for correct agent behavior and are not visible in annotations alone.

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 dense and front-loaded with the key decision rule, and every clause adds operational value. However, it is a single long paragraph with many embedded conditions, which makes it harder to scan quickly; structured bullets or separate sentences would improve readability.

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?

The description covers the main operational paths: in-area customer save, outside-area lead handling, the Massachusetts special case, the interaction with request_booking, and the correct confirmation behavior based on issue_description_saved. With an output schema present, nothing critical is missing for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 57% schema description coverage, the description meaningfully compensates by clarifying that issue_description must be customer-approved, that heard_about_us should be asked rather than inferred, that confirmed represents customer approval, and that address determines in-area versus outside-area handling. This goes well beyond the schema field names.

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?

The description states a specific action ('submit new customer form') and clearly scopes it to 'NEW customers only' after asking whether the customer has used the service before. It distinguishes this from related tools by noting it saves in-area customers or creates outside-area leads, and explicitly separates it from request_booking and request_out_of_area_callback.

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?

It gives explicit usage conditions: use after the 'Have you used us before?' question, only for new customers, and only after approval of required fields. It also tells the agent when not to call a sibling tool ('do not call request_out_of_area_callback afterwards') and where later booking notes go ('in-area booking notes are saved later with request_booking').

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?