ERP Data Connector (Home Service Pass)
Home Service Pass v2, Talking to Your Business Through an MCP Connector
A Benmore Technologies case study, in partnership with Home Service Pass.
Client: Brad Pierce & Eddie Juarez · FDE: Arkash Jain · Site: homeservicepass.com
1. Introduction
Overview
Home Service Pass (HSP) is a membership marketplace for in-person home services. Customers buy an annual pass, a vetted network of local providers fulfils it, and the HSP team runs the platform from a backoffice. Benmore built the platform in v1.
In v2, Benmore connected that platform to AI. HSP now has a custom MCP connector: admins, providers and customers open Claude or ChatGPT, sign in with their normal HSP account, and ask questions of the live system in plain English. "Which providers are falling behind this month?" "What am I owed?" "What's left on my pass?" The answer comes from production data, through the same rules the app already enforces.
Nothing was rebuilt. The connector sits on top of the existing codebase, reuses its permissions, and adds no new copy of customer data. It went from first commit to live in 18 days.
At a glance
| Live since | September 2026, on HSP's existing backend |
| Works with | Claude (web and desktop), ChatGPT, Claude Code, the Anthropic API |
| Capabilities | 52 signed-in tools (32 admin, 9 customer, 7 provider, 4 shared) plus 8 public tools |
| Safety | 39 read-only · 4 low-risk writes · 9 money actions held for human approval |
| Sign-in | HSP's own login, industry-standard OAuth, one-minute setup |
| Delivery | 18 days · 28 commits · 279 automated tests |
Challenge
- Give three very different users (owners, providers, customers) AI access to their own data, from one integration
- Let AI read and act, but never move money on its own
- Reuse every permission the platform already has instead of writing new ones
- Ship on the existing infrastructure, with no new servers and no new database
2. The Problem
Background
- HSP's most useful data (revenue, customer lifetime value, provider performance, redemptions, payouts) lived behind admin screens and CSV exports
- Every business question became a developer request or a spreadsheet afternoon
- Providers and customers had smaller versions of the same problem: checking a schedule or a pass balance meant opening the app and tapping through
Pain Points
- Analytics on request. Weekly numbers cost engineering time; ad-hoc questions cost more
- Support load. Providers asking about payouts and job history; customers asking what their pass covers
- Off-the-shelf AI tools are unsafe here. "Chat with your database" products want a database copy and a master key. That is a second, unmanaged store of customer data with no idea who is asking
- AI agents can act without asking. Some AI research modes run with approvals switched off. A connector that can refund a pass on the model's say-so is a liability
3. Our Solution
What MCP is, in one paragraph
The Model Context Protocol (MCP) is the open standard that lets an AI assistant plug into an outside system. A business publishes a set of tools (things the assistant can look up or do), the assistant discovers them, and the user's own login decides which ones they may use. Claude, ChatGPT and most modern AI clients speak it natively. Benmore built HSP a custom MCP server so the platform shows up in those clients as a connector, the same way Slack or Google Drive do.
Discovery Process
- HSP's backend already described every operation it supports, with a name, an input, an output and a permission rule. That description became the tool catalogue
- Rather than wire the AI to the database, every tool call is routed through the real application, so the same login checks, rate limits and business rules apply as if the user had tapped a button in the app
- The team set a hard ceiling on the number of tools, because an assistant chooses the right tool less reliably as the list grows
The rule that shaped everything: the connector declares what exists; it never decides anything itself. It calculates no prices, no commissions and no payouts. If a tool would ever allow more than the underlying feature allows, an automated test fails.
Core Value Proposition
One connector, three audiences, zero new data stores. Owners get answers in a sentence. Providers get their schedule and earnings in chat. Customers get their pass balance and can book from the answer. Every request is checked by the platform, logged, and, when money is involved, held for a person.
Proposed Solution
Where the capabilities go
| Audience | Tools | Safety class | Tools |
|---|---|---|---|
| Admins | 32 | Read-only | 39 |
| Customers | 9 | Money, staff approval required | 9 |
| Providers | 7 | Low-risk write | 4 |
| Shared by two roles | 4 | ||
| Public, no sign-in | 8 |
Of the 52 signed-in tools, 39 are read-only, 4 are low-risk writes, and 9 touch money.
- Admins ask for revenue and risk summaries, customer lifetime value and CAC, high-value and high-risk customers, provider performance, payouts and receivables, or a daily brief. Refunds and settlements go to the approval queue
- Providers ask for their job queue, customers, booking history and payouts, and can schedule a booking
- Customers ask what is on their pass, their credits, bookings and referral code, and can book a service
- Anyone can check coverage by zip code, browse the catalogue and pricing plans, and read testimonials, without signing in
How a request flows
- The user asks a question in Claude or ChatGPT
- The assistant picks the matching HSP tool
- HSP checks the user's login and role, exactly as the app would
- Read-only tools return the answer immediately; money tools go to an approval queue
- The call is logged: who, which tool, how long, how many rows. Never the data itself
Technology Stack
| Layer | Technology |
|---|---|
| Protocol | MCP (current 2026 revision, older client versions supported) over HTTPS, JSON only |
| Sign-in | OAuth 2.1 with PKCE · automatic client registration · scopes issued per role |
| Tool definitions | Generated from the platform's own API specification, never hand-written |
| Execution | Every call replayed through the real Django application and its permissions |
| Approvals | Money actions land in a queue in the HSP admin, approved by staff |
| Audit | Every call recorded with redacted inputs, status, row count and latency |
| Hosting | HSP's existing Heroku backend, with a kill switch that turns the connector fully off |
4. Implementation
Step 1. Connect
- In Claude, open Settings → Connectors → Add custom connector, give it a name and paste the HSP server address. That is the whole setup; there are no API keys to copy
- In ChatGPT the same connector is added under Settings → Connectors once developer mode is switched on
Step 2. Sign in
- Claude inspects the server and detects both Sign in now and Register automatically. The user never chooses a protocol; the client and HSP negotiate it
- Sign-in is HSP's own login page. Whatever role the account has in the app (admin, provider, customer) is the role it has in chat
- Every registered client appears in the HSP backoffice and can be revoked in one click
Who sees what after sign-in
| Signed in as | Tools visible | Can read | Can act |
|---|---|---|---|
| Admin | 36 | Revenue, LTV/CAC, risk, providers, payouts, receivables | Refunds and settlements, via the approval queue |
| Provider | 9 | Own queue, customers, bookings, payouts | Schedule a booking, update job notes |
| Customer | 11 | Own passes, credits, bookings, referral | Book a service |
| Not signed in | 8 | Coverage, catalogue, pricing, benefits, testimonials | Nothing |
Step 3. Ask
- "Which providers are completing their bookings?" returns a per-company table from production in one turn: bookings, completed jobs and completion rate
- "What was redeemed this week?" returns the count, the number of unique passes and users, and the top services
- Row counts and response times are logged for every call; the returned data is not stored, so the connector creates no second copy of customer information
What happens when a question touches money
| Request | What the AI gets back | What happens next |
|---|---|---|
| "Refund this customer's pass" | "Approval required", with a reference | A pending action appears in the HSP admin with the exact before-and-after; staff approve or reject |
| "Settle this receivable" | Same | Same |
| "Pay this provider" | Not available as a tool | Deliberately excluded until a payment-gap fix lands |
| "Show me this month's revenue" | The numbers | Logged; nothing changes |
- Nine tools touch money: refunds, receivable settlement, commission changes, influencer codes. None of them can execute from an AI client
- A test walks every money tool in the live registry and proves the rule holds
Why not just ask the model to confirm? Some AI modes run with confirmation disabled, so the "person" a confirmation prompt reaches would be the model. The approval therefore lives in a screen only staff can open.
Built for the infrastructure HSP already pays for
- The connector runs on the same Heroku backend as the app, with no new servers
- It uses a simple request-and-response transport rather than a streaming one, so idle AI sessions cannot tie up the web workers that serve customers
- A single setting turns the connector fully off, returning "not found" before any request is processed
5. Results
Product Outcomes
- Live in production for Claude, ChatGPT and Claude Code users
- Bookings up 20% since launch
- Business questions answered in 2 days instead of 9
- 52 signed-in capabilities and 8 public ones, from one integration
- No money moved by an AI: every money action goes through the approval queue
- 18 days from first commit to live
Technical Achievements
- Permissions inherited from the platform, verified by an automated test on every feature
- Tool definitions generated from the API specification, so they can never drift from the app
- 279 automated tests, including exhaustive checks over every registered tool
- Audit without a data copy: inputs redacted, outputs never stored
- A real off switch: one setting disables the connector before any processing
Measured impact
Reported by HSP after the first weeks of connector use.
| Area | Before | After |
|---|---|---|
| Bookings | Baseline | +20% |
| Response time to a business question | 9 days | 2 days |
| Engineering time on ad-hoc reporting | About 6 hours a week | Near zero |
| Provider completion follow-up | Monthly, by hand | Weekly, by question |
| Gross margin | Baseline | Up, from faster receivable follow-up and fewer unbilled jobs |
Business Impact
- Data for the people who need it. The founders ask questions in a sentence instead of filing a request; turnaround fell from 9 days to 2
- More bookings, better margins. Bookings rose 20%, and gross margin improved as receivables and unbilled jobs are followed up weekly
- Same rules everywhere. An admin in Claude can do exactly what an admin in the backoffice can do, and nothing more
- Safe by design. Approvals, permission checks and tool limits are enforced by tests, not by memory
- Grows with the product. A new feature in the app becomes a new tool with one line of configuration
Read client reviews on Trustpilot ↗
6. Conclusion
HSP v2 turned a production marketplace into something its owners, providers and customers can talk to. Nothing was rewritten and no data was copied. The connector is 60 capabilities over the existing platform, governed by the platform's own permissions, with money held for a human and every call logged.
Roadmap
- A 90-day review of bookings, margin and response-time figures
- Provider actions from chat (reschedule, complete a job) with a provider-side approval view
- Customer booking with payment handoff from the conversation
- A public catalogue for prospective members to explore before joining
- Re-admitting the payout settlement tool once the payment gap is closed
The architecture for all of it is already in place.