io.github.hcpapi/housecall-pro-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@io.github.hcpapi/housecall-pro-mcpShow me all jobs scheduled for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Housecall Pro MCP Server
An open-source MCP server for the Housecall Pro API. Connect Claude, ChatGPT, Cursor, or any MCP-compatible AI agent to your Housecall Pro account, so you can ask for what you need instead of clicking through reports.
Independent project, not affiliated with, endorsed by, or sponsored by Housecall Pro. We run a service company on Housecall Pro ourselves, which is why it exists.
Install
Needs Node 18 or newer and a Housecall Pro API key. API access comes with the MAX plan and is not available on lower tiers.
Claude Desktop. Open Settings, then Developer, then Edit Config, and add:
{
"mcpServers": {
"housecall-pro": {
"command": "npx",
"args": ["-y", "housecall-pro-mcp"],
"env": { "HCP_API_KEY": "your-api-key-here" }
}
}
}Restart Claude Desktop and the Housecall Pro tools will appear.
Claude Code. Add it directly:
claude mcp add housecall-pro -e HCP_API_KEY=your-api-key-here -- npx -y housecall-pro-mcpOr install it as a plugin, which prompts for the key (stored in your keychain, never in a config file) and exposes the read-only and toolset switches as install-time options:
/plugin marketplace add hcpapi/housecall-pro-mcp
/plugin install housecall-pro@hcpapiCursor, Codex, and other MCP clients. Any client that speaks MCP over stdio
works. Use npx as the command, ["-y", "housecall-pro-mcp"] as the arguments,
and put HCP_API_KEY in the environment.
Getting a key takes about a minute and is described under Getting your Housecall Pro API key.
Related MCP server: invoiceninja-mcp
Housecall Pro API quirks, and what this server does about them
These are the edges of the Housecall Pro API itself. Each one is a place an integration built from the documentation alone gets a wrong answer rather than an error.
What the API does | What this server does about it |
Money is integer cents, so $250 is | Converts in both directions. $250 stays $250 and never arrives as $2.50. |
| Sends only the nested schedule object the API honours, so a reported success is a real one. |
A job's description is derived from its line items and cannot be set directly. | Exposes line-item writes rather than a description field that would silently do nothing. |
Invoices filter on | Uses the names the endpoint actually takes, and walks a service-date window client-side because no server-side equivalent exists. |
| Normalises on read, so a status filter matches real records instead of nothing. |
Deleted jobs still appear in list responses and count toward totals. | Surfaces |
Removing a tag from a job answers with an empty success whether or not the tag was there. | Reports the request as accepted rather than claiming a removal it cannot confirm. |
An archived job refuses to describe its appointments. | Flags the job as archived and returns an empty list, so a sweep never stops part way. |
The invoice document is a very long HTML page, not a PDF. | Returns the opening of the page and says how much of it that was. |
Attachments have no route of their own — | Asks with |
Some routes answer only on | Uses the method each route actually takes, so dispatching a crew and bulk line-item updates work instead of looking absent. |
Never trust a 2xx on a Housecall Pro write. Read the record back. Several routes answer 200 without changing anything, which is why the rows above exist.
Documented routes that do not exist
Housecall Pro's published documentation describes these. They are not there. An integration built from the docs alone ships broken code paths for each one.
Documented | Reality |
| Absent. Appointments exist only nested under a job. |
| Absent. |
| Absent. |
| Absent. There is no public customer delete. |
| Absent. Addresses are append-only. |
| Absent. |
| Absent as writes: a lead cannot be updated or deleted. Reading works — |
| Absent. A tag can never be deleted through the API. |
| Absent. |
| The verb is absent, not the route: |
| Absent. Materials and categories create normally. |
| Absent. |
What you can ask
"How much did we invoice in June, grouped by service?"
"List this week's scheduled jobs with outstanding balances"
"Pull up the customer record for the Smiths on Elm Street"
"Which customers are tagged 'Service Plan'?"
"Export Q2 invoices as CSV"
"What's in our price book for water heaters?"
"When is job_123 booked, and who is going?"
"Show me invoice_123 the way the customer sees it"
"Add a new customer: John Baker, 22 Elm St, Springfield IL, +1 555 123 4567"
"Draft a good/better/best estimate for cus_123: water heater replacement at $2,400 / $3,100 / $3,900"
"Book Tuesday 8-10am on job_123 for Mike"
"Move that visit to Thursday morning and put Dave on it instead"
"Dispatch Mike and Dave to job_123"
"Reprice every labor line on job_123 in one go"
"The customer went with the middle option on that estimate - mark it approved"
"What hours do we work, and what's free next week?"
"Default our jobs to 90 minutes with a two-hour arrival window"
Getting your Housecall Pro API key
Sign in to Housecall Pro as an admin. Office staff logins cannot generate keys.
Open My Apps, the grid icon in the top bar
Click Go to App store, search for API, and open API Key Management. It will usually not be sitting in the My Apps menu already, because that menu lists a subset rather than the whole catalogue.
Click Generate new API key, name it, and choose its access level:
Read-only, for reporting, lookups and exports. It refuses writes across the account with one exception we have measured: the price-book routes under
/api/price_book/are not covered by that gate, and a read-only key can create and delete price-book categories there. If you want a guarantee rather than nearly one, run this server with--read-only, which does not register a write tool at all.Full access, which also allows creating customers, jobs and estimates.
Copy the key. Housecall Pro keeps it visible on that page afterwards, so you can come back and copy it again. What you cannot do is edit a key: changing the access level means generating a new one and deleting the old.
The walkthrough with screenshots is at https://hcpapi.com/mcp/#key.
The access level you pick is the real boundary. This server follows whatever you generated, so a read-only key cannot reach the write tools at all. If you want an assistant that only answers questions, generate a read-only key and Housecall Pro enforces that limit for you.
Only an admin can generate a key, and admins have full account access, so the key reaches the whole account rather than one person's slice of it.
Tools
95 tools. Reading works with any key; writing needs a full-access one. They are grouped into toolsets, so an install can register only the groups it needs - see Choosing which tools to register.
Reading
Tool | What it does |
| Company profile, with the account's time zone and its default arrival window |
| The hours the account works, and how far ahead it takes bookings |
| The slots Housecall Pro reports as bookable, and which of them are open |
| Search or list customers, or filter by tag |
| One customer's full record |
| Whether customers are safe to contact - unions every do-not-contact signal the API can read, and names the one it can't |
| Jobs by status, schedule window, or customer |
| One job's full record |
| A job's notes, and the account's total job count |
| A job's booked visits, windows and technicians |
| One job's line items, priced in dollars |
| What was actually used on a job, as distinct from what was billed |
| Checklists attached to jobs or estimates |
| Invoices in a date range, filterable by status ( |
| One invoice in full, with payments, refunds and balance |
| A single job's invoices, without walking the whole list |
| A preview of the invoice page as the customer sees it |
| Estimates with option totals |
| Line items on an estimate option |
| Unconverted enquiries, and one lead with its line items |
| Calendar entries that are not jobs, with recurrence and attendees |
| One address by id, when you have the id and not the customer |
| The API application registered on the account, if any |
| A date's routes: employees grouped with their assigned work |
| Service areas with zip codes and trip charges, and whether a zip is covered |
| The workflow stages configured for jobs, leads or estimates |
| Services, materials, categories, price forms |
| Bookable service templates, with durations and booking questions |
| Employees and roles |
| Account lookups |
| Invoiced revenue by month or line item |
| Turn findings into one self-contained interactive HTML report — sortable tables, selectable rows, print. Makes no API call |
| CSV export of customers, jobs, invoices or estimates |
| What the API actually does for a topic, where that differs from its documentation. Answers from a compiled table, so it makes no request |
Writing
Needs a full-access key.
Tool | What it does |
| Create a customer, or change one's fields |
| Add a service address to a customer |
| Create an unscheduled job |
| Add line items to a job |
| Change one line item on a job, or take it off |
| Change several of a job's line items in one call |
| Add an internal note, or take one off. The delete is confirmed by re-reading the job |
| Attach a photo or document to a job, passed as base64. Confirmed against the job's attachment list. There is no public route to remove one |
| The same for an estimate option. Cannot be read back, so keep the returned id |
| Book a visit for an estimate option and dispatch to it. |
| Attach a titled link. Needs an application on the account, or answers "Application not found" |
| Freeze a job, or everything from a date. No unlock exists on this API — a dashboard action, so ask first |
| Enable or disable the account's API application. Affects every integration on the account |
| Subscribe or unsubscribe a delivery URL. Partner-gated, and a subscription is dropped after one 5xx from your endpoint |
| Replace what a job records as used on site. A whole-list replace, so read it first |
| Put a tag on a job, or take it off |
| Book a visit on a job with technicians dispatched, which schedules the job |
| Move a visit, change who is dispatched to it, or both |
| Take one visit off a job |
| Clear a job's visits and its schedule, back to needs scheduling |
| Put a crew on a job's work. Customer-visible, so treat it as reaching them |
| Draft a multi-option estimate, or add an option to one |
| Record the customer's answer on one or more estimate options |
| Replace the line items on an estimate option. A whole-list replace |
| Note an estimate option. These cannot be read back, so keep the id |
| Create a lead |
| Turn a lead into an estimate or a job. The lead survives it |
| Create a tag, or rename one |
| Create a job type, or rename one. Deleting one is a dashboard action |
| Create or rename a lead source, the validation list for |
| Add, change or remove a price-book material |
| Add, rename or remove a price-book material category |
| Add, change or remove a bookable service template |
Shop defaults
Tool | What it does |
| Read the defaults stored for this installation |
| Store one or more, or clear one by passing null |
| Read the business profile: who the shop is, their vendors, pricing, payroll and messaging rules |
| Store one or more profile sections, or clear one by passing null |
Three preferences are kept: how long a job is scheduled for when nobody says otherwise, how wide an arrival window is by default, and the name of the line item most jobs start from. They save answering the same question twice.
They live in a file the server owns. HCP_MCP_DEFAULTS_PATH names it outright
if you set it; otherwise it is %APPDATA%\housecall-pro-mcp\defaults.json on
Windows and $XDG_CONFIG_HOME/housecall-pro-mcp/defaults.json elsewhere,
falling back to .config/housecall-pro-mcp/defaults.json under your home
directory. That location is per machine and not per Housecall Pro account: the
file belongs to the installed server, so a shop running this on two computers
sets its defaults on each. Nothing in it is sent to Housecall Pro, and the keys
it accepts are a closed set, so nothing about a customer or a job can be parked
in it.
The business profile is the bigger sibling, made for skills that run a
setup interview: five sections - shop, vendors, pricing, payroll,
comms - covering who the shop is, who they buy from and how their documents
arrive, margin and rounding rules, pay-week and commission rules, and how
outbound messages should sound. A skill reads it before asking setup questions
so nothing is asked twice; each section records the date it was last confirmed,
and sections are replaced whole, which is why a skill saves only after reading
the section back for a yes. Same file conventions as the defaults
(HCP_MCP_PROFILE_PATH override, profile.json beside defaults.json), same
privacy posture: per machine, never transmitted, closed section set, nothing
about any customer - and a vendor account_hint refuses anything that looks
like a full account number.
Building the desktop bundle
manifest.json describes this server as an MCP bundle, which installs into a
desktop client by drag-and-drop with no Node install and no config file to edit.
npx -y @anthropic-ai/mcpb pack .That writes housecall-pro-mcp-<version>.mcpb. .mcpbignore keeps build-time
dependencies out of it; without those rules the bundle carries the TypeScript
compiler and is nearly three times the size. The bundle asks the user for their
API key, and optionally for read-only mode and a toolset list, in the client's
own settings interface rather than in a file.
Choosing which tools to register
Every tool the server registers is a tool the client has to hold in context before it does any work, and a longer list makes a client choose worse among the tools that matter. So the surface is selectable.
# Only what a reporting session needs, and nothing that can change anything
npx -y housecall-pro-mcp --read-only --toolsets=reports,invoices,customersOption | Effect |
| Registers no tool that can change anything. Also |
| Registers only these groups. Also |
| Lists the groups and exits |
Groups: company, customers, jobs, estimates, invoices, pricebook,
schedule, reports, admin. Also all, and default for the default set.
admin is tag, job-type and price-book structure maintenance - the writes
that reshape those registries. It is not in the default set, because a
booking or reporting session never needs it and leaving it out keeps the
starting surface smaller. Ask for it by name, or use --toolsets=default,admin.
Listing tags and job types is not admin: those reads are how ordinary job data
gets interpreted, so they are always in the default set.
A misspelled group name stops the server with a message naming the valid ones, rather than starting with tools missing. An install that quietly exposed nothing would look exactly like the API being unreachable.
--read-only is a second, independent thing from the access level of your key.
A read-only key already refuses writes at the API. This refuses to register them
at all, which is what you want when pointing an agent at a live account to look
around: the write tools are not merely guarded, they are absent.
Without HCP_API_KEY the server still starts, keyless: only the tools
that never call Housecall Pro register - hcp_render_report, hcp_api_notes
and the business-profile pair - and nothing can reach a Housecall Pro account.
That keeps the report renderer available when you are working from dashboard
CSV exports rather than the API, and lets a skill's setup interview run before
a key exists.
What the server tells the model up front
Two of this project's tables are compiled into the server rather than left in this README, because a README is read by people and never by the model.
The connect-time instructions carry the rule that prevents the worst failure: never trust a 2xx on a Housecall Pro write, read the record back.
hcp_api_notesanswers a plain-language question about what the API actually does - a route, a field, or the thing you were trying to do - from the same verified table behind the two sections above. It makes no request, so it costs nothing. Ask it before concluding something cannot be done, and after any write that reported success but looks like it changed nothing.The same tables are also exposed as MCP resources (
hcp://api-notes/quirksandhcp://api-notes/phantom-routes) for clients that can read a resource without spending a tool call.
How it behaves
The write tools only work with a full-access key. Call one with a read-only key and it fails with a plain message telling you why, rather than doing something you did not expect.
Every tool carries the spec's annotations, so a client can tell a read from a
write, a write from a delete, and either from something that reaches the
customer, without having to infer it from the name. hcp_dispatch_job and the
estimate approve and decline tools are marked as possibly notifying the
customer, because they are.
No tool here sends an email, a text or an estimate on your behalf. Drafting an estimate leaves it sitting as a draft, and sending it stays a deliberate action you take inside Housecall Pro.
Dispatching a crew is customer-visible. hcp_dispatch_job puts technicians
on a job's work, and that route is one the customer can see: Housecall Pro may
tell them who is coming and that someone is on the way. What it sends has not
been watched either way, so treat it as reaching the customer rather than
assuming it does not.
Recording an answer on an estimate option is the shop writing down what the
customer said, not a request going out to ask. Housecall Pro's own word for the
result is "pro approved" or "pro declined", which is what
hcp_approve_estimate_options and hcp_decline_estimate_options record. Doing
it emailed and texted nobody when it was exercised. That is not a promise for
your account: Housecall Pro's automations and notification settings send on
their own, whatever any single call does, and one account's configuration says
nothing about another's. On an account set up to copy an approved option to a
job, approving creates one and the response names it.
Changing several line items is one call.
hcp_update_job_line_items hands Housecall Pro the whole list in a single
request. hcp_update_job_line_item is one request per row, so a run of them can
stop half way and leave a job part-repriced; use it when exactly one row is
changing and the bulk tool when more than one is.
Booking a job is one call. Creating an appointment on a job also sets that
job's schedule, so hcp_schedule_job_appointment books the work and dispatches
it together: the job stops reading as needs scheduling, and the visit lands on
the technicians you named. Call it again on the same job to add a second visit.
Every appointment needs at least one technician, and one that names nobody is
refused here rather than sent.
Moving a visit with hcp_update_job_appointment moves the job's schedule with
it, so a reschedule is also one call. Undoing a booking is
hcp_delete_job_appointment for a single visit, or hcp_unschedule_job to take
every visit off and return the whole job to needs scheduling.
Before offering a customer a time, hcp_get_schedule_availability gives the
hours the account works and hcp_list_booking_windows gives the slots it
reports as bookable, so what you offer matches what the account actually does.
None of these calls emails or texts the customer itself. What Housecall Pro does send is its own appointment reminders as the date approaches, which depends on your account's settings rather than on this server. Automations you have set up in Housecall Pro run on their own, outside this server's control.
A failed write is never retried automatically, so a network hiccup cannot quietly create the same record twice.
Your API key goes only to api.housecallpro.com. The only other request this
server ever makes is the version check described under Updating, which carries
no account data.
Where your keys go
One key is configured, and it reaches exactly one host.
Your Housecall Pro API key (
HCP_API_KEY) goes only toapi.housecallpro.com. Nothing read from your Housecall Pro account is sent anywhere else.
The only other request this server ever makes is the version check described under Updating, which carries the product name and installed version and nothing else.
Limitations
A few more edges that are shape rather than quirk.
Appointments belong to a job. There is no account-wide appointment list, so
you reach visits one job at a time. Ask for a job's appointments, not for
"every appointment this week". The account's own schedule does read account
wide: hcp_get_schedule_availability returns the hours it works and
hcp_list_booking_windows the slots it reports as bookable.
An arrival window has to be a width Housecall Pro accepts: 0, 15, 20, 60, 120, 180 or 240 minutes, where 0 means an exact time. It rejects any other number on the write, so the booking tools offer the accepted widths as a list rather than a free number.
A booking can be undone; the job cannot be deleted. hcp_unschedule_job
takes the visits off and clears the schedule, leaving the job at needs
scheduling with its customer, line items and notes intact. Housecall Pro's API
has no route that deletes a job, so a job created by mistake is closed out in
Housecall Pro itself.
A customer address is append-only. hcp_create_customer_address adds one,
and no route changes or removes it afterwards. Get it right before adding it; a
wrong one is corrected in Housecall Pro.
Taking a tag off a job is one tag at a time. hcp_remove_job_tag needs the
job and the tag; there is no call that clears every tag from a job at once. It
also needs a key whose permissions cover tag changes, so a 401 here means the
key's access level rather than a missing feature.
Checklists must be asked for by job or estimate. There is no way to list every checklist on the account, and an empty answer means no checklist has been set up for those records rather than that something went wrong.
Tags are created and renamed, never deleted. Deleting a tag from the account is done in Housecall Pro. Create them sparingly.
Updating
On startup the server checks hcpapi.com for a newer version; the request carries the product name and installed version, and nothing else. If a newer version exists, the next tool response mentions it once. If the check cannot complete, the server just carries on.
To update, re-run the install command for your client; the npx setups in
Install pull the latest published version. If your client is holding on to an
older cached copy, change the arguments to
["-y", "housecall-pro-mcp@latest"] to force the newest release.
Troubleshooting
401 Unauthorized. Either the key is read-only and you called a write tool, or the employee who created it does not have permission for that data. Generate a full-access key, or check that employee's permissions.
Empty results where you expected data. Usually the same cause. An employee-scoped key only returns what that employee can see.
No tools appear in your client. Check that you have Node 18 or newer with
node --version, and that HCP_API_KEY is set inside the MCP server's env
block rather than in your shell.
Going further
This server covers the Housecall Pro API itself. We are building the layer that sits on top of it: reporting and export workflows, price book tooling, and webhook setup. If that sounds useful, email hello@hcpapi.com and we will tell you when it is ready.
Issues and pull requests
Bug reports and feature requests are welcome in the issue tracker, and the more of them the better — say what you asked your assistant to do and what came back.
Pull requests are closed automatically. Releases are validated against an internal test suite that a pull request cannot run, so there is no honest way to review one here. Telling us what is broken in an issue gets it fixed faster than a patch would.
License
MIT, copyright HCP API. Independent project, not affiliated with Housecall Pro. "Housecall Pro" is a trademark of its owner, used here only to describe compatibility.
Available Tools
4 toolshcp_api_notesARead-onlyIdempotent
Look up what the Housecall Pro API actually does for a given topic, as opposed to what its published documentation says. Call this BEFORE concluding that something cannot be done, before retrying a route that returned 404, and after any write that reported success but looks like it changed nothing. It answers from a table of verified behaviour: routes the documentation describes that do not exist, writes that are accepted and silently ignored, and fields whose units are not what they appear to be. Ask in plain words - a topic, a route, a field name, or the thing you were trying to do. Omit the topic to read the whole table. This tool reads a table compiled into this server and makes no API call, so it costs nothing and cannot fail.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | What you are working on. A route ("PATCH /jobs"), a field ("work_status"), or a goal ("set a job description", "create an invoice"). Omit for everything. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds further context by revealing that the tool makes no API call, reads a local compiled table, costs nothing, and cannot fail. This enriches the behavioral profile beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence delivers crucial guidance: purpose, when to call, content of the table, how to phrase queries, and the no-cost/no-fail guarantee. It is front-loaded with the core purpose and structured logically, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, rich annotations, and no required output schema, the description fully explains what the tool does, what it contains, and what to expect. It leaves no significant gaps for an agent to misuse it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a thorough description for the single 'topic' parameter, including examples and the omission rule. The description's mention of 'plain words' is redundant with the schema's guidance. With 100% schema coverage, the description adds no meaningful parameter semantics beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's unique purpose: looking up verified behavior of the Housecall Pro API versus its published docs. The verb 'look up' combined with the resource (verified behavior table) distinguishes it from sibling tools like hcp_get_business_profile or hcp_set_business_profile, which make actual API calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use the tool: before concluding something cannot be done, before retrying a 404, and after a write that appears to have no effect. Also provides alternatives by contrasting with published documentation, making the use cases unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcp_get_business_profileARead-onlyIdempotent
Read the business profile stored for this installation: who the shop is, who they buy from, their pricing rules, their payroll rules, and how their outbound messages should sound. Skills read this before asking setup questions, so an interview answered once is never asked twice; missing_sections is what a first run still has to ask, and each stored section carries the date it was last confirmed. 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. An empty profile is the ordinary state of a fresh install, not a problem.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond these: that no data is read from or sent to Housecall Pro or anyone else, that an empty profile is normal for fresh installs, and that sections carry confirmation dates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: content overview, usage guidance, and privacy/edge-case behavior. It is front-loaded with the core read action and then provides necessary context without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return semantics (missing_sections, section dates) and covers data locality and empty-profile handling. It offers a complete mental model for an agent to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description compensates by explaining what the returned structure contains (missing_sections, sections with dates), which is helpful in the absence of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and identifies the resource as 'the business profile stored for this installation', clearly distinguishing it from siblings like hcp_set_business_profile. It enumerates profile contents (pricing rules, payroll rules, etc.), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: 'Skills read this before asking setup questions' and explains that missing_sections indicates what a first run still needs to ask. It does not explicitly name alternative tools or state when not to use it, but the occasion is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcp_render_reportARead-onlyIdempotent
Render a findings report into one self-contained, offline, interactive HTML file — sortable and filterable tables, severity-coded sections, collapsible worklists, selectable rows that copy back to chat, light and dark theme, print. This is a presentation tool: it makes no Housecall Pro call and takes findings you already have.
Pass a report contract. Required keys: skill, title, sections (an array). Each section has a title, an optional severity (confident|ok|warning|blocked|info|neutral), and blocks (an array). A block is one of: table ({columns:[{label,numeric?}], rows:[[cells]], selectable?, collapsedRows?, defaultSort?}), prose/lead ({html}), list ({items,crosses?}), subhead ({text}). Optional top-level keys: kicker, stats (cards), coverage, headline, order (suggested work), meta, generated, provenance, closing. In table cells and list items, `backticks` render as chips, **stars** as bold, and [text](https://...) as a link opening in a new tab (http/https only) - use it to link records to their pages in the owner's own dashboard. Keep money as display strings; exports and paste-backs show a link's text without the URL.
The tool returns the finished HTML. In Claude Code, write it to a .html file and give the owner the path; on Claude Desktop, present it as an HTML artifact. On a contract error nothing renders and the exact problems are listed so you can fix and re-call.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | The report contract object (see the description for its shape). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive; the description adds substantial behavioral detail: output is self-contained/offline, it returns the finished HTML, contract errors are listed and nothing renders, and links are restricted to http/https with specific rendering behavior. This greatly exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence is necessary given the complex contract. It is front-loaded with the core purpose, followed by structured contract details, formatting rules, and output behavior. No redundant or filler sentences are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested object, sparse schema, and no output schema, the description is exceptionally complete. It covers the full input contract, return value, error behavior, platform-specific handling, security constraints, and rendering nuances, leaving no significant gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema only describes a generic 'report' object, the description fully specifies the contract: required keys (skill, title, sections), section structure (title, severity, blocks), block types (table, prose/lead, list, subhead), optional top-level keys, and markdown formatting rules. This is a comprehensive compensation for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Render a findings report into one self-contained, offline, interactive HTML file.' It also explicitly differentiates from siblings by stating it is a presentation tool that makes no Housecall Pro call and operates on existing findings, making its role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use the tool: when you already have findings and need an interactive HTML report. It also gives platform-specific guidance (write to .html in Claude Code, present as artifact on Claude Desktop). It does not explicitly name alternatives or exclusions, but the context is strong enough to guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hcp_set_business_profileAIdempotent
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.
| Name | Required | Description | Default |
|---|---|---|---|
| shop | No | Who the shop is: trade(s), region, team size, and any peer group they benchmark against. Pass null to clear the section. | |
| comms | No | How 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. | |
| payroll | No | Payroll rules: when the pay week starts and the commission rules by role. Pass null to clear the section. | |
| pricing | No | Pricing rules: the margin floor, per-category overrides, and how prices are rounded. Pass null to clear the section. | |
| vendors | No | Who 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the destructiveHint annotation. It states 'null clears one' section, which is a destructive operation, while annotations declare destructiveHint=false. This is a direct contradiction, and per the rules, transparency is scored 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences pack significant information: purpose, replacement/clearing behavior, storage location, and privacy/security constraints. Every clause earns its place, though it could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's behavior: what it stores, how sections are replaced/cleared, where the profile lives, and what it never contains. For a setter with no output schema, this is comprehensive and equips an agent for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all five parameters (100% coverage). The description adds crucial semantics beyond the schema: null clears a section, and vendor's account_hint rejects full account numbers. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Store one or more business-profile sections for this installation' and names all five sections. It distinguishes itself from the sibling hcp_get_business_profile by focusing on writing/updating, not reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a critical usage guideline: 'save a section only after reading the whole section back to the user for a yes.' It does not explicitly name alternatives, but the contrast with hcp_get_business_profile is implicit. The privacy statement also informs when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
v1.15.1- First observed
hcp_api_notes - First observed
hcp_get_business_profile - First observed
hcp_render_report - First observed
hcp_set_business_profile
TDQS
Each tool targets a distinct function: rendering reports, reading/writing the business profile, and looking up API notes. The get/set pair is symmetric and unambiguous, with no overlapping purposes.
Three tools follow a clear verb_noun pattern (render_report, get_business_profile, set_business_profile). One tool (hcp_api_notes) uses a noun phrase instead of a verb, a minor deviation that does not cause confusion.
Four tools is a well-scoped set for this server's purpose: one presentation tool, two profile management tools, and one reference tool. Each earns its place with no redundancy.
The business profile has full get/set/clear lifecycle, report rendering is a single-purpose tool, and API notes provides lookup. There are no obvious gaps given the server's defined scope of not making direct Housecall Pro calls.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
- ZapierOAuthcom.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server for Housecall Pro, providing 5 tools for AI agents to register customers, schedule jobs, create estimates, log leads, and generate invoices (env-gated).5MIT
- AlicenseBqualityFmaintenanceMCP server for Invoice Ninja v5 API. Enables AI assistants to manage clients, invoices, quotes, payments, and time tracking through natural language.32222MIT
- AlicenseBqualityDmaintenanceA Model Context Protocol (MCP) server that provides tools for managing GoHighLevel (GHL) conversations, tasks, and calendar appointments through AI assistants like Claude.2137MIT
- FlicenseNot gradedqualityDmaintenanceMCP server for GoHighLevel sub-accounts, enabling management of CRM contacts, pipelines, calendars, invoices, and more via natural language.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hcpapi/housecall-pro-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server