Skip to main content
Glama

HireNimbus home services MCP

by io.github.HireNimbus
OverviewDiscussionsAdmin

Get my profile

get_my_profile
Read-onlyIdempotent

Load the authenticated homeowner profile. Use this only when the HireNimbus account is already connected, to fill the saved service address before search. Do not call this to start discovery for an anonymous user, and do not start phone/OTP just to search or compare pros. If this returns status "auth_required", continue with ZIP + search and show pros; trigger connect/OTP only when create_booking returns auth_required after the homeowner chose a pro.

Returns GetMyProfileResult (structured JSON):

  • status (string, required): "ok", "error", or "auth_required"

  • name (string|null): homeowner full name when status is ok

  • phone (string|null): homeowner phone when status is ok

  • address (object|null): service street address with address1, address2, city, region, postalCode, country, formattedAddress

  • search_location (string|null): 5-digit ZIP from address.postalCode for search_providers.location (after user confirms the saved street address is the job site; never City, ST, the street line, formattedAddress, or address1)

  • error_code (string|null): "AUTH_REQUIRED" when status is auth_required

  • message (string|null): error or auth_required explanation

If address.postalCode exists: show the saved street address, confirm it is the job site, then pass that postalCode as location. If address.postalCode is missing: ask once "What's the ZIP for the job?" Do not ask for city/state first. Name, street, and phone can wait until preview/book.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contextNoAlways 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."

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoHomeowner full name from profile (present when status is ok)
phoneNoHomeowner phone from profile (present when status is ok)
statusYesOutcome: "ok" when profile loaded, "auth_required" when unsigned-in, "error" otherwise
addressNoFull service street address on file with fields address1, address2, city, region, postalCode, country, formattedAddress
messageNoError or auth_required explanation
error_codeNoStable code such as "AUTH_REQUIRED" when status is auth_required
next_actionNoWhen status is auth_required: "continue_discovery" means search and show pros without OTP; "connect_to_book" means start phone/OTP connect now
search_locationNo5-digit US ZIP from address.postalCode (e.g. "22307" or "94114") — pass to search_providers.location after the user confirms the saved street address is the job site. Never City, ST, a street line, formattedAddress, or address1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedOutput schema / examples
      Previous value: -[
-  {
-    "address": {
-      "address1": "123 Main St",
-      "address2": null,
-      "city": "Alexandria",
-      "country": "US",
-      "formattedAddress": "123 Main St, Alexandria, VA 22314",
-      "postalCode": "22314",
-      "region": "VA"
-    },
-    "message": null,
-    "name": "Jane Doe",
-    "phone": "+15551234567",
-    "search_location": "22314",
-    "status": "ok"
-  },
-  {
-    "address": null,
-    "message": "No authenticated homeowner profile found.",
-    "name": null,
-    "phone": null,
-    "search_location": null,
-    "status": "error"
-  }
-]New value: +[
+  {
+    "address": {
+      "address1": "123 Main St",
+      "address2": null,
+      "city": "Alexandria",
+      "country": "US",
+      "formattedAddress": "123 Main St, Alexandria, VA 22314",
+      "postalCode": "22314",
+      "region": "VA"
+    },
+    "message": null,
+    "name": "Jane Doe",
+    "phone": "+15551234567",
+    "search_location": "22314",
+    "status": "ok"
+  },
+  {
+    "address": null,
+    "message": "No authenticated homeowner profile found.",
+    "name": null,
+    "phone": null,
+    "search_location": null,
+    "status": "error"
+  },
+  {
+    "address": null,
+    "error_code": "AUTH_REQUIRED",
+    "message": "No HireNimbus account is connected. Searching and browsing pros works without an account.",
+    "name": null,
+    "next_action": "continue_discovery",
+    "phone": null,
+    "search_location": null,
+    "status": "auth_required"
+  }
+]
    • addedOutput schema / properties / error_code
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Stable code such as \"AUTH_REQUIRED\" when status is auth_required",
+  "title": "Error Code"
+}
    • changedOutput schema / properties / message / description
      Previous value: -"Error explanation when status is error"New value: +"Error or auth_required explanation"
    • addedOutput schema / properties / next_action
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "continue_discovery",
+        "connect_to_book"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "When status is auth_required: \"continue_discovery\" means search and show pros without OTP; \"connect_to_book\" means start phone/OTP connect now",
+  "title": "Next Action"
+}
    • changedOutput schema / properties / status / description
      Previous value: -"Outcome: \"ok\" when profile loaded, \"error\" otherwise"New value: +"Outcome: \"ok\" when profile loaded, \"auth_required\" when unsigned-in, \"error\" otherwise"
    • changedOutput schema / properties / status / enum
      Previous value: -[
-  "ok",
-  "error"
-]New value: +[
+  "ok",
+  "error",
+  "auth_required"
+]
  2. Changed3 schema fields changed
    • 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."
+]
    • changedInput schema / required
      Previous value: -[
-  "context"
-]New value: +[]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Despite annotations already marking the call read-only, idempotent, and non-destructive, the description adds meaningful behavioral detail: it can return ok, error, or auth_required, and prescribes what to do on auth_required. This goes beyond the annotations and matches the read-only safety profile without contradiction.

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 front-loaded with purpose and usage, and the later field list is mostly actionable (e.g., search_location must be a ZIP, never City or street). It is longer than strictly necessary because it restates return fields that an output schema would cover, but each section earns its place with operational guidance.

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?

For a tool with one well-documented parameter, strong annotations, and an output schema, the description supplies the missing orchestration: when to call, how to interpret auth_required, how to turn address.postalCode into search_providers.location, and what to do when postalCode is absent. An agent has everything needed to invoke it correctly.

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?

The only parameter, context, is fully specified by the input schema (always include, 15-25 words, third person, no PII), so schema coverage is 100%. The tool description itself adds no new parameter-level semantics, so the baseline 3 is appropriate.

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 opens with a specific action and resource: 'Load the authenticated homeowner profile.' It then states the exact niche (fill saved service address before search) and explicitly what not to use it for (anonymous discovery, phone/OTP), so it is easily distinguished from siblings like search_providers and create_booking.

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 when-to-use and when-not-to-use conditions: only when the HireNimbus account is already connected, only to fill the saved service address before search, never for anonymous discovery or OTP. It also names the alternative flow with create_booking for the auth_required case.

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 toolsInspect
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