Skip to main content
Glama

HireNimbus home services MCP

Find handyman

find_handyman
Read-onlyIdempotent

Use when the user wants to find, search, or compare handyman professionals, or describes a problem a handyman solves — such as TV mounting, furniture assembly, a hole in the drywall, a door that won't close or latch, sticking or squeaky doors, caulking or grout repair, shelving or picture hanging, weatherstripping, fence or gate repair, loose deck boards, gutter cleaning or minor gutter repair, trim and baseboard work, small tile fixes, or paint touch-ups. Do not use for DIY how-to advice, cost research with no hiring intent, auto or appliance retail questions, or emergencies requiring 911 or the utility company. Read-only; does not create a booking. Showcase matching pros before any booking or OTP. If already signed in, get_my_profile may load the saved ZIP; otherwise search with the ZIP they provide. Prefer a 5-digit ZIP for location. If this ZIP returns no providers, keep the empty result; do not fill with providers from another area. 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
NameRequiredDescriptionDefault
pageNo
limitNo
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."
locationYesPrefer a 5-digit US ZIP for location (e.g. "22307" or "94114"). This is the primary and preferred location input. After get_my_profile, if address.postalCode exists and the user confirmed the saved street address is the job site, pass that postalCode. Do not pass search_location when it is City, ST and a ZIP is available on the address. Never pass a street address, formattedAddress, or address1.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • 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: -[
      -  "location",
      -  "context"
      -]New value: +[
      +  "location"
      +]
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description adds meaningful behavior: it does not create a booking, results should be shown before booking or OTP, empty ZIP results must remain empty rather than filling from another area, and the `context` parameter should be provided but omitting it will not fail the call. These details materially shape an agent's invocation and expectations.

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 longer than average, but almost every sentence earns its place by stating a use case, an exclusion, a location rule, or a behavioral guardrail. The example list of handyman tasks is extensive yet useful for classification; only slight redundancy with the schema's context description keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a finder tool with a rich output schema and safety annotations, the description covers invocation scenarios, location handling, empty results, booking behavior, and the context parameter requirement. It is complete enough for correct use, though page and limit semantics are not addressed and no sibling alternative is named for broader search scenarios.

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 schema already documents location and context well, and the description reinforces key constraints like preferring a 5-digit ZIP and using third-person, non-PII context. However, page and limit are left without any semantic explanation in either the schema or description, and schema coverage is only 50%, so the description does not fully compensate for the undocumented parameters.

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 ('find, search, or compare handyman professionals') and enriches it with concrete example tasks like TV mounting and drywall repair. It distinguishes this tool from book_handyman by explicitly noting it is read-only and from find_electrician/find_plumber etc. by focusing on handyman work.

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 gives explicit 'Use when' and 'Do not use for' guidance, including exclusions like DIY advice, cost research without hiring intent, and emergencies. It also provides sequencing advice involving get_my_profile and ZIP-based search, but it does not explicitly name alternative sibling tools for the excluded cases, so it stops just short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.