Wingspan

Payer seat: onboard contractors — create each one, assign their engagements and send the invite. Use for "onboard these contractors", "add these people as contractors", "invite these contractors". Defaults to a preview that writes nothing; call again with mode "apply", a requestId and the confirmationToken that preview returned to actually create them. Email is the only required field per contractor. Contractors who already exist are reported and skipped, never duplicated, and so is a row whose externalId is already on a different contractor.

Payer seat: create payables (payments owed to contractors) against their engagements. Use for "log a payment for these contractors", "add these payments to an engagement", "pay X $500 for Y". Amounts are in DOLLARS, not cents. Defaults to a preview that writes nothing; call again with mode "apply", a requestId and the confirmationToken that preview returned to create them. No parameter on this tool can open, approve, schedule or fund a payment. The contractor cannot see it, and opening is a separate tool with its own confirmation step. A payable's engagement is fixed at creation and cannot be changed afterwards.

Payer seat: read ONE contractor (payee) in full, the way the Contractors detail screen shows them. Returns `alert` — the screen's single headline verdict on whether this contractor is ready to be paid and, if not, the one reason why (invited / tax information not shared / archived / all set / eligibility pending / requirements expiring / requirements incomplete) — plus their tax information and verification, every engagement assignment with its requirement counts, the full requirement list with expiry, their payout-method status and their external id. This is the tool for "can I pay X, and if not why?" and "what is X's status?". To search or list contractors instead, use search_contractors, which is also where a contractorId comes from.

Payer seat: read ONE payable (a payment owed to a contractor) in full, the way the Payables detail panel shows it. Returns the panel's headline and the table's status pill, any alert on it (awaiting the contractor's payment setup, or disputed), the amount with its gross-to-net breakdown and named deduction rows, the line items, the due date and whether it was rescheduled, how it was paid, the dispute state, the attachments, and the full activity timeline of everything that has happened to it, who approved or declined it and when, and where the money is in the banking rail — sent or not, by which rail, and when it should land. Takes the payable by its payableId, by your own referenceId for it, or by its invoiceNumber; exactly one of the three. Use it once you have one of those and need one payment's detail or history — to list, search or filter payables instead, use search_payables, which is also where a payableId comes from.

Payer seat: what the next contractor payroll run will pay, before it goes out. Answers when it processes and when the money lands, how much will move, over how many payables and contractors, what is queued but waiting on a contractor to become payments-eligible, and what will be left behind unless you approve it first. Reads only — it changes nothing about the run. Set includePayables to list the individual payables. For one payable in full use get_payable; to search payables in any state use search_payables.

Payer seat: open draft payables, which is what makes them visible to the contractor. Use for "open these drafts", "release the drafts due this month", "send my contractors their draft payables". Opening is the ONLY thing it changes: it does not approve, fund or pay anything, and approval and payment stay in Wingspan. Choose the payables by id, by a filter over the draft list, or with all: true for every draft; call it with no selection at all and it reports how many drafts exist without touching them. Defaults to a preview that writes nothing and hands back a confirmationToken plus each payable's ifMatch fingerprint — apply needs the token, and the fingerprints mean a payable someone edited in between is refused instead of opened. A filter is resolved again on apply, and if it now matches a different set the call is refused rather than opening payables that were never previewed. Anything already open, paid or cancelled is reported as skipped, not as an error. Opening is externally visible and there is no quiet undo: cancelling an opened payable is a separate action in the app.

Payer seat: list or search contractors (payees). With no inputs it lists active contractors; query searches by name, email, company or external id; status picks a Contractors tab. Rows are the Contractors table's rows and carry the same Requirements and Tax ID status the screen shows. Sortable by createdAt or updatedAt, paginated with limit/pageToken — the response's pagination.nextPageArgs and note say how to continue. Use it to answer "who do we pay / who matches X", and to get a contractorId for get_contractor, create_payables or create_contractors. For "who is holding up payroll?", pass eligibility "blocked": every row then names the requirements blocking it and reports its tax-ID status. For one contractor in full — including what each of their engagements is waiting on — pass a row's contractorId to get_contractor.

Payer seat: list or search payables (payments owed to contractors). With no inputs it lists every non-cancelled payable; status picks a Payables view (draft, toApprove, scheduled, paid, cancelled); query searches by contractor or invoice number; contractor narrows to one contractor; approval, payrollRunId, referenceId and batch narrow further; due/paid date ranges bound the list. summaryOnly answers with the count and total alone. Rows carry the same status wording the Payables screen shows. Sortable by dueDate, createdAt, updatedAt, openedAt, paidAt, amount or scheduledPaymentDate, paginated with limit/pageToken — the response's pagination.nextPageArgs and note say how to continue. Every list carries a summary (count and total amount) for the whole filtered set. For one payable in full, pass a row's payableId to get_payable.

Payer seat: list the requirement definitions you have configured — the things a contractor has to satisfy before you can pay them, such as a W-9, a certificate of insurance or a background check. Each carries a requirementDefinitionId, whether an outstanding one actually blocks payment, who has to act, its grace period and how often it expires. Use it to find the id for search_contractors' requirement filter, which then answers "who is blocked by this one?". These are the TEMPLATES, not one contractor's progress against them — for that, use get_contractor.

Confirm the connection works and report who the bearer token authenticates as — person, email, and the accounts the session can reach. Use to check a token is valid, or when an answer looks like it came from the wrong account or the wrong seat.