io.github.theluckystrike/new-hire-onboarding-tasks

Official9 toolsLive

by theluckystrike · JavaScript

New-hire onboarding: role-based task templates, day-one to day-ninety checklists, completion.

io.github.theluckystrike/new-hire-onboarding-tasks (MCP Server)

This MCP server provides new-hire onboarding task templates and checklists across a defined timeline. It supports role-based task templates and day-one through day-ninety checklists, with a focus on task completion tracking. Server data includes name and description fields reflecting this onboarding scope.

🛠️ Key Features

Role-based task templates
Day-one to day-ninety checklists
Task completion

🚀 Use Cases

Onboarding new hires with role-specific tasks
Managing onboarding activities from day one through day ninety
Recording completion status for onboarding tasks

⚡ Developer Benefits

Structured onboarding content derived from provided templates and checklists
Clear mapping to a day-one to day-ninety onboarding window

⚠️ Limitations

Available data does not specify additional tools, endpoints, topics, or configuration details.

Topics

claudecursorinvoicemcpmcp-servermodel-context-protocolspreadsheetaccountingai-toolsbookkeepingclaude-desktopfreelanceinvoicinglocal-firstmcp-serverspdfself-hostedtime-trackingvatproductivity

Captured live from the server via tools/list.

onboarding_hire_add

Add a new hire and return its H-NNNN id: a name, a role and the day they start. The role is a grouping key, lower-cased and hyphenated. Add tasks with onboarding_task_add, or apply a role template with onboarding_template_apply.

Parameters3

name	string	required	The hire's name, e.g. Ada Lovelace
role	string	required	The role, e.g. engineer or sales. Lower-cased and hyphenated
start_date	string	required	The day they start, YYYY-MM-DD. Task due dates are counted from here

Raw schema

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "maxLength": 200,
      "description": "The hire's name, e.g. Ada Lovelace"
    },
    "role": {
      "type": "string",
      "maxLength": 60,
      "description": "The role, e.g. engineer or sales. Lower-cased and hyphenated"
    },
    "start_date": {
      "type": "string",
      "maxLength": 10,
      "description": "The day they start, YYYY-MM-DD. Task due dates are counted from here"
    }
  },
  "required": [
    "name",
    "role",
    "start_date"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

onboarding_hire_list

Every hire with their role, start date, task counts, percent complete and overdue count. Filter by role or by a word in the name. Returns at most 500 rows, newest change first.

Parameters2

role	string	optional	Only hires in this role, matched after the same lower-case hyphenation applied on add
contains	string	optional	Only hires whose name contains this text, matched case-insensitively

Raw schema

{
  "type": "object",
  "properties": {
    "role": {
      "type": "string",
      "maxLength": 60,
      "description": "Only hires in this role, matched after the same lower-case hyphenation applied on add"
    },
    "contains": {
      "type": "string",
      "maxLength": 200,
      "description": "Only hires whose name contains this text, matched case-insensitively"
    }
  },
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

onboarding_task_add

Add one task to a hire's plan and return its K01-style id: the text, who owns it (hr, manager or it) and how many days after the start date it is due. The due date is counted from the hire's start date.

Parameters4

hire	string	required	The hire id, e.g. H-0001, or the name when only one carries it
text	string	required	The task, as the person doing it will read it, e.g. Issue laptop and security badge
owner	string	required	Who owns the task: hr, manager or it
due_offset	integer	required	Days after the hire's start date the task is due. 0 is day one

Raw schema

{
  "type": "object",
  "properties": {
    "hire": {
      "type": "string",
      "maxLength": 200,
      "description": "The hire id, e.g. H-0001, or the name when only one carries it"
    },
    "text": {
      "type": "string",
      "maxLength": 2000,
      "description": "The task, as the person doing it will read it, e.g. Issue laptop and security badge"
    },
    "owner": {
      "type": "string",
      "enum": [
        "hr",
        "manager",
        "it"
      ],
      "description": "Who owns the task: hr, manager or it"
    },
    "due_offset": {
      "type": "integer",
      "minimum": 0,
      "maximum": 365,
      "description": "Days after the hire's start date the task is due. 0 is day one"
    }
  },
  "required": [
    "hire",
    "text",
    "owner",
    "due_offset"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

onboarding_task_done

Mark one task on a hire done or skipped, with the day it happened. done counts toward the percent complete; skipped is a deliberate dismissal and never counts as done. A task can be set back to todo to reopen it.

Parameters4

hire	string	required	The hire id, e.g. H-0001, or the name when only one carries it
task	string	required	The task id, e.g. K03, as shown by onboarding_progress
status	string	required	done, skipped, or todo to put it back to outstanding
date	string	optional	The day it was completed, YYYY-MM-DD. Default today

Raw schema

{
  "type": "object",
  "properties": {
    "hire": {
      "type": "string",
      "maxLength": 200,
      "description": "The hire id, e.g. H-0001, or the name when only one carries it"
    },
    "task": {
      "type": "string",
      "maxLength": 16,
      "description": "The task id, e.g. K03, as shown by onboarding_progress"
    },
    "status": {
      "type": "string",
      "enum": [
        "todo",
        "done",
        "skipped"
      ],
      "description": "done, skipped, or todo to put it back to outstanding"
    },
    "date": {
      "type": "string",
      "maxLength": 10,
      "description": "The day it was completed, YYYY-MM-DD. Default today"
    }
  },
  "required": [
    "hire",
    "task",
    "status"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

onboarding_template_apply

Apply a role template to one hire (free) or many (Pro), copying the template's tasks into each hire with the template's version recorded. Editing the template afterwards never changes a hire already under way. If no template exists for the role, one is created from the tasks you pass.

Parameters3

hire	string	required	The hire to apply the template to. Pro: pass a comma-separated list of hire ids or names to apply to many at once
role	string	optional	The role template to apply, by id (T-0001) or role. If omitted, the hire's own role is used
tasks	array	optional	When no template exists for the role, create one from these tasks and apply it. Pro only when applying to more than one hire

Raw schema

{
  "type": "object",
  "properties": {
    "hire": {
      "type": "string",
      "maxLength": 200,
      "description": "The hire to apply the template to. Pro: pass a comma-separated list of hire ids or names to apply to many at once"
    },
    "role": {
      "type": "string",
      "maxLength": 60,
      "description": "The role template to apply, by id (T-0001) or role. If omitted, the hire's own role is used"
    },
    "tasks": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "text": {
            "type": "string",
            "maxLength": 2000
          },
          "owner": {
            "type": "string",
            "enum": [
              "hr",
              "manager",
              "it"
            ],
            "default": "manager"
          },
          "due_offset": {
            "type": "integer",
            "minimum": 0,
            "maximum": 365,
            "default": 0
          }
        },
        "required": [
          "text"
        ],
        "additionalProperties": false
      },
      "maxItems": 500,
      "description": "When no template exists for the role, create one from these tasks and apply it. Pro only when applying to more than one hire"
    }
  },
  "required": [
    "hire"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

onboarding_progress

One hire's whole plan: every task with its owner, due date and status, plus the percent complete, the overdue count and what is still outstanding. Pass as_csv for a Pro-only CSV export of the plan.

Parameters2

hire	string	required	The hire id, e.g. H-0001, or the name when only one carries it
as_csv	boolean	optional	Return the plan as CSV. Pro only. Default false

Raw schema

{
  "type": "object",
  "properties": {
    "hire": {
      "type": "string",
      "maxLength": 200,
      "description": "The hire id, e.g. H-0001, or the name when only one carries it"
    },
    "as_csv": {
      "type": "boolean",
      "description": "Return the plan as CSV. Pro only. Default false"
    }
  },
  "required": [
    "hire"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

onboarding_overdue

Every task that is still outstanding past its due date, across all hires or one hire, with how many days late. Returns at most 500 rows, most overdue first.

Parameters1

hire

string

optional

Only this hire's overdue tasks. Omit for every hire

Raw schema

{
  "type": "object",
  "properties": {
    "hire": {
      "type": "string",
      "maxLength": 200,
      "description": "Only this hire's overdue tasks. Omit for every hire"
    }
  },
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

license_status

Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.

Parameters

No parameters.

Raw schema

{
  "type": "object",
  "properties": {},
  "$schema": "http://json-schema.org/draft-07/schema#"
}

license_activate

Turn Pro on for this connection with key, an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.

Parameters1

key

string

required

License key from checkout, MCPL1.<payload>.<signature>

Raw schema

{
  "type": "object",
  "properties": {
    "key": {
      "type": "string",
      "description": "License key from checkout, MCPL1.<payload>.<signature>"
    }
  },
  "required": [
    "key"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

servers/onboarding/README.md6 KBView on GitHub

mcp-onboarding

In the official MCP Registry (io.github.theluckystrike/onboarding). New-hire onboarding as role-based task templates, with a dated checklist per hire that HR and the manager both read.

The one rule that decides everything else

If somebody edits the checklist afterwards, adds a step or deletes one, every run already in progress keeps the list it started with, and the version it was copied from is recorded on the run.

That is not a caching convenience. A checklist somebody ticked and signed has to be the list they actually saw. A run that read its steps live from the checklist would mean a signed handover certificate for eleven checks when the person signing it saw ten, with no field in the record showing that it had happened. It also means deleting a checklist leaves its runs readable and complete, which is what you want the year afterwards when somebody asks what was checked.

Two smaller rules follow from it:

Nothing derived is stored. The pass, fail and outstanding counts, the percentage, and whether a run can be signed off are worked out on every call from the run's own steps. A stored "complete" flag is a fact about the afternoon somebody last looked, and complete here is a reading: it appears when the last step is answered and goes away again when one is put back to pending.
Not applicable is not a pass. na counts as ANSWERED and never as passed. A step that was looked at and dismissed is a different fact from a step that passed, and merging the two is how a checklist reports full marks for a job where half the steps did not apply.

What blocks a signature

A required step that is unanswered, a required step that failed, an unanswered optional step, or a run with no steps. force: true signs anyway, and the exceptions stay on the record and print on the report under "Signed with exceptions". They are not lost, and they are not silent.

Install

One-click (.mcpb): download checklist.mcpb from the latest release and double-click it in Claude Desktop: https://github.com/theluckystrike/mcp-servers/releases/latest

npm publish for @theluckystrike/mcp-onboarding is pending, so the npx line below returns 404 today. Build from source in the meantime; see llms-install.md.

Claude Desktop

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

json

{
  "mcpServers": {
    "checklist": {
      "command": "npx",
      "args": ["-y", "@theluckystrike/mcp-onboarding"]
    }
  }
}

Claude Code

claude mcp add checklist -- npx -y @theluckystrike/mcp-onboarding

Cursor

~/.cursor/mcp.json (global) or .cursor/mcp.json (project), same entry as Claude Desktop.

Tools

Tool	What it does
`checklist_create`	Create a reusable checklist: a name, a category, a description
`checklist_item_add`	Add a step: the text, a section heading, and whether it is required
`checklist_item_remove`	Remove a step and bump the version. Runs already under way keep it
`checklist_show`	One checklist, grouped by section, with a blank printable copy on request
`checklist_list`	Every checklist with its version, step count and how many runs came from it
`checklist_delete`	Delete a checklist. Its runs stay readable, because each carries its own copy
`run_start`	Start a dated run against a job. The steps are copied into it at this point
`run_check`	Mark one step pass, fail or na, with who and when and what was found
`run_show`	The run: every step with its answer, the counts, the failures, and what blocks sign-off
`run_list`	Runs newest first, filtered by checklist, status, reference, or only those with failures
`run_sign_off`	Sign off with a name and a date, which freezes the run
`run_status`	Reopen a complete run, or abandon one when the job did not happen
`run_report`	The run as text on every tier. Pro also writes it to `out_path` as a .txt file
`run_delete`	Delete a run. A signed-off one is refused
`license_status`	Which tier this install is on and where the key came from
`license_activate`	Store a Pro key for this server

There is also a resource, checklist://contract, carrying the snapshot rule, the item states, the run status machine, what blocks a sign-off and where this server writes; and a prompt, run_the_checklist, that walks the whole job in order.

Free vs Pro

	Free	Pro
Checklists you keep	3	unlimited
Runs of them	unlimited	unlimited
Steps per checklist	up to 500	up to 500
`run_show`, `run_list`, the counts	yes	yes
The run report as text	yes	yes
Writing the report to a file with `out_path`	no	yes

The meter is on how many DIFFERENT checklists you keep, not on how many jobs you check. A trade with one pre-delivery check, one handover sheet and one snag list runs its whole year inside the free tier. Runs are never capped, because capping the running of a checklist would cap the only thing a checklist is for. Deleting a checklist frees a slot.

Get Pro: https://mcp.zovo.one/buy/checklist (one-time), or all servers for one price at https://mcp.zovo.one/buy/bundle

Privacy

All data stays local, in ${XDG_DATA_HOME:-~/.local/share}/mcp-servers/checklist/. There is no network call anywhere in this server, no API key, and no account. The only file it reads that it does not own is the shared business profile, for the name and address at the top of a printed report, and it never writes to it.

Built by theluckystrike. Support: support@zovo.one

Use these docs as an MCP server

Any MCP client (Claude, Cursor, Windsurf, VS Code) can read this repository's documentation directly via GitMCP - no install:

Docs MCP URL: https://gitmcp.io/theluckystrike/mcp-onboarding

Install

Tools (9)

onboarding_hire_addonboarding_hire_listonboarding_task_addonboarding_task_doneonboarding_template_applyonboarding_progressonboarding_overduelicense_status

Remote endpoint

Streamable HTTP

Hosted server - connect over the network, no local install.

url

https://mcp.zovo.one/mcp/new-hire-onboarding-tasks

Configuration

Environment variables

MCP_LICENSE_KEYsecret

Optional Pro license key (MCPL1....). Verified offline.

Add to VS Code Add to Cursor

claude_desktop_config.json

json

{
  "mcpServers": {
    "new-hire-onboarding-tasks": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.zovo.one/mcp/new-hire-onboarding-tasks"
      ]
    }
  }
}

Desktop config is stdio-only; this bridges via mcp-remote. Native remote: Settings > Connectors.

io.github.theluckystrike/new-hire-onboarding-tasks (MCP Server)

🛠️ Key Features

🚀 Use Cases

⚡ Developer Benefits

⚠️ Limitations

Topics

onboarding_hire_add

onboarding_hire_list

onboarding_task_add

onboarding_task_done

onboarding_template_apply

onboarding_progress

onboarding_overdue

license_status

license_activate

mcp-onboarding

The one rule that decides everything else

What blocks a signature

Install

Claude Desktop

Claude Code

Cursor

Tools

Free vs Pro

Privacy

Use these docs as an MCP server

Install

Remote endpoint

Configuration

Related servers