HireNimbus home services MCP

Book same pro again

book_same_pro_again

Rebook a HireNimbus provider the homeowner has used before, by job ID. Requires authentication. Call with confirm_booking=false to preview the rebooking, then confirm_booking=true after homeowner approval. This tool may create a real booking request, including for an out-of-market address, because the provider is verified against the homeowner's owned prior job. Always pass optional context on this call (15-25 words, third person, abstract purpose only, no PII) so analytics can record why the tool was called. Omitting it does not fail the call; do not send an empty string.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Optional name override; omit to use authenticated homeowner profile
`phone`	No	Optional phone override; omit to use authenticated homeowner profile
`job_id`	Yes	Job ID from get_previous_jobs for the prior booking to rehire
`source`	No		AI Assistant
`address`	No	Optional street-level address override. Omit to use profile or prior-job address. Pass structured fields only (address1, city, region, postalCode, etc.) — never formattedAddress.
`context`	No	Always include this argument on every call — do not omit it (analytics / Agent Intent). Write 15-25 words in third person explaining why this tool is being called. Abstract purpose only: never names, phones, emails, street addresses, IDs, or other PII. Example: "Homeowner wants vetted local plumbers for a leaking kitchen faucet within the previously confirmed ZIP."
`location`	No	Optional geocoding hint when address lacks coordinates. Omit in normal flows. When needed, pass exactly one of: lat+lng, zip, or text.
`confirm_booking`	No	false (default): return a rebooking preview; does NOT submit. true: submit the rebooking after the homeowner explicitly confirms.
`job_description`	No	Description of the new work; omit to reuse the prior job description

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 16, 2026

addedInput schema / properties / context / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / context / default
```
Added value: +null
```

changedInput schema / properties / context / description

Previous value: -"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""New value: +"Always include this argument on every call — do not omit it (analytics / Agent Intent). Write 15-25 words in third person explaining why this tool is being called. Abstract purpose only: never names, phones, emails, street addresses, IDs, or other PII. Example: \"Homeowner wants vetted local plumbers for a leaking kitchen faucet within the previously confirmed ZIP.\""

addedInput schema / properties / context / examples

Added value: +[
+  "Homeowner wants vetted local plumbers for a leaking kitchen faucet within the previously confirmed ZIP.",
+  "Homeowner is comparing HVAC pros after a no-cool air conditioner at the confirmed job site."
+]

addedInput schema / properties / context / title
```
Added value: +"Context"
```
removedInput schema / properties / context / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "job_id",
-  "context"
-]New value: +[
+  "job_id"
+]

First observedSep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations indicate readOnlyHint=false (mutation allowed). The description explicitly discloses that the tool 'may create a real booking request,' including out-of-market addresses, and requires homeowner approval before confirmation. It also details the context parameter's optional nature and warns against empty strings. This goes well beyond the annotations.

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?

Every sentence earns its place: purpose, safety warning, preview/confirm flow, context requirement, and parameter clarifications. The structure is front-loaded with the core action and then details, making it easy for an agent to parse quickly.

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 tool has 9 parameters (1 required) and an output schema, but the description covers all critical behavior: rebooking flow, side effects, out-of-market handling, context usage, and address overrides. Nothing an agent needs to call it correctly 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 description coverage is 89%, so most parameters are self-explanatory. The description adds extra meaning for `context` (always include, 15-25 words, third person, no PII) and `confirm_booking` (false=preview, true=submit). It also clarifies the address override and location hints, going beyond the schema.

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 verb and resource: 'Rebook a HireNebula provider the homeowner has used before, by job ID.' It clearly distinguishes from sibling book_* tools by targeting a prior provider, not a trade. The preview/confirm flow adds precision.

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

Usage Guidelines4/5

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

The description explains when to use it (rebooking a previously used provider) and provides a clear two-step flow (preview with confirm_booking=false, then confirm after homeowner approval). It also warns about out-of-market addresses. It doesn't explicitly name alternatives or state when NOT to use it, but the context is sufficient.

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

All HireNimbus home services 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.