How do I use w2w-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@w2w-mcp what are the shifts for next week?" 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.

w2w-mcp

by TheRealAlexV

Overview Schema Related Servers Score Discussions

TypeScript

Remote

When2Work MCP Server

License: MIT TypeScript Node.js MCP

A Model Context Protocol (MCP) server that provides seamless integration with the When2Work scheduling API. This server exposes When2Work data as MCP tools, allowing AI assistants like Claude to query employee schedules, shifts, time off, and reports.

💚 Support Our Mission

This tool was built for Dumont Volunteer Ambulance Corps, a member-owned non-profit volunteer ambulance service. If you find this tool useful, please consider supporting our life-saving work:

Your donation helps us continue providing emergency medical services to those in need!

Related MCP server: MCP OpenClaw

✨ Features

Feature	Description
👥 Employee Management	List all employees with contact information
🎯 Position Management	List all positions/job roles
🏷️ Category Management	List all shift categories
📅 Shift Queries	Get assigned shifts with date range support and automatic pagination
🏖️ Time Off Tracking	Get approved time off requests
📊 Daily Reports	Get daily schedule totals and position breakdowns
🔄 Automatic Pagination	Handles When2Work's 31-day limit by chunking requests automatically
🔒 Type Safety	Full TypeScript support with proper type definitions

✅ Testing Status

All 7 tools have been tested and verified working:

Tool	Status	Description
`w2w_get_employees`	✅ Tested	Retrieve all employees with contact info
`w2w_get_positions`	✅ Tested	Retrieve all positions/job roles
`w2w_get_categories`	✅ Tested	Retrieve all shift categories
`w2w_get_shifts`	✅ Tested	Get assigned shifts with date range support
`w2w_get_timeoff`	✅ Tested	Get approved time off requests
`w2w_get_daily_totals`	✅ Tested	Get daily schedule totals
`w2w_get_daily_position_totals`	✅ Tested	Get daily totals by position

📋 Prerequisites

Node.js 18 or higher
When2Work Pro Plan with API access
When2Work API key

🚀 Installation

1. Clone or create the project

cd /home/dvac_workspace/DVAC/dvac-w2w-mcp

2. Install dependencies

npm install

3. Build the project

npm run build

4. Set up environment variables

export W2W_API_KEY=your_api_key_here

To make this permanent, add it to your shell profile (~/.bashrc, ~/.zshrc, etc.):

echo 'export W2W_API_KEY=your_api_key_here' >> ~/.bashrc
source ~/.bashrc

💻 Usage

▶️ Running the server

npm start

Or directly:

node dist/index.js

For development with auto-rebuild:

npm run dev

🤖 Using with Claude Desktop

Add this server to your Claude Desktop configuration:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "when2work": {
      "command": "node",
      "args": ["/home/dvac_workspace/DVAC/dvac-w2w-mcp/dist/index.js"],
      "env": {
        "W2W_API_KEY": "your_api_key_here"
      }
    }
  }
}

🛠️ Available Tools

`w2w_get_employees`

Get all employees from When2Work.

Parameters: None

Example:

{
  "name": "w2w_get_employees",
  "arguments": {}
}

`w2w_get_positions`

Get all positions from When2Work.

Parameters: None

Example:

{
  "name": "w2w_get_positions",
  "arguments": {}
}

`w2w_get_categories`

Get all shift categories from When2Work.

Parameters: None

Example:

{
  "name": "w2w_get_categories",
  "arguments": {}
}

`w2w_get_shifts`

Get assigned shifts for a date range. Automatically handles pagination for ranges over 31 days.

Parameters:

start_date (string, required): Start date in mm/dd/yyyy format (e.g., "01/15/2024")
end_date (string, required): End date in mm/dd/yyyy format (e.g., "01/31/2024")
position_id (string, optional): Filter by position ID

Example:

{
  "name": "w2w_get_shifts",
  "arguments": {
    "start_date": "01/01/2024",
    "end_date": "01/31/2024",
    "position_id": "12345"
  }
}

`w2w_get_timeoff`

Get approved time off for a date range. Automatically handles pagination for ranges over 31 days.

Parameters:

start_date (string, required): Start date in mm/dd/yyyy format
end_date (string, required): End date in mm/dd/yyyy format

Example:

{
  "name": "w2w_get_timeoff",
  "arguments": {
    "start_date": "01/01/2024",
    "end_date": "01/31/2024"
  }
}

`w2w_get_daily_totals`

Get daily schedule totals (shifts and hours) for a date range. Automatically handles pagination for ranges over 31 days.

Parameters:

start_date (string, required): Start date in mm/dd/yyyy format
end_date (string, required): End date in mm/dd/yyyy format

Example:

{
  "name": "w2w_get_daily_totals",
  "arguments": {
    "start_date": "01/01/2024",
    "end_date": "01/31/2024"
  }
}

`w2w_get_daily_position_totals`

Get daily schedule totals broken down by position for a date range. Automatically handles pagination for ranges over 31 days.

Parameters:

start_date (string, required): Start date in mm/dd/yyyy format
end_date (string, required): End date in mm/dd/yyyy format

Example:

{
  "name": "w2w_get_daily_position_totals",
  "arguments": {
    "start_date": "01/01/2024",
    "end_date": "01/31/2024"
  }
}

🔌 API Details

When2Work API Endpoint

Base URL: https://www8.whentowork.com/cgi-bin/w2wJ.dll

Note: This is the correct production endpoint for the When2Work API, not https://api.when2work.com.

Authentication

The When2Work API uses query parameter authentication:

API key is passed as a key query parameter
No Authorization header is used

Example request URL:

https://www8.whentowork.com/cgi-bin/w2wJ.dll/api/employees?key=YOUR_API_KEY&detail=Y

When2Work API Constraints

Date Format: All dates must be in mm/dd/yyyy format (not ISO 8601)
Date Range Limit: Maximum 31 days per query (this server handles pagination automatically)
Plan Requirement: Pro Plan required for API access

Response Format

The When2Work API returns data in specific keys depending on the endpoint:

Endpoint	Response Key
Employees	`EmployeeList`
Positions	`PositionList`
Categories	`CategoryList`
Shifts	`AssignedShiftList`
Time Off	`ApprovedTimeOff`
Daily Totals	`DailyTotals`
Daily Position Totals	`DailyPositionTotals`

The MCP server normalizes these responses into consistent arrays for easier consumption.

Automatic Pagination

The server automatically handles When2Work's 31-day limit by:

Splitting date ranges > 31 days into chunks
Making multiple API requests in parallel
Merging results into a single response

This allows you to query any date range without worrying about the limit.

👨‍💻 Development

Project Structure

dvac-w2w-mcp/
├── package.json
├── tsconfig.json
├── README.md
├── src/
│   ├── index.ts              # MCP server entry point
│   ├── w2w-client.ts         # When2Work API client
│   ├── tools/                # MCP tool implementations
│   │   ├── employees.ts
│   │   ├── positions.ts
│   │   ├── categories.ts
│   │   ├── shifts.ts
│   │   ├── timeoff.ts
│   │   └── reports.ts
│   └── types/
│       └── w2w.ts            # TypeScript interfaces

Adding New Tools

Create a new file in src/tools/
Define the tool schema and handler function
Export both from the file
Import and register in src/index.ts

Type Checking

npm run typecheck

Linting

npm run lint

🐛 Troubleshooting

Error: "W2W_API_KEY environment variable is required"

Make sure you've set the W2W_API_KEY environment variable:

export W2W_API_KEY=your_api_key_here

Error: "When2Work API error (401)"

Your API key may be invalid or expired. Verify your API key in your When2Work account settings:

Log in to your When2Work account
Go to Settings > Company Settings > Integrations
Check or regenerate your API key

Error: "Invalid date format"

Make sure dates are in mm/dd/yyyy format (e.g., "01/15/2024"), not ISO 8601 format.

Error: "When2Work API error (429)"

You're being rate limited. The server automatically handles most rate limiting through pagination, but very large queries may still hit limits. Try reducing your date range.

Empty Results

If tools return empty arrays, check:

The date range contains data in your When2Work account
Your API key has access to the requested data
The position/category filters (if used) match existing records

Connection Issues

If you see connection errors:

Verify your internet connection
Check that https://www8.whentowork.com is accessible
Ensure no firewall is blocking the connection

🧪 Testing

To verify the server is working correctly:

Start the server:
```
npm start
```
Test with Claude Desktop or any MCP client:
- Try w2w_get_employees first (no parameters needed)
- Then test date-based tools with a small date range
- Verify pagination by querying a 60+ day range

All tools have been verified to work with real When2Work API calls.

📄 License

This project is licensed under the MIT License - see below for details:

MIT License

Copyright (c) 2024 Dumont Volunteer Ambulance Corps

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

🆘 Support

For issues related to this MCP server, please check:

✅ Your When2Work Pro Plan subscription status
✅ Your API key validity
✅ The date format (must be mm/dd/yyyy)
✅ The API endpoint URL is correct: https://www8.whentowork.com/cgi-bin/w2wJ.dll
Finally, if you're still having an issue please submit an issue here on github.

🔑 Getting Your API Key

Log in to your When2Work account as a Tech Administrator
Navigate to Pro > API Config
Copy your API key (or generate a new one if needed)

📚 When2Work Resources

When2Work Help Center
API Documentation (requires Pro Plan)

🙏 Acknowledgments

Built with ❤️ by Dumont Volunteer Ambulance Corps

If this tool has been helpful to your organization, please consider making a donation to support our volunteer emergency services.

Available Tools

7 tools

w2w_get_categoriesA

Get all shift categories from When2Work

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the transparency burden. It discloses the scope ("all shift categories") and read-only nature, but doesn't discuss return format, auth requirements, or pagination behavior. Adequate for a simple parameterless list tool but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence that immediately conveys the action and resource. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature (no parameters, no output schema), the description provides the essential purpose. It could mention what a "shift category" includes or the response format, but it's sufficient for basic selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema is already at 100% coverage (an empty object). The description doesn't need to explain parameters, so the baseline score of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ("Get") and resource ("shift categories") and names the source system ("When2Work"). It clearly distinguishes from sibling tools like w2w_get_employees by naming a distinct entity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use or alternatives is provided. The purpose is specific enough to imply its use case, but it doesn't mention exclusions or how it differs from sibling getters beyond the resource name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

w2w_get_daily_position_totalsA

Get daily schedule totals by position from When2Work for a date range. Shows assigned shifts and hours per day, broken down by position. Supports automatic pagination for ranges over 31 days.

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	Yes	End date in mm/dd/yyyy format (e.g., 01/31/2024)
`start_date`	Yes	Start date in mm/dd/yyyy format (e.g., 01/15/2024)

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool shows assigned shifts and hours per day, broken down by position, and supports automatic pagination for ranges over 31 days. These are meaningful behavioral traits beyond a simple 'gets data' statement. However, it does not explicitly state read-only nature, error handling, or rate limits, which would be additional context but are not critical for this simple read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise, consisting of two sentences that each serve a clear purpose. The first sentence states the core function, and the second elaborates on the output content and pagination behavior. There is no redundancy or filler, making it efficient for an agent to parse and act upon.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is quite complete. It conveys the purpose, what is returned, and a key behavioral aspect (pagination). While a more explicit description of the return structure could be beneficial in the absence of an output schema, the provided details are sufficient for an agent to select and invoke the tool effectively. The lack of mention of alternative tools slightly reduces completeness in a broader context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents both parameters with descriptions and example format. The description adds value by noting that ranges over 31 days trigger automatic pagination, which explains the combined effect of start_date and end_date beyond what the schema specifies. This enhances understanding of how the parameters interact, meriting a score above the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets daily schedule totals by position for a date range from When2Work. It identifies the action (get), resource (daily schedule totals by position), and scope (date range). However, it does not explicitly distinguish itself from the sibling tool w2w_get_daily_totals, which likely provides similar totals without the position breakdown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: when you need daily schedule totals broken down by position. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. Given the existence of the sibling tool w2w_get_daily_totals, the lack of guidance on selecting between them is a notable gap. The guidance is present but 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.

w2w_get_daily_totalsA

Get daily schedule totals from When2Work for a date range. Shows assigned shifts and hours per day. Supports automatic pagination for ranges over 31 days.

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	Yes	End date in mm/dd/yyyy format (e.g., 01/31/2024)
`start_date`	Yes	Start date in mm/dd/yyyy format (e.g., 01/15/2024)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses useful behavioral traits such as showing assigned shifts/hours and supporting automatic pagination. Yet it does not mention any side effects, authentication requirements, or what exactly constitutes 'totals', which would add more context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is composed of three short, purposeful sentences. It front-loads the main action and adds only informative details (return content and pagination). No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters, no output schema, and no annotations, the description adequately covers purpose, return summary, and pagination behavior. It could be more precise about the structure of the daily totals, but it is sufficient for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage for the two parameters, including format and examples. The description only refers to 'a date range' without adding any extra meaning to the start_date and end_date parameters, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get'), the resource ('daily schedule totals from When2Work'), and the scope ('for a date range'). It also mentions what is shown (assigned shifts and hours), but it does not explicitly differentiate from the sibling w2w_get_daily_position_totals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides situational guidance by noting that automatic pagination is supported for ranges over 31 days, implying the tool is suitable for long date ranges. However, it does not mention when to avoid this tool or name alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

w2w_get_employeesB

Get all employees from When2Work

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only says 'Get all employees'. It does not explicitly disclose whether the operation is read-only, any side effects, authentication needs, or response behavior. The verb 'Get' implies a read, but the description does not confirm safety or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose without unnecessary words. It is appropriately concise for a simple get-all operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, zero-parameter tool, the description is minimally adequate. However, it lacks context about the response format, any implicit filters (e.g., active employees only), or potential limitations like pagination. Without annotations or an output schema, a bit more guidance would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and schema coverage is effectively 100% (vacuously). The baseline for zero-parameter tools is 4, and the description adds no parameter-related information because none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'all employees from When2Work', which is specific and understandable. It does not explicitly distinguish from sibling tools (e.g., get_positions), but the resource name makes it unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. With six sibling get_* tools, there is no mention of when to select this one over others, leaving the agent without context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

w2w_get_positionsA

Get all positions from When2Work

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It only states that it gets positions, with no mention of side effects, return format, filtering, or limitations. For a read-only list operation, this is minimal but lacks any contextual detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words. It is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 params, no output schema), the description is minimally adequate. However, it does not explain return structure or any filters, which might be expected for a 'get all' operation. It is complete enough for basic use but lacks depth.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and schema coverage is 100% (empty schema). The baseline for 0 params is 4; the description adds no parameter-specific detail, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get all positions from When2Work' uses a specific verb ('Get') and resource ('positions'), clearly distinguishing it from sibling tools like w2w_get_employees and w2w_get_shifts. It succinctly states what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. While sibling names suggest differentiation, the description itself does not mention use cases, exclusions, or preferred scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

w2w_get_shiftsA

Get assigned shifts from When2Work for a date range. Supports automatic pagination for ranges over 31 days.

ParametersJSON Schema

Name	Required	Description
`end_date`	Yes	End date in mm/dd/yyyy format (e.g., 01/31/2024)
`start_date`	Yes	Start date in mm/dd/yyyy format (e.g., 01/15/2024)
`position_id`	No	Optional: Filter by position ID

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It discloses a useful behavioral trait (automatic pagination for ranges over 31 days) but does not mention other behavioral aspects such as whether it returns all shifts for the current user, sorting, error handling, or rate limits. The pagination detail is a positive addition, but more context would be needed for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the core purpose. Every word adds value, and it is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with no output schema and a fully described input schema, the description covers the essential purpose and a key behavioral detail (pagination). It could mention scope (e.g., all shifts vs. user's shifts) but overall is adequate for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all three parameters fully documented in the input schema. The description adds general context about date ranges and pagination but does not elaborate on individual parameter meanings beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves assigned shifts from When2Work for a date range, using a specific verb ('Get') and resource ('shifts'). It distinguishes itself from sibling tools by naming a unique resource type, and the date-range scope is explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fetching shift data over a specified date range and notes automatic pagination for long ranges, which helps set expectations. It does not explicitly name alternatives, but the distinct resource type makes the intended context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

w2w_get_timeoffA

Get approved time off from When2Work for a date range. Supports automatic pagination for ranges over 31 days.

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	Yes	End date in mm/dd/yyyy format (e.g., 01/31/2024)
`start_date`	Yes	Start date in mm/dd/yyyy format (e.g., 01/15/2024)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and provides useful behavior: 'approved time off' implies filtering, and 'automatic pagination for ranges over 31 days' discloses pagination behavior. It doesn't cover error handling or exact output structure, but the key traits 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, each earning its place: the first states purpose, the second adds a critical behavior. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with no output schema and no annotations, the description is fairly complete: it states the resource, scope, and pagination. However, it doesn't briefly mention the return format or fields, which would be slightly more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both parameters described with format examples (mm/dd/yyyy). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get'), resource ('approved time off'), and source ('When2Work'), with a scope ('for a date range'). It distinguishes from sibling tools by the specific resource (time off vs employees, positions, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for use (date range) but does not explicitly mention alternatives or exclusions. Sibling tools are distinct by resource, making the intended use apparent from context, so it earns a 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.0Aug 10, 2026
- First observedw2w_get_categories
- First observedw2w_get_daily_position_totals
- First observedw2w_get_daily_totals
- First observedw2w_get_employees
- First observedw2w_get_positions
- First observedw2w_get_shifts
- First observedw2w_get_timeoff

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

Each tool targets a distinct resource (employees, positions, categories, shifts, timeoff, daily totals, daily position totals). The two 'totals' tools could be confused, but descriptions clarify the position breakdown.

Naming Consistency5/5

All tools follow a consistent 'w2w_get_<resource>' pattern using snake_case. No mixed conventions or vague verbs.

Tool Count5/5

Seven tools provide a well-scoped read-only interface for When2Work data. Each tool has a clear place, and the count is appropriate for the server's purpose.

Completeness4/5

Core schedule data (shifts, timeoff, daily totals, position totals) and master data (employees, positions, categories) are covered. Missing single-item fetch endpoints, but listing all resources is sufficient for a read-only server.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
mcp-serverOAuth
io.klokin
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
Workplace & Productivity Project Management
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1

Related MCP Servers

ServiceTitan MCP Server
App Automation Customer Support
JordanDalton
F
license
D
quality
D
maintenance
An MCP server that allows AI assistants to interact with the ServiceTitan API, requiring client credentials for authentication.
Updated a year ago (2025-04-11 00:18 UTC)
4
-
MCP OpenClaw
Communication Calendar Management Shell Access
starlink-awaken
A
license
B
quality
D
maintenance
An MCP server that integrates with the OpenClaw API to enable AI assistants to send messages across multiple platforms, execute system commands, and manage calendar events and emails.
Updated 7 months ago (2026-02-11 20:32 UTC)
5
1
MIT
EARLY App MCP Server
Workplace & Productivity Project Management
janfincke
A
license
A
quality
A
maintenance
An MCP server that provides AI assistants with access to the EARLY time tracking public API, enabling time entry management, activity management, and report generation through natural language.
Updated a month ago (2026-08-08 10:20 UTC)
14
22
MIT
msgraph-mcp
Email Calendar Management Communication
jspv
F
license
B
quality
B
maintenance
MCP server providing AI assistants with full access to Microsoft Outlook email and calendar via the Microsoft Graph API, featuring 26 tools for mail, calendar, contacts, and scheduling with delegated authentication.
Updated a month ago (2026-07-31 01:05 UTC)
29
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheRealAlexV/w2w-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server