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., "@Deputy Workforce Operations MCP Show timesheet exceptions above a 15-minute tolerance."
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.
A read-only Model Context Protocol server that turns Deputy workforce records into five grounded, operational workflows for AI assistants.
“Where are the coverage gaps from 20 to 26 July, using a minimum of two people?”
“Which combined completed and rostered workloads cross our 40-hour planning threshold?”
“Show timesheet exceptions above a 15-minute tolerance.”
“Which rosters overlap recorded unavailability or approved leave?”
“Summarise staffing by location and day for this week.”
The tools answer those questions directly instead of exposing Deputy's endpoint catalogue.
Related MCP server: Slack MCP Server
The examples below use fictional records and compact the structured response to the fields a manager can act on.
{
"period": { "start": "2026-07-20", "end": "2026-07-26", "timezone": "Europe/London" },
"findings": [{ "kind": "coverage_gap", "sources": [{ "resource": "Roster", "id": 1001 }], "rule": "active roster has fewer than 2 people" }],
"limits": []
}{ "period": { "start": "2026-07-20", "end": "2026-07-26", "timezone": "Europe/London" }, "findings": [{ "worker_id": 7, "planned_hours": 43.5, "threshold_hours": 40, "sources": [{ "resource": "Timesheet", "id": 2007 }, { "resource": "Roster", "id": 1007 }], "rule": "completed plus remaining rostered hours exceeds threshold" }], "limits": [] }{ "period": { "start": "2026-07-20", "end": "2026-07-26", "timezone": "Europe/London" }, "findings": [{ "kind": "start_time_variance", "roster_id": 1002, "minutes": 22, "tolerance_minutes": 15, "sources": [{ "resource": "Roster", "id": 1002 }, { "resource": "Timesheet", "id": 2002 }], "rule": "timesheet start differs from roster beyond tolerance" }], "limits": [] }{ "period": { "start": "2026-07-20", "end": "2026-07-26", "timezone": "Europe/London" }, "findings": [{ "kind": "recorded_unavailability_conflict", "sources": [{ "resource": "Roster", "id": 1002 }, { "resource": "EmployeeAvailability", "id": 4001 }], "rule": "roster interval overlaps recorded unavailability" }], "limits": [] }{ "period": { "start": "2026-07-20", "end": "2026-07-26", "timezone": "Europe/London" }, "findings": [{ "location": "North", "day": "2026-07-21", "rostered_hours": 16, "completed_hours": 12, "assigned": 3, "unassigned": 1, "sources": [{ "resource": "Roster", "id": 1008 }, { "resource": "Timesheet", "id": 2008 }], "rule": "group roster and timesheet hours by location and local day" }], "limits": [] }Every finding names its period, source record identifiers, and the rule or threshold that produced it. Empty data gives a confidence limit rather than a false all-clear.
Every tool is read-only, idempotent, and non-destructive.
The server never creates or changes shifts, timesheets, leave, payroll, or employee data.
Workload thresholds are operational planning signals, not payroll, employment, or legal advice.
Telemetry excludes tool arguments, employee and location IDs, dates, result content, and tokens.
Standard MCP analytics are disabled unless the deployment owner provides a PostHog project token; the privacy allowlist is documented in PRIVACY.md.
V1 is single-tenant by deployment: one Deputy installation and one MCP bearer token per instance.
Authentication, bounded HTTP transport, rate limiting, structured results, and stdio lifecycle
use MCP Maker's shared @hyperdrift-io/mcp-service-kit; Deputy keeps its provider and workflow logic.
See SECURITY.md and PRIVACY.md for the complete contracts.
Node.js 22 and pnpm are required. The quickest safe inspection uses the public package and fictional fixture data:
DEPUTY_MODE=fixture pnpm dlx @hyperdrift-io/deputy-workforce-mcp@latestFor a visible tool-list and tool-call proof, see the fixture demonstration. The package is also distributed through the official MCP Registry and as a one-file MCP Bundle on Smithery. Maintainers can reproduce the local bundle with:
pnpm mcpb:packTo work from source:
git clone https://github.com/hyperdrift-io/deputy-workforce-mcp.git
cd deputy-workforce-mcp
pnpm install
pnpm build
DEPUTY_MODE=fixture node dist/stdio.jsFixture mode contains fictional Worker 01-style records and is safe for evaluation. To connect a
Deputy installation, copy .env.example to .env.local, choose DEPUTY_MODE=live, and provide a
customer-owned base URL and OAuth access token. Live resource shapes still require the first
sandbox verification recorded in docs/DEPUTY_API.md.
Example client configuration:
{
"mcpServers": {
"deputy-workforce": {
"command": "node",
"args": ["/absolute/path/to/deputy-workforce-mcp/dist/stdio.js"],
"env": { "DEPUTY_MODE": "fixture" }
}
}
}The same five tools can run over authenticated streamable HTTP. Remote mode requires an MCP bearer token of at least 32 bytes, authenticates before parsing requests, limits bodies to 1 MiB, and uses bounded in-memory rate protection.
DEPUTY_MODE=fixture \
MCP_BEARER_TOKEN="replace-with-at-least-32-random-bytes" \
PORT=3013 \
pnpm startHealth: GET /health
MCP: authenticated POST /mcp
See docs/DEPLOYMENT.md before operating a remote instance.
The server registers exactly five tools:
find_coverage_gaps
flag_overtime_risk
list_timesheet_exceptions
find_availability_conflicts
summarise_staffing
Inputs, rules, and output limits are documented in docs/TOOLS.md.
Fixture mode, stdio, and authenticated streamable HTTP are operational. Live Deputy mode remains explicitly pending a customer-owned sandbox token and field-shape verification. The public API is still in prototype discovery and may evolve from real workflow feedback.
Deputy Workforce Operations MCP is the flagship public implementation from MCP Maker: Hyperdrift turns established SaaS APIs into secure, production-ready AI integrations.
The open-source core remains useful on its own. MCP Maker offers managed deployment, security hardening, custom workflows, and operational support for organisations that want a production integration tailored to their environment.
Find rosters overlapping recorded unavailability or approved leave.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | Last local calendar date, YYYY-MM-DD, inclusive. | |
| timezone | Yes | IANA timezone used to group operational days. | |
| start_date | Yes | First local calendar date, YYYY-MM-DD. | |
| location_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds only that the tool finds overlapping rosters, which is already clear from the name. No additional behavioral traits like return format or performance implications are disclosed.
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?
A single, concise sentence that is front-loaded with the core purpose. No extraneous information.
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 does not explain the return value or output format. Given no output schema, this is a significant gap. The tool has 4 parameters and no output schema, so the description should clarify what the result looks like.
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?
Schema coverage is 75% (three of four parameters have schema descriptions). The tool description does not add meaning for parameters beyond the schema. Baseline of 3 is appropriate as schema does most of the work, but location_ids lacks schema description and tool description does not compensate.
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?
Description clearly states the tool finds rosters overlapping recorded unavailability or approved leave. The verb 'Find' and resources are specific. It distinguishes from siblings like find_coverage_gaps (coverage gaps) and flag_overtime_risk (overtime risks).
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 implies usage for detecting conflicts between rosters and unavailability/leave, but does not explicitly state when to use this tool versus alternatives. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find open shifts and optional minimum-staffing shortfalls without changing Deputy data.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | Last local calendar date, YYYY-MM-DD, inclusive. | |
| timezone | Yes | IANA timezone used to group operational days. | |
| start_date | Yes | First local calendar date, YYYY-MM-DD. | |
| location_ids | No | ||
| minimum_people | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description restates 'without changing Deputy data' but adds no new behavioral traits. With annotations present, this is adequate but not enriched.
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 a single clear sentence with no redundant words. It is front-loaded with the core action and resources, making it efficient for an agent to parse.
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?
Despite having no output schema and 5 parameters, the description provides no details on return format, examples, or interpretation of 'shortfalls'. It relies entirely on the schema and annotations, leaving gaps for an agent to guess.
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?
Schema description coverage is 60% (3 of 5 parameters have descriptions). The tool description adds no parameter-specific information, leaving location_ids and minimum_people unexplained. It does not compensate for the missing schema descriptions.
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 it finds open shifts and minimum-staffing shortfalls, specifying the verb 'find' and the resources. It does not explicitly differentiate from sibling tools, but the purpose is distinct enough to avoid confusion.
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?
No guidance is provided on when to use this tool versus alternatives like flag_overtime_risk or list_timesheet_exceptions. The only context is that it does not change data, which is already covered by annotations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare completed and remaining rostered hours with a configured operational threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | Last local calendar date, YYYY-MM-DD, inclusive. | |
| timezone | Yes | IANA timezone used to group operational days. | |
| start_date | Yes | First local calendar date, YYYY-MM-DD. | |
| location_ids | No | ||
| threshold_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is consistent. It adds minimal behavioral context beyond the threshold concept, which is already hinted by the name. No contradictions.
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 a single sentence that is front-loaded and free of unnecessary words. Every word earns its place, achieving maximum conciseness.
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?
With no output schema and a moderately complex task (5 parameters), the description omits what the output looks like (e.g., a boolean flag, a list of flagged items). It also fails to clarify the 'compare' operation details, leaving room for ambiguity.
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?
Despite 60% schema coverage, the description does not elaborate on parameter meanings beyond the schema. For example, 'location_ids' lacks a schema description and the tool description does not compensate. The only parameter indirectly explained is 'threshold_hours' via 'configured operational threshold.'
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 'compare' and a clear resource ('completed and remaining rostered hours with a configured operational threshold'). It distinguishes the tool from siblings like 'find_coverage_gaps' or 'list_timesheet_exceptions' by focusing on threshold-based risk flagging.
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 implies usage for flagging overtime risk but does not provide explicit guidance on when to use or avoid this tool, nor does it mention alternatives among siblings. The context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find missing or materially different timesheets using an explicit tolerance.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | Last local calendar date, YYYY-MM-DD, inclusive. | |
| timezone | Yes | IANA timezone used to group operational days. | |
| start_date | Yes | First local calendar date, YYYY-MM-DD. | |
| location_ids | No | ||
| tolerance_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat safety info. However, it adds no extra behavioral context such as pagination, number of results, or side effects beyond what annotations imply.
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?
A single sentence that is front-loaded and contains no filler. Every word earns its place, achieving maximum conciseness.
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 that there is no output schema and parameters are partially described, the description should cover return value shape or behavior. It does not mention what the output looks like, pagination, or error conditions, leaving gaps for an 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?
Schema coverage is 60% (3 of 5 parameters have descriptions). The description mentions 'using an explicit tolerance' which hints at tolerance_minutes but doesn't explain it or other parameters like location_ids. It adds minimal clarification beyond the 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 'Find' and resource 'missing or materially different timesheets', clearly distinguishing from sibling tools like find_coverage_gaps or flag_overtime_risk. It succinctly captures the tool's core purpose.
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?
No guidance on when to use this tool versus alternatives, no prerequisites, and no context like expected use cases or limitations. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise rostered and completed staffing by location and local day.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | Last local calendar date, YYYY-MM-DD, inclusive. | |
| timezone | Yes | IANA timezone used to group operational days. | |
| start_date | Yes | First local calendar date, YYYY-MM-DD. | |
| location_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows the tool is safe and non-destructive. The description adds specific behavioral context by stating that it summarises rostered vs completed staffing, which is beyond what annotations provide. There is no contradiction.
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 a single concise sentence (9 words) that effectively communicates the tool's purpose without any wasted words or redundancy.
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 tool's simplicity, no output schema, and clear annotations, the description sufficiently conveys the core functionality. It is complete enough for an AI agent to understand what the tool does, though it does not elaborate on the return format or precise meaning of 'rostered and completed'.
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 description adds the context of grouping by 'location and local day', which corresponds to location_ids and the date parameters, but does not detail each parameter. Since schema description coverage is 75% and the schema descriptions for required parameters are already informative, the description provides moderate additional semantic value.
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 verb 'summarise' and the resource 'rostered and completed staffing' with dimensions 'by location and local day'. However, it does not explicitly differentiate from sibling tools, though the siblings have distinct purposes such as 'find_coverage_gaps' or 'flag_overtime_risk', making the purpose distinct.
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 provides no guidance on when to use this tool versus alternatives or any prerequisites. The sibling tools are listed in context but the description itself does not mention them or any conditions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0find_availability_conflictsfind_coverage_gapsflag_overtime_risklist_timesheet_exceptionssummarise_staffingEach tool targets a distinct operational concern: coverage gaps, overtime risk, timesheet exceptions, staffing summary, and availability conflicts. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (find_, flag_, list_, summarise_, find_), making them predictable and clear.
5 tools is well-scoped for a read-only workforce analysis server, covering key monitoring areas without bloat or deficiency.
The set covers main operational needs (gaps, overtime, exceptions, summary, conflicts). A minor gap is the absence of a tool to list all shifts or employees directly, but the summary and gap tools partially address this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hyperdrift-io/deputy-workforce-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
