Which Housecall Pro MCP actually works?
Several open-source Housecall Pro (HCP) MCP servers exist. The tool count on a README does not separate them. What does is how many of the routes each one calls actually exist, measured against a live account.
| Server | Routes it calls | Dead | Dead rate |
|---|---|---|---|
| hcpapi this project | 71 | 0 | 0% |
| toducthanh toducthanh/housecallpro-mcp | 79 | 10 | 13% |
| buildwithbeacon buildwithbeacon/housecallpro-mcp | 46 | 17 | 37% |
| busybee3333 busybee3333/housecall-pro-mcp-2026-complete | 71 | 54 | 76% |
Tested 7 August 2026, against each repository's then-current code. Repos change; a repo that has cleaned up since can be re-tested.
Why a dead route is worse than a missing feature
A route that does not exist does not fail in a way you notice. The call comes back a 404, the tool reports it could not do the thing, and to the person who asked it looks like the feature is missing or the account is empty, not like the tool is pointed at a route that was never there. You find that out in front of a customer, not in a test.
This is the specific failure of building an integration from documentation alone. Housecall Pro's published API describes routes that return a 404 when you call them, and omits routes that work. A server assembled from the docs ships a broken path for each one, and every one of them fails only in production.
Measured, not claimed
Every route each server calls was tested against a live Housecall Pro account. The count is routes, not tools: one dead route can sit behind several tools, so a server can advertise a long tool list while a third of it reaches nothing. The numbers are checkable: the free MCP is open source, and the endpoint reference lists every route with its verdict.
The others, fairly
These are real efforts by people solving their own problem in the open, and none of this is an argument that they were built carelessly. Most of the dead routes come straight from trusting Housecall Pro's own documentation, which is the honest mistake to make.
toducthanh
The best-engineered of the others: retry with backoff, typed against the vendored spec. Then it diverges from that spec. A run of its material and service routes call paths that return a 404, and it passes raw cents straight through, so money arrives off by a factor of a hundred.
buildwithbeacon
Twenty servers stitched together in one pass and not touched since. A whole appointments module targets a top-level collection that does not exist, and an invoice module builds on a detail route that is not there either.
busybee3333
Reads as auto-generated. Most of its routes match no Housecall Pro API in any form: a payments API, a dispatch board, a reviews endpoint. Impressive on paper, and three quarters of it cannot run.
One more exists that is not in the table: jkeith10/HCP_Claude is a hosted web app rather than an MCP server you install, so it is a different kind of thing and not comparable route-for-route. Its small client calls a couple of routes that are not there either.
Why ours is zero
Not because we are cleverer. It is that we run a service company on Housecall Pro and tested every route against the account before shipping the tool that calls it. Where the documentation and the live API disagreed, we followed the API. The endpoint reference is the same knowledge written out: what reads, what writes, and the documented routes that are not there.
It is free, so you can check us
Our Housecall Pro MCP is free and open source, the source is on GitHub, and the endpoint reference above lists every route with its verdict. Do not take the table on faith. The whole point is that it is checkable.
Corrections, or a server that belongs in the table: hello@hcpapi.com.