Skip to main content
Glama
hcpapi

io.github.hcpapi/housecall-pro-mcp

by hcpapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

hcp_set_business_profile

Idempotent

Save or clear local business-profile sections—shop, vendors, pricing, payroll, and comms—for this installation. Each section replaces the stored section; pass null to clear it.

Instructions

Store one or more business-profile sections for this installation: shop, vendors, pricing, payroll, comms. Each section replaces the stored section whole, and null clears one - so save a section only after reading the whole section back to the user for a yes. The profile is this installation's own file, on this machine, beside the defaults file. Nothing in it is read from Housecall Pro or sent to it, or to anyone else. The sections hold the shop's own facts, never a customer's, and never credentials: a vendor's account_hint refuses anything that looks like a full account number.

Input Schema

NameRequiredDescriptionDefault
shopNoWho the shop is: trade(s), region, team size, and any peer group they benchmark against. Pass null to clear the section.
commsNoHow outbound messages should sound: sender name, a short voice sample in the shop's own tone, and the follow-up cadence in days. Pass null to clear the section.
payrollNoPayroll rules: when the pay week starts and the commission rules by role. Pass null to clear the section.
pricingNoPricing rules: the margin floor, per-category overrides, and how prices are rounded. Pass null to clear the section.
vendorsNoWho they buy from: vendor name, a shipped pack name when one matches, how purchase documents arrive, an account hint (never a full number), and any learned custom layout. Pass null to clear the section.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.19.0
    • changedInput schema / additionalProperties
      Previous value: -falseNew value: +true
  2. First observedv1.15.1

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond annotations: whole-section replacement semantics (critical given destructiveHint=false, since a partial-looking write actually overwrites), null-to-clear behavior, that the data lives in a local file and is never read from or sent to Housecall Pro, and that account_hint rejects account numbers. The privacy and credentials constraints are exactly the kind of disclosure annotations cannot carry.

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?

Front-loads the core action and then layers narrowing constraints; each sentence carries distinct information (sections, replacement, null, locality, credentials). It is dense but not padded, with only minor repetitiveness around the local/never-sent point.

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 mutation tool with no output schema and no required parameters, the description covers replacement semantics, clearing behavior, data locality, and the credentials prohibition – everything an agent needs to call it without surprising side effects. Nothing material 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: each section replaces the stored section whole and null clears it, and it clarifies the account_hint safety rule. That is genuine value on top of the per-field schema descriptions.

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?

Names the resource (business-profile sections), the verb (store), and enumerates the exact sections it touches (shop, vendors, pricing, payroll, comms), which cleanly distinguishes it from the sibling hcp_get_business_profile. An agent can tell immediately this is the write counterpart to the profile read.

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?

Gives an explicit precondition – "save a section only after reading the whole section back to the user for a yes" – which is real when-to-use guidance. It does not explicitly name hcp_get_business_profile as the read-before-write counterpart, so the routing to the sibling is left implicit.

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

Deploy Server

Other Tools