ServiceM8 is common enough across Australian trade businesses, plumbers, electricians, HVAC technicians, that a purpose-built MCP server against its API is worth the build once a business is running more than the occasional Claude query against job data. This is the developer-facing build guide: the specific tools worth exposing, and the parts of ServiceM8's data model that take real care to get right.
The tools worth building first
A trade business asking Claude about job data almost never wants the raw API response; they want the plain-English answer a good office admin would give if you asked them the same question over the phone. That gap between what the API returns and what a business owner actually wants to hear is exactly what the MCP server's tool layer needs to close, formatting and filtering the raw job records into something genuinely useful before Claude ever sees them.
ServiceM8's API centres on jobs, clients, and staff, with job status, scheduling, and materials tracked as related objects rather than flat fields, which means a naive MCP server exposing raw API pass-through gives Claude a confusing, deeply nested structure to reason about instead of the plain-English answer a business owner actually wants.
get_job_status(job_number): current status plus the last three activity log entries, not just a status code
search_jobs_by_client(client_name): fuzzy client match returning open and recently closed jobs
get_technician_schedule(staff_id, date_range): a technician's booked jobs for a given window
get_unbilled_jobs(): completed jobs with no invoice yet raised, the single highest-value tool in practice
Where the real build effort goes
ServiceM8's job status field doesn't map cleanly to a simple open-or-closed state; a job can be Quote, Work Order, Completed, or Unsuccessful, and each has its own implications for what a business owner actually wants to know when they ask Claude "what's outstanding." Getting that status mapping right, and deciding which statuses count as genuinely "outstanding" for the get_unbilled_jobs tool specifically, is the bulk of the real design work, more than the API authentication itself.
A Perth electrical contracting business running eleven technicians had a standing Friday-afternoon habit of one office admin manually cross-checking ServiceM8 for completed-but-unbilled jobs before the weekend, a task that took close to an hour and occasionally missed a job that had been completed but not correctly marked. Building the MCP server with the unbilled-jobs logic correctly scoped turned that hour into a two-minute Claude Cowork check, and the owner estimated it recovered around $6,800 a year in admin time, plus caught two jobs in the first month that the manual process had been missing.
Testing against a real account before going live
ServiceM8 offers a sandbox account for development, but a handful of the trickier status and scheduling edge cases only really show up against a genuinely messy real production account, one with cancelled jobs, rescheduled jobs, and jobs reassigned mid-way between technicians. Running the finished server against a read-only copy of the real account's data for a week before switching any write operations live catches these edge cases while the cost of getting one wrong is still zero.
Handling multi-technician jobs correctly
ServiceM8 allows multiple staff assigned to one job, and a server that assumes a single technician per job will silently misreport scheduling conflicts or workload for any business running crews rather than solo technicians. Testing the schedule tool specifically against a multi-technician job before trusting it catches this gap early, since it's the kind of silent wrong answer that's easy to miss until a technician turns up double-booked.
Webhooks versus polling for job status changes
ServiceM8 supports webhooks for job status changes, and a server that polls the API on a fixed interval instead will always lag slightly behind what actually happened, which matters if a business wants Claude to flag a job the moment it's marked complete rather than up to several minutes later. Building the webhook receiver takes more upfront effort than simple polling, but for any business using the unbilled-jobs tool as a same-day trigger for invoicing, the lag genuinely matters and the webhook approach is worth the extra build time.
What this isn't
This is a technical build guide for the MCP server itself, distinct from a broader piece on Claude and ServiceM8 for general trade job admin; this is specifically for the developer building the integration, and the data-model decisions that determine whether the resulting tools actually give correct answers.
Automata AI builds ServiceM8 MCP servers for Australian trade businesses running past what manual job-status checks can keep up with. Get in touch via /contact with your technician count and roughly how many jobs run through the business each week, and we'll scope the build against your actual job mix, including whether webhooks are worth the extra setup time for your specific invoicing cadence.
