What can you do with this server?

The Shiftyasan MCP Server enables AI agents to validate, solve, and monitor shift-scheduling tasks using the Shiftyasan public API. Key capabilities include: * validate_shift_input: Free validation of solver requests against the API schema, returning detailed field-level errors (RFC 7807 format). * solve_shift: Generate optimized rosters; sync solving for small/medium problems (up to ~25 employees, within ~30s), or async for larger ones (returns a job_id). Charged per call. * get_solve_job: Free polling of async job status (running, completed with solution, or failed). * plan_shift prompt: Guides agents through an interactive interview to collect inputs, validate, solve, and present the roster. * Schema inspection via OpenAPI; explicit warnings for partially‑applied preferences/constraints. * Integrates with MCP hosts (Claude Desktop, Cursor, Continue) and ChatGPT via Custom GPT Actions. Pricing: Open beta free; solver calls consume quota; validation and polling are free.

How do I use Shiftyasan MCP Server?

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., "@Shiftyasan MCP Server Validate this shift scheduling input for errors" 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.

Shiftyasan MCP Server

by shiftyasan

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@shiftyasan/mcp-server

npm version License: MIT

Model Context Protocol (MCP) server for the Shiftyasan public solver API. Lets AI agents (Claude Desktop, Cursor, Continue, etc.) call the shift-scheduling solver from any MCP-aware host.

Status: open beta — validate_shift_input, solve_shift, and get_solve_job (async polling for large problems). Usage queries (get_usage) coming next.

Most people no longer need this package

Shiftyasan now runs a remote MCP server, which is the recommended way to connect:

https://api.shiftyasan.com/mcp

	Remote (recommended)	This npm package
Node.js	not needed	20 or newer required
API key	issued automatically when you connect	you create and paste it yourself
Updates	server-side, nothing to do	you update the package
Claude.ai (web) / ChatGPT	works	cannot run a local process

Connecting from Claude.ai or ChatGPT opens a Shiftyasan sign-in page in your browser; approve it once and you are done. Revoke a connection any time from the dashboard under "Connected apps".

This package is still supported and existing setups keep working. Reach for it when you want the server to run locally — for example on a host that cannot reach the internet directly, or when you prefer to hold your own API key.

See the quickstart for the remote setup.

Related MCP server: SpaceTraders MCP Server

What is Shiftyasan?

Shiftyasan is a SaaS that auto-generates work shifts for businesses (retail, hospitality, healthcare, etc.) using a constraint-optimization engine. The same solver is exposed as a public HTTP API at https://api.shiftyasan.com/v1/public/*. This MCP server is a thin client wrapper that turns the API into discoverable tools for AI agents.

Developer documentation — quickstart, the full list of supported constraints, and pricing — lives at https://platform.shiftyasan.com (Japanese and English).

Tools

Tool	Description	Charged?
`validate_shift_input`	Validate a `SolveRequest` payload against the public-API schema (no solver).	No
`solve_shift`	Run the solver. Small/medium problems return synchronously; large problems (roughly 25+ employees) are queued and return `202` with a `job_id`.	Yes
`get_solve_job`	Poll an asynchronous job until `completed` / `failed`.	No

The full SolveRequest / SolveResponse schema lives in the OpenAPI spec at GET <base URL>/v1/public/openapi.json (base URL = SHIFTYASAN_BASE_URL, default https://api.shiftyasan.com).

Prompts

Prompt	What it does
`plan_shift`	Walks the agent through building a schedule: what to ask the user for, when to validate, and how to present the finished roster.

Both arguments (period, context) are optional, so it can be invoked bare. In Claude Code it shows up as /mcp__shiftyasan__plan_shift; other hosts surface prompts in their own UI.

Use it when you want the agent to interview you for the inputs rather than guessing them, or when a previous attempt produced a roster you could not check at a glance. The prompt tells the agent to render one row per person with the per-person totals on the right, which is what a shift manager reads first.

The server also sends workflow guidance in its initialize response (call validate_shift_input before solve_shift, poll get_solve_job on 202, how to read shortage markers and the infeasibility diagnosis). Hosts may add this to the model's system prompt; Claude Code does, Claude Desktop currently does not, which is why the same ordering rules also live in the tool descriptions.

Constraints the schema accepts but the solver does not apply yet

A few fields are accepted by the API and then dropped during translation, because the solver has no equivalent. validate_shift_input and solve_shift print an explicit warning listing exactly what was dropped, so an agent never reports them as honored.

Field	Status	Workaround
`employees[].preferences[].type: "avoided_shift"`	Not applied	Remove the shift from that employee's `assignable_shift_ids` (hard), or state a `preferred_shift` for the shift they should get instead
`employees[].working_days_per_week.max`	Only `min` is used	Use `working_days_per_month` for an upper bound over the period
`constraints.employee_pairings[].rule: "require"`	Not applied (only `exclude` works)	Use `fixed_assignments` to place them on the same shift

Everything else in the schema is applied by the solver.

Install

Running locally requires Node.js 20 or newer. If you would rather not manage that, use the remote server instead.

Use directly via npx (no global install needed):

npx -y @shiftyasan/mcp-server

Also listed in the MCP Registry as com.shiftyasan/mcp-server.

Or install globally:

npm install -g @shiftyasan/mcp-server
shiftyasan-mcp-server

Setup

1. Get an API key

Issue an sk_live_... key in the self-service dashboard: https://platform.shiftyasan.com/dashboard/ (your existing Shiftyasan account works; sign-up is also available). If anything goes wrong, email info@shiftyasan.com (Japanese or English).

Treat the token like a password: it grants access to your solver quota.

Beta note: you may receive a base URL different from the default — set it via SHIFTYASAN_BASE_URL (see below).

2. Configure your MCP host

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%/Claude/claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "shiftyasan": {
      "command": "npx",
      "args": ["-y", "@shiftyasan/mcp-server"],
      "env": {
        "SHIFTYASAN_API_KEY": "sk_live_..."
      }
    }
  }
}

Restart Claude Desktop. The shiftyasan server appears in the tools menu and exposes validate_shift_input, solve_shift, and get_solve_job.

Claude Code

claude mcp add shiftyasan -e SHIFTYASAN_API_KEY=sk_live_... -- npx -y @shiftyasan/mcp-server

(Add -e SHIFTYASAN_BASE_URL=... if you were given a beta base URL.)

Cursor / Continue / other MCP hosts

Add to your MCP server config in the same shape (command + args + env). Refer to your host's docs for the exact config file path.

Using from ChatGPT

ChatGPT cannot spawn local stdio MCP servers like this package, so use the HTTP API directly through a Custom GPT with Actions (the OpenAPI spec is designed to be Actions-compatible — fully inlined schemas, no external refs):

ChatGPT → My GPTs → Create a GPT → Configure → Actions → Import from URL, and enter <base URL>/v1/public/openapi.json (base URL = the one you received with your API key; default https://api.shiftyasan.com).
If you were given a beta base URL, also edit the imported schema's servers[0].url to <base URL>/v1/public.
Authentication → API Key → Auth Type Bearer → paste your sk_live_... token.
Suggested GPT instructions:
You can build optimized work shift schedules with the Shiftyasan actions. Always call the validate action first (free), then solve. Large problems return 202 with a job_id — poll the job endpoint every ~15 seconds until the status is "completed" or "failed".

Notes: creating custom GPTs requires a paid ChatGPT plan, and the API key is stored inside the GPT — do not share that GPT publicly.

ChatGPT's MCP connectors only support hosted MCP endpoints (Streamable HTTP), not local stdio processes. A hosted MCP endpoint is on our roadmap; until then, use Actions as above.

Environment variables

Variable	Required	Description
`SHIFTYASAN_API_KEY`	yes	Bearer API key. Format: `sk_(live\|test)_<64 hex chars>`.
`SHIFTYASAN_BASE_URL`	no	Override base URL (default `https://api.shiftyasan.com`). Useful for staging or self-host.

Example session

In Claude Desktop, after configuring:

You: Schedule 3 employees over the first week of June across morning and evening shifts. Use Shiftyasan.

Claude will discover the tools, call validate_shift_input to confirm the payload it constructed is acceptable, then call solve_shift to get the assignment. Errors from the API (RFC 7807) are surfaced inline so Claude can self-correct (e.g., "staffing_demand length must equal schedule_days").

Pricing

The open beta is free. Each API key comes with a free usage quota (solve_shift consumes units per call; validate_shift_input is always free). Check your remaining quota with GET /v1/public/usage using your key. When you run out, email info@shiftyasan.com to get more.

Paid plans are planned after the beta. The MCP server itself never charges; all metering happens against your SHIFTYASAN_API_KEY on the API side.

Local development

git clone https://github.com/shiftyasan/mcp-server.git
cd mcp-server
npm install
npm run build
npm test

To run against a local gateway:

SHIFTYASAN_API_KEY=sk_test_... \
SHIFTYASAN_BASE_URL=http://localhost:8080 \
  npm run dev

Test interactively with the MCP inspector:

npx @modelcontextprotocol/inspector node dist/index.js

Reporting issues

MCP server bugs / requests: https://github.com/shiftyasan/mcp-server/issues
Underlying API issues: contact info@shiftyasan.com

License

MIT — see LICENSE.

Available Tools

3 tools

get_solve_jobPoll an asynchronous solve jobAInspect

Check the status of an asynchronous solve job created by solve_shift (202 response with job_id). Free of charge. status "running" means the solver is still working — wait ~15 seconds and call again (large problems typically finish within 2–7 minutes). "completed" includes the solution and usage; "failed" includes error.code (e.g. no_solution).

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes	The job_id returned by solve_shift (202 async response).

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description bears full responsibility and does well: it explains the meaning of each status ('running', 'completed', 'failed'), what completed includes (solution and usage), and that failed includes error.code. It also mentions being free of charge, which is helpful 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 three sentences, front-loaded with the purpose, followed by practical status details. Every sentence earns its place—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 polling tool, the description covers the key behavioral aspects: when to poll, what statuses mean, and expected output content. It lacks details on invalid job_id or authentication, but given the simplicity and lack of output schema, it is reasonably 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?

The schema already fully describes job_id (100% coverage), including that it comes from the 202 async response of solve_shift. The description adds no additional parameter semantics beyond restating this, so the baseline of 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 checks the status of an asynchronous solve job created by solve_shift, using a specific verb (check) and resource (job). It also references the sibling tool solve_shift, distinguishing it from validate_shift_input and solve_shift.

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?

It provides clear context: this is the polling tool for async jobs from solve_shift, and explicitly advises waiting ~15 seconds and calling again while status is running. It implies the tool should be used after receiving a 202 response, though it doesn't state explicit exclusions.

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

solve_shiftSolve a shift scheduleAInspect

Run the Shiftyasan solver on a shift scheduling request payload. Synchronous (returns within ~30 seconds for solver_timeout_seconds <= 30). Charged per call: requires SHIFTYASAN_API_KEY with sufficient quota. Tip: call validate_shift_input first to confirm the payload shape (free). See https://api.shiftyasan.com/v1/public/openapi.json for the request/response schema.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	The full SolveRequest payload (schedule_period, shifts, duties, employees, constraints, options). Schema: GET <base URL>/v1/public/openapi.json (base URL = SHIFTYASAN_BASE_URL, default https://api.shiftyasan.com).

TDQS

A4.2/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 disclosure. It clearly states the call is synchronous, returns within ~30 seconds, is charged per call, and requires an API key with quota. This covers latency, cost, and authentication—key behavioral aspects beyond the schema.

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 three concise sentences: the first states the core purpose, the second adds behavioral constraints (synchronous, timeout), and the third gives a usage tip and a link to the full schema. No wasted words; information is front-loaded.

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 tool with one complex parameter and no output schema, the description provides adequate context by referencing the external OpenAPI schema for request/response details, covering prerequisites (validation, API key), and describing latency/cost. It does not spell out the return structure directly, but the external link fills that gap.

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 schema already thoroughly describes the single `request` parameter (100% coverage) including its contents (schedule_period, shifts, duties, etc.). The description's additional mention of 'solver_timeout_seconds' is useful but not required to understand the parameter, so the baseline of 3 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 opens with 'Run the Shiftyasan solver on a shift scheduling request payload,' using a specific verb ('Run') and resource ('Shiftyasan solver') that clearly distinguishes it from sibling tools like validate_shift_input. The intent to actually solve a shift schedule is unmistakable.

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 'Tip: call validate_shift_input first' gives an explicit alternative to use for validation before invoking this tool. It also states the synchronous behavior and mention of charging helps agents decide when to call it, though it does not explicitly mention when to use get_solve_job.

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

validate_shift_inputValidate Shiftyasan solver inputAInspect

Validate a shift solver request payload against the Shiftyasan public API schema. Free of charge (does not run the solver). Use this before solve_shift to confirm the request shape is correct, especially when constructing the payload programmatically. Returns either {valid: true, ...summary} or an RFC 7807 problem detail with field-level errors.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes	The full SolveRequest payload (schedule_period, shifts, duties, employees, constraints, options). Schema: GET <base URL>/v1/public/openapi.json (base URL = SHIFTYASAN_BASE_URL, default https://api.shiftyasan.com).

TDQS

A4.5/5.0

Behavior4/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 that the tool is 'Free of charge (does not run the solver),' implying no side effects, and describes the return format: '{valid: true, ...summary} or an RFC 7807 problem detail.' This provides solid transparency, though it doesn't elaborate on potential errors or rate limits.

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 three sentences, front-loaded with purpose, then usage guidance, and then return format. Every sentence earns its place with no redundancy or fluff.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, no output schema), the description covers everything needed: purpose, usage, behavior, and return value. It points to the external schema for the full payload structure, making it complete for the target use case.

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 of the single parameter (`request`) with a detailed description pointing to the OpenAPI schema. The tool description adds no extra parameter-level meaning, 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 tool's function: 'Validate a shift solver request payload against the Shiftyasan public API schema.' It uses a specific verb ('validate') and resource ('shift solver request'), and distinguishes itself from siblings by noting 'does not run the solver' and pointing to usage before `solve_shift`.

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

Usage Guidelines5/5

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

The description explicitly says when to use it: 'Use this before `solve_shift` to confirm the request shape is correct, especially when constructing the payload programmatically.' This names the alternative tool and provides clear contextual guidance.

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.

3 tool updatesv0.1.0Aug 4, 2026
- First observedget_solve_job
- First observedsolve_shift
- First observedvalidate_shift_input

Install Server

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

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a distinct and non-overlapping purpose: validating input, running the solver, and checking async job status. There is no ambiguity in selecting between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores: validate_shift_input, solve_shift, get_solve_job. The naming is uniform and predictable.

Tool Count5/5

Three tools is a well-scoped set for a specialized solver API, covering validation, synchronous invocation, and asynchronous status retrieval without bloat or unnecessary redundancy.

Completeness5/5

The tool surface covers the full workflow: validate payload, run solver, and retrieve async result. There are no obvious missing operations for the stated domain of shift scheduling solving.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

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

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
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2

Related MCP Servers

Offorte Proposal Softwareofficial
App Automation Marketing Content Management Systems
offorte
A
license
B
quality
C
maintenance
MCP server for the Offorte API - Create & send proposals using AI
Updated 6 months ago (2026-03-19 14:36 UTC)
15
20
5
MIT
SpaceTraders MCP Server
TheValverde
A
license
Not graded
quality
D
maintenance
An MCP server that enables AI agents to interact with the SpaceTraders API, managing agents, fleets, contracts, and trading operations in the SpaceTraders universe.
Updated a year ago (2025-07-22 05:08 UTC)
MIT
w2w-mcp
Calendar Management
TheRealAlexV
F
license
A
quality
D
maintenance
MCP server integrating with When2Work scheduling API, enabling AI assistants to query employee schedules, shifts, time off, and reports via a set of tools.
Updated 6 months ago (2026-02-25 03:58 UTC)
7
-
kaiten-mcp
Project Management Developer Tools
Happiest-d
A
license
Not graded
quality
D
maintenance
MCP server for managing Kaiten tasks through AI agents like Claude, enabling task retrieval, creation, updating, and time logging.
Updated 7 months ago (2026-02-12 20:07 UTC)
644
2
MIT

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/shiftyasan/mcp-server'

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

@shiftyasan/mcp-server

Most people no longer need this package

What is Shiftyasan?

Tools

Prompts

Constraints the schema accepts but the solver does not apply yet

Install

Setup

1. Get an API key

2. Configure your MCP host

Claude Desktop

Claude Code

Cursor / Continue / other MCP hosts

Using from ChatGPT

Environment variables

Example session

Pricing

Local development

Reporting issues

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Offorte Proposal Softwareofficial

SpaceTraders MCP Server

w2w-mcp

kaiten-mcp

Latest Blog Posts

MCP directory API