TheSignup

Bulk-create items (things participants bring or contribute) on an existing signup. Each item has a name and quantityNeeded, plus optional description, maxPerPerson (the most units one person may claim; 0 or omitted = no limit), category, and askDetails. Use right after create_signup to populate the items panel — items render separately from time slots. Returns the inserted rows.

add_items

Bulk-create time slots on an existing signup. Each slot has start/end times, capacity, and optional title/description/location. Use right after create_signup to lay out a multi-slot event. Returns the inserted rows. Timezone contract (THE-206): supply `timezone` (IANA, e.g. `America/Los_Angeles`) and you can pass naive local ISO times (`2026-09-15T17:00`) — the server interprets them as wall-clock time in that zone. If you omit `timezone` we fall back to whatever zone is recorded on the parent signup; if neither is set, the existing UTC-only contract still applies (start/end must end in `Z` or carry an explicit offset). The slots themselves are always stored as UTC instants — the timezone only governs how the incoming strings are parsed.

add_slots

Transition a signup to any valid status. Use to unpublish (published -> draft), close a signup early (-> closed), or revert a mistaken publish (-> draft). Idempotent — setting the current status is a no-op. Closed signups are terminal and can't be reopened (mirrors the publish_signup rule); create a new signup instead. Moving to `published` requires the account behind this connection to have a verified email address (same as publish_signup); `draft` and `closed` do not. Unpublishing keeps every existing registration: those people hold their spots and can still cancel, but cannot open the page until it is republished — the response carries a `warning` with the count when anyone is affected.

set_signup_status

Create a draft signup — metadata only, no slots or items. Follow up with add_slots and/or add_items, then publish_signup to make it visible to participants. Returns the new id, slug, and draft status. Timezone contract (THE-206): supply `timezone` as an IANA name (e.g. `America/Los_Angeles`) and you can pass `eventDate` / `signupCloseDate` as naive local ISO strings (`2026-09-15T17:00`); the server interprets them as wall-clock time in that zone and stores the matching UTC instant + the zone for display. Omit `timezone` and the existing UTC-only contract still applies (eventDate must end in `Z` or carry an explicit offset).

create_signup

SENDS REAL EMAIL TO REAL PEOPLE. Every call delivers the subject and body you supply to the inboxes of everyone the Message Scope resolves to, immediately, with no undo and no dry-run. Ask the person you are acting for before you call it. Requires the `messages:send` scope, which exists only for this tool and this endpoint — holding `reminders:send` (fixed-body SMS to opted-in participants) or any read scope does NOT grant it. You choose WHO by naming a scope, not by naming people: `all` (everyone attending, no scopeId), `day` (everyone tied to one date, scopeId = that day's event_days id — read it off `eventDayId`/`slot.eventDayId` in list_participants), `shift` (one specific occurrence of a slot, scopeId = that time_slots id — read it off `timeSlotId`/`slot.id` in list_participants), `person` (one participant, scopeId = their registration id), `roster` (everyone who has ever held this repeating Shift, across every date it runs, scopeId = `<seriesId>#<shiftIndex>` — read seriesId/shiftIndex off get_slot_coverage), `gaps` (same people as roster, worded as an ask to cover a short date — same `<seriesId>#<shiftIndex>` scopeId). The server resolves the addresses; you cannot pass any, and an unrecognized field is rejected rather than ignored. Returns `{recipients, sent, failed}` — counts only, never addresses. One email per person however many commitments they hold. `{name}`, `{slot}` and `{item}` in the body are filled in per recipient. Metered per organization per UTC day in RECIPIENTS, not calls; a send that would cross the ceiling is refused whole and nothing goes out. Every call is written to the organization's audit log with your credential, the scope, the recipient count and the subject. Requires the account behind this connection to have a verified email address. To see who a scope covers BEFORE sending, read get_slot_coverage or list_participants under their own scopes. Wraps `POST /v1/signups/{id}/messages` — reference: https://thesignup.app/v1/docs.

message_participants

Live participant/slot/item fill counts and the list of unfilled slots and items. Use this to answer 'how full is X?' or 'which slots still need volunteers?' Computed per call, not cached.

get_signup_analytics

Identify which organizations this connection can act in and which scopes were granted. Call first to confirm context before doing real work. `organization` is the default org — the one used when a tool is called without `organization_id`. `organizations` lists every org reachable from this connection, each with the scopes in force there; pass one of their ids as `organization_id` on any tool to act in it. Also returns a `quotas` map keyed by scope (`ai:draft`, `messages:send`) with `used`, `limit`, `remaining`, and `period`. Unlimited quotas (Pro+) report `limit: null` and `remaining: null`. `messages:send` is never unlimited — it counts RECIPIENTS emailed today (UTC), so read `remaining` before calling message_participants on a large scope.

whoami

List every participant registered for the signup, with their slot/item bindings inlined. Returns an error if the signup isn't owned by the calling org.

list_participants

List recent signups owned by the calling org. Cursor-paginated (page size 1–100, default 20). There is no search endpoint — fetch and filter client-side, or use a known id with get_signup.

list_signups

For a RECURRING signup, one entry per Shift — a repeating slot — rolled up across every date it runs: average fill, how many upcoming dates are staffed vs short (and which dates), unclaimed items, a cell per date, and the Regulars who usually take it. Use this to answer 'which Shift is chronically short?' or 'who normally covers Tuesday setup?'. Differs from get_signup_analytics, which is flat and event-wide and answers 'how full is this signup right now, and which individual slots and items still need people' — it has no notion of a Shift and cannot compare one date to another. Returns an empty list for a signup with no recurring slots; that is not an error. Regulars carry names and attendance counts and NO email addresses — reach someone via list_participants under its own scope.

get_slot_coverage