The Winslow MCP.

Benefits onboarding, end to end

1. Configuration — get_benefits_configuration (created on first read), then update_benefits_configuration to set hasFullCensus if it applies.
2. Plans — create_benefit_plan for each medical, dental and vision plan (PENDING). Move each to VERIFIED with update_benefit_plan once carrier terms are confirmed.
3. Offerings — create_plan_offering per plan (rates, coverage, employer contribution), or copy_plan_offerings_from_previous to roll a plan into a new period.
4. Plan selection — create_plan_selection (DRAFT) → open_plan_selection → close_plan_selection → finalize_plan_selection with the chosen selectedPlanIds.
5. Coverage period — create_coverage_period → activate_open_enrollment, which creates PENDING elections for every eligible employee × offered plan type.
6. Tracking — get_enrollment_tracking through the window; send_enrollment_reminders for anyone who hasn't submitted.
7. Elections — employees (or an admin with benefits:manage-oe) call update_employee_election / waive_employee_election per plan type, then submit_employee_enrollment with a signature. Admins reconcile with list_period_elections, admin_update_election and set_election_status.
8. Close and finalize — close_open_enrollment, then finalize_open_enrollment with acknowledged: true. Call it once first to preview any verification blockers.

QLEs run alongside, any time: preview_life_event_requirements → file_life_event_request → admin review → update_life_event_request_status. APPROVED opens a 7-day QLE window and drafts elections; the employee completes it with get_qle_enrollment and the same election tools.

Payroll response shape

list_payrolls returns summaries. get_payroll returns a curated PayrollView keyed by Winslow employeeRecordIds — no Check ids — with totals, per-employee pay, contractors, and a freshness block. Monetary values are strings for precision (e.g. "15000.00").

{
  "payrollId": "payroll-id",
  "status": "paid",
  "type": "regular",
  "periodStart": "2024-02-01",
  "periodEnd": "2024-02-14",
  "payday": "2024-02-16",
  "approvalDeadline": "2024-02-15T18:00:00Z"
}

Payroll adjustment templates

recurrenceType: ONE_TIME (needs oneTimeOnPayroll ≥ 1), MONTHLY, FIRST_HALF (first payroll of the month), SECOND_HALF. amountType: FIXED_ALL, ASSIGNED_PER_PERSON, CUSTOM_REQUIRED. targetType: EMPLOYEE_TYPE, EMPLOYEE_LIST, DEPARTMENT.

Example — a $150 gym supplement on the first payroll of each month for US full-time:

recurrenceType: "FIRST_HALF",  amountType: "FIXED_ALL",  fixedAmount: 150,
targetType: "EMPLOYEE_TYPE",   targetEmployeeTypes: ["US_FULL_TIME"],
checkPayrollItemType: "bonus", active: true

Benefit adjustment rules

• ONGOING must not include checkPayrollId. ONE_TIME requires it, and the employee must be on that payroll.
• Amounts are dollars, zero or greater; a ONE_TIME employeeAmount must be greater than zero.
• One ONGOING per employee + election; one ONE_TIME per employee + election + payroll.

Artifact types and data shape

• The payload sits at artifact.data.payload (CARD, JSON) or artifact.data.content (TEXT, MARKDOWN) — each artifact has its own data field.
• MCP responses call the namespace appId. REST calls the same value applicationId (and accepts appId as an alias on requests). REST also wraps responses in { "data": … }.
• fields[].type is an optional rendering hint — one of TEXT, MARKDOWN, IMAGE_URL, FILE_URL, URL, PROGRESS, CURRENCY, TABLE. Always uppercase; omit for plain text.

Two-step document upload

begin_employee_document_upload is the preferred path for PDF, DOCX, or anything over 256 KB. Step 1 returns a signed uploadUrl that expires in 15 minutes. Step 2 is a multipart POST of the raw file to that URL — one part named file, 100 MB max. The URL is already signed, so no MCP auth header and no x-client-token is needed. upload_employee_document (base64) is capped at 256 KB decoded.