Deputy already has an integration path for asking Claude questions against your rostering data, but a business building its own MCP server on top of Deputy's API is after something different: custom actions and reporting tailored to exactly how they run rosters, not the general-purpose question-answering the standard integration covers.
Why build your own rather than use the existing integration
The general integration is good for natural-language questions against existing data: who's on shift Thursday, how many hours did casual staff work this fortnight. A custom MCP server earns its cost when a business needs specific, repeated actions the general integration doesn't offer: auto-flagging shifts approaching overtime thresholds, cross-referencing rostered hours against a separate compliance calendar, or generating a weekly exception report formatted exactly the way a specific manager wants it, not a generic summary.
Resources: current roster, historical shift data, leave balances
Tools: approving swap requests, flagging overtime risk, generating custom reports
Rate limits: Deputy's API has its own limits worth checking before designing call frequency
Data sensitivity: rostering data includes personal information covered by the Privacy Act
A worked scope for a hospitality business
A Melbourne hospitality group with 40 casual staff across three venues built a server exposing shift data as resources and two specific tools: an overtime-risk flag that checks against Fair Work thresholds automatically each morning, and a weekly variance report comparing rostered versus actual hours worked. The build ran around $3,800, and the overtime-flag tool alone caught two near-miss overtime situations in its first month that had previously been caught manually, inconsistently, by whichever manager happened to notice.
Handling the compliance angle properly
Rostering data is personal information under the Privacy Act, and a server exposing it, even internally, needs the same access-control discipline as any other system touching staff records: scoped access per role, no broader visibility than a manager actually needs for their own venue or team, and a clear record of who can query what. This isn't a reason to avoid building the tool, but it is a reason to involve whoever owns HR or compliance policy in the access design before the server goes live, not after.
Keeping it maintainable
Deputy's own API evolves, and a custom server built against it needs an owner who checks for breaking changes periodically rather than discovering a silent failure when a report stops generating correctly. Budget a modest ongoing maintenance allowance, even a few hours a quarter, rather than treating the build as a one-off project with no future attention needed.
Testing before it touches live rosters
Run the server against a test Deputy account or a sandboxed subset of real data before connecting it to the venues actually rostering staff week to week. Overtime flags and variance reports both depend on getting the underlying calculation logic exactly right, and a subtle error in how hours are summed across split shifts is the kind of bug that's easy to miss in a quick manual check but expensive to leave live for a month.
Once live, spot-check the automated reports against a manual calculation periodically, at least monthly in the first quarter, until enough confidence has built up that the checks can space out further. This mirrors the same discipline any business should apply to a new payroll-adjacent tool, regardless of how it was built.
For a multi-venue operator, the reporting consistency alone, every venue's manager seeing the same format, calculated the same way, is often worth as much as the time saved generating it.
Worth deciding upfront who owns approving swap requests through the tool versus who's just reading reports, since giving broad write access to everyone who only needs read access is a common early mistake that's easy to avoid with a short access-planning conversation before launch.
A short pilot period, running the new server alongside the existing manual process for two or three weeks before fully switching over, catches most remaining issues cheaply, and it gives managers time to build trust in the automated flags before relying on them exclusively.
When the general integration is actually enough
Not every business needs the custom build. If the questions being asked of Deputy data are genuinely general, straightforward lookups without a recurring specific action behind them, the existing integration likely covers it without the added cost and ongoing maintenance of a custom server. Reserve the custom build for the specific, repeated actions that justify the investment.
That distinction, general lookup versus specific recurring action, is the same test worth applying before any custom MCP build against any connected system.
Get that distinction right before writing a line of code, not after the build is already underway.
