Well

Add a contact channel to a company or person.

Wraps the resource-scoped REST endpoints (POST /v1/{companies,people}/:id/{emails,phones,web-links,locations}).

channel + the matching value field:

• email → value.email

• phone → value.e164_number (E.164; a leading "+" is added if missing)

• web_link → value.url (+ optional value.platform, default "website")

• location → value.city, value.country (+ optional address_line1/2, region, postal_code) value.label is optional (defaults to "work").

NOTE: adding a phone is supported on a PERSON but NOT on a company (no endpoint) — that combination returns a clear error. To READ existing channels, use well_query_records on the parent (companies/people) or the channel root.

Save the MCP server of a tool Well's catalog does not carry as a connector of this workspace. The connector belongs to this workspace only: no other workspace sees it, and Well's catalog does not list it.

Call it only when well_show_connector_request returned can_add_self: true, with the tool's name and the address the person gave, after well_probe_mcp_server answered "mcp_server" for that address. Only a workspace owner or admin can add one; anyone else is refused.

The address is checked again before anything is saved: Well connects only to a public https address that answers as an MCP server, and re-checks it on every request. Never ask for a key, a token or a password in the conversation: this call takes none. A server that asks for a sign-in on its own page is not open yet ("sign_in_not_open"): say so, and say nothing was saved. Adding the same address again returns the same connector.

Read outcome. "added": say the server is saved for this workspace and name the sign-in from sign_in; with "api_key", say its key is added outside the conversation, and never ask for it. Any other outcome: say in one line why nothing was saved.

Add rows at the end of a log sheet that Well keeps in the Well folder of the workspace's connected Google Drive. Call it when the user asks to log, record or add rows to a Google Sheet.

Well can write only to a sheet it created in its own Drive folder. sheet_name names that sheet: the first call with a new name creates it in the Well folder, and every next call with the same name adds rows to the same sheet. Well cannot write to a sheet the user made or picked: say so and offer a Well log sheet instead.

Pass rows: one array of cells per row, in column order. Every cell is stored as typed; a value that starts with "=" stays text. The user confirms on a card before the rows are added.

When each row carries an id that names it, such as a transaction id, pass key_column: the number of the column that holds the id, 1 for column A. Well then reads that column of the sheet and adds only the rows whose id is not in it yet, and a row whose id repeats an earlier row of the same call is added once. So a repeated call, or a call whose window overlaps an earlier one, adds each row once. Two calls at the same moment on the same sheet can both add a row with the same id. The result gives rows_appended and rows_skipped, the rows left out because their id was in the sheet or earlier in the call. outcome: "already_logged" means every row was already in the sheet: it is a success, and no row was added. outcome: "too_many_rows_to_check" means the sheet holds more than 20000 rows, empty rows included, so Well cannot check it: no row was added, so offer a sheet with a new name. Without key_column, each call adds its rows once more, so never repeat a call that returned appended.

Only the member who connected Google Drive can write to it; a call by another member returns outcome: "not_connection_owner". When the caller connected several Drive accounts, the call returns outcome: "connection_choice_needed" with workspace_connector_ids: ask which one, then call again with workspace_connector_id.

Tell the user the message the result carries and give web_view_link when present. On needs_reconnect, ask the user to reconnect Google Drive. On unconfirmed, ask the user to check the sheet before a new try.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Attach a bank account to a company, and say whether the workspace owns it.

Use this when an account carries no company, or when its ownership is still unknown — the two states a figure that walks account ownership cannot be computed over.

REQUIRED: account_id, plus at least one of company_id or ownership.

ownership is one of:

• "workspace" — the business's own account

• "counterparty" — someone else's, seen on an invoice or a payment

• "unknown" — not yet classified

This changes figures, not just a label. An account marked "workspace" puts its transactions inside the internal-transfer rule: a movement with both legs on owned accounts stops counting as money leaving the business. Marking a counterparty's account as the workspace's own therefore removes real spend from the burn, quietly and consistently, with no error anywhere.

So do not guess it. An account's owner cannot be read off its name, its bank, or the company that appears most often beside it. Ask, or leave it unknown — "not yet classified" is a truthful state and a wrong classification is not.

company_id must name a company in the SAME workspace as the account; a company from another workspace is refused rather than resolved. Pass company_id: null to detach.

Returns { success: true, account_id, ownership, company_id } on success.

Set the owner SET of the missing-invoice TRANSACTIONS you name — the only write for missing-invoice ownership.

REQUIRED: transaction_ids — the settled lines still missing a supplier invoice, from well_list_missing_invoice_owners. owner_person_ids — the people who together owe those invoices; pass an EMPTY array to clear the owners.

Ownership is per TRANSACTION and is a SET, not one owner and not a card rule. The write REPLACES the owner set on every named transaction: the people you send become its owners and anyone not sent is removed. Assigning several people to a (counterparty × month) gap creates ONE proof task per distinct person, and ONE supplier invoice resolves every owner's task for that gap — the fan-out is for accountability, not for N separate collections. Tell the user this plainly.

Each person_id must already be a member of the workspace (get them with well_query_records on people). A person outside the workspace is refused (refusal_reason NOT_FOUND), not silently dropped.

Closed periods are frozen: a transaction whose fiscal month already closed refuses the whole batch (refusal_reason CLOSE_OWNER_PERIOD_FROZEN) rather than rewriting a committed close. A transaction id the workspace does not own refuses the batch too (refusal_reason NOT_FOUND).

Cancel one workspace schedule for good: a one-off that has not run yet ("cancel my 1:45am poem"), a recurring job or an event job. A cancelled schedule runs nothing again and cannot be resumed; to run the job again, create a new schedule. A run already in progress is not stopped.

REQUIRED: schedule_id (from well_list_schedules or the result of well_create_schedule).

Cancelling draws no confirmation card. Confirm the schedule's name with the user in your own words before you call it, and quote the status the result returns.

Use it when the person asks to disable, stop or turn off a routine, such as "disable my morning brief".

Do NOT use this to skip a few days of a routine (use well_snooze_schedule), to pause a schedule you may want back (use well_update_schedule with status "paused"), or to change one (use well_update_schedule).

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Check one bank account (IBAN) against what Well knows of one supplier: the supplier's known bank accounts, the day each first appeared, and the payments made to each. It draws no card. Use it when a person forwards new or changed bank details for a supplier ("our supplier changed bank", "nouveau RIB"), from a mail, an invoice or a typed message, before they pay.

Pass the supplier's company_id and the IBAN as given; spaces and lower case are fine. The IBAN is compared exactly, across every currency pocket of the account.

status:

• never_seen: the supplier is known and none of its known accounts has this IBAN.

• already_paid_there: the IBAN is a known account of the supplier and payments to it are on file.

• known_never_paid: the IBAN is a known account of the supplier, with no payment to it on file.

• own_account: the IBAN is one of the workspace's own accounts, not a supplier's.

• unknown_supplier: the company_id names no company this workspace can read. Nothing is known about its accounts.

• invalid_iban: the value is not a valid IBAN. Nothing was read.

checked_iban gives the checked IBAN's first-seen day and payment count when the supplier has it. accounts lists every known account of the supplier by the last four characters of its IBAN, the checked one first: the day it first appeared (its first payment, or the day Well recorded it when that is earlier), the payment count, the totals per currency and the 10 most recent payments. known_payment_count is every payment to the supplier Well knows; a small number means a thin history, so say how many payments the answer rests on. payments_without_known_account counts payments to the supplier with no known account. accounts_truncated: true means the oldest accounts were not read; the checked IBAN is always read, so never_seen still holds.

The check gives facts and never blocks a payment. Never call new bank details safe from this answer alone.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Claim every bank statement the user dropped on Well's website in one visit, using the ONE claim token from their message or from the /import-statement command argument, or the one claim link from Well's website that carries it (https://wellapp.ai/find-missing-invoices/#claim=...). Pass the link exactly as given; the tool reads the token out of it.

The token covers every file in that drop: call this tool once per token, never per file. It works once and expires an hour after the drop.

Returns one document_id per file; poll well_get_statement_import_result for each.

A refused token (expired, already claimed, unknown) is final: tell the user plainly and ask them to attach the files here, never retry. Files listed under failed were claimed but did not ingest; ask for exactly those by hand.

Compare the supplier quotes of one comparison group, read from the quote documents the workspace received. It writes nothing.

A comparison group is set by a person, never guessed: well_group_quotes puts quotes in one. Call this with quote_request_id to compare that group, or with no argument to list the groups (requests, each with its quote_count, the 20 newest) and the quotes no group holds yet (ungrouped_quotes).

With a group, each quote carries its supplier, its source document_id, valid_until, currency, items_total, tax_total, grand_total (decimal strings in major units of that currency) and its lines in printed order (label, quantity, unit price, line total), every amount as the quote prints it. expired is true when valid_until is before today.

Ranking is per currency only (currency_groups): rank_in_currency 1 is the lowest total among the quotes of that currency still on offer. Equal totals share a rank, and lowest_supplier_quote_id is null when several quotes share the lowest total: name each of them. An expired quote, a quote with no total and a quote with no currency are not ranked (rank_exclusion). When mixed_currencies is true, never add, convert or rank totals across currencies: say the quotes are in different currencies and show each in its own. Quote every figure as returned, with its supplier; never compute a total or a unit price the quote does not state.

The comparison is computed on each call from the stored quotes, as of as_of. url is the link to share it: a signed-in page that only the workspace's members (never a guest) can open, and that recomputes the comparison each time it opens. The link carries no data and no session of its own, so it is not a snapshot: give it as the way to see the comparison stay current, and never call it public.

refusal_reason: "request_not_found" (no such group in this workspace), "no_workspace", "read_failed".

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Call this for any time that is stated in another time zone than the one you will write it in ("3pm New York time", "10am in Tokyo", "what time is that for me?"): never work out an offset or a daylight-saving change yourself, because Well does the calculation and your own arithmetic is wrong around the clock changes.

Pass local_time as the wall-clock date and time, YYYY-MM-DDTHH:mm with no offset and no Z, and from_timezone as the IANA zone that clock is in. Leave to_timezone out to convert into the user's own time zone; pass it to convert into another zone.

Returns instant_utc, from and to. Each of from and to holds the timezone, the local_time with its UTC offset on that day, and the utc_offset. Use to.local_time as the start of a calendar event: its offset is already right.

A clock time that does not exist (the hour skipped when clocks go forward) moves forward by the gap, and one that happens twice (the hour repeated when clocks go back) is the first of the two. When that happens the result carries adjustment ("shifted_forward" or "earlier_of_two") and note, a sentence for the user: tell the user what it says, in the language of the conversation, and use the returned time. On a normal time adjustment and note are absent.

On success false, error_reason says why and error is a plain sentence. "unknown_timezone": the zone name is not an IANA name. "invalid_time": local_time is not a real date and time. "user_timezone_unknown": no time zone is known for the user, so ask them which one they are in and call again with to_timezone set to their answer. In a scheduled run no one can answer: report that the time zone is unknown and write no timed event. Never guess a zone and never fall back to UTC.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Create an event on one of the user's own Google calendars.

Use this tool when the user asks to schedule, book, add or set up a meeting or an event. When the user names no calendar, use calendar_id "primary" and do not look calendars up. Call well_list_calendars first only when the user names a calendar other than their main one, and well_list_calendar_events first when the user may already have the event.

REQUIRED: calendar_id (a calendar id from well_list_calendars, or "primary" for the user's main calendar; never guess a default), title, start_at, end_at, notify_attendees. OPTIONAL: timezone (send it on every create), is_all_day, description, location, attendees (email addresses), recurrence (RRULE lines), visibility.

Ask the user whether the guests should be emailed an invitation, and pass their answer as notify_attendees (true or false). Never assume it. Times: start_at and end_at are timestamps with an offset, such as 2026-10-12T10:00:00+02:00. Send timezone, the IANA name of the zone those times are in (such as Europe/Paris), on every create. For an all-day event send dates (2026-10-12) and set is_all_day to true; end_at is the day AFTER the last day. Sending the same create again within ten minutes returns the event it already made instead of a second one; to book a second identical meeting, change something in it, such as the title. Only the user's own calendars can be changed. If the user has not granted calendar access, the call fails with calendar_scope_not_granted and a link: give that link to the user as it is.

Returns { success: true, event_id, title, start_at, end_at } on success, or { success: false, error } on failure.

Create a new company in the current workspace.

Use this tool when the user asks to create, add, or register a new company.

REQUIRED: name OPTIONAL: description

After creation, enrichment (logo, domain, industry, tax ID, description fill-in) runs asynchronously in the background. The new company is available immediately for follow-up actions, but enriched fields may take a few seconds to populate — re-query after a brief delay to see them.

Returns { success: true, company_id, name } on success, or { success: false, error } on failure.

Mint a company candidate from a registry hit, the step between finding the company and creating its workspace. This is the deliberate pick the confirm-your-company card makes.

REQUIRED: registry_ref — the id of a well_search_company_registry hit. This tool hydrates that hit and mints the company as a primary (own-company) candidate. Then call well_create_company_workspace with the returned candidate_id to make it the company workspace.

Only a workspace owner or admin may mint a candidate. A caller without that role is refused, not silently ignored. When the picked company already has a confirmed company workspace, the result carries linked_to_existing_child: true and its workspace_id — switch into it with well_switch_workspace instead of creating another. Confirm the exact company with the user before calling; never pick one from a name alone.

Create the company workspace from a candidate, the step that turns a picked company into a workspace the close runs in. This anchors the candidate's company as the new workspace's own company and links it to the membership it was created under.

REQUIRED: candidate_id — from well_create_company_candidate. This mints the child workspace, projects its accounting settings from the country defaults, anchors its own company, and writes the lineage row, so well_switch_workspace can move into it in the same conversation. Idempotent: calling it again on the same candidate returns the same child, with already_anchored true.

OPTIONAL, the person's two answers: bring_company_data (true brings the company's history into its workspace: its documents, tasks, transactions and accounts) and move_connectors (true moves the person's bank and accounting connections into the company workspace). Before calling, confirm the company with the person and ask both questions: bring its history (default yes) and move the bank and accounting connections (the card shows it on by default). Pass each answer as true or false exactly as the person gave it, and ask again when an answer is unclear. Omitting move_connectors records "do not move": the connections move only when the person says yes, through the card or in the chat. Omitting bring_company_data means true.

After a successful mint, history reports the stored history choice and preview counts, and connector_move reports the stored connector-move state. Tell the person with these sentences only, translated when they write in another language, and never write a field name, a state or refusal literal, an id or a unit count. history.brought false: "The company's earlier items stay where they are, and nothing was brought into the new workspace." true with counts null: "The company's earlier documents, tasks, transactions and accounts are being linked to the new workspace." true with counts: "N documents, N tasks, N transactions and N accounts will be linked to the new workspace." (more than N when capped; "are linked" only when adoption_status is complete). connector_move.state armed: "Your bank and accounting connections are being moved to the new workspace, and this takes a while." nothing_to_move: "There are no bank or accounting connections to move." pending: "The move of your bank and accounting connections is being set up." refused, whatever the refusal: "Your bank and accounting connections stay where they are, because Well could not move them." not_requested or null: no sentence.

OPTIONAL: existing_workspace_id — when well_get_own_company returned it on the candidate, the person already has a workspace for that company. Pass the id and this call attaches that workspace under this one instead of minting a duplicate: with relation child it already sits under this workspace, with relation top_level it is linked under it. The two answers still apply: the stored choice keeps or brings the history, and the move runs after the call, never before it. Never invent or reuse an id the read did not return; a candidate that carries none mints as before, and one whose offer is stale is refused rather than duplicated.

Only a workspace owner or admin may create the company workspace. A caller without that role is refused, not silently ignored. Confirm the company with the user before calling.

Create a new custom column on the current view in the workspace.

Use this tool when the user asks to add, create, or set up a new column on the active grid (e.g. "add an Industry column", "create an AI column that scores risk").

REQUIRED: name, type

• type: one of text, number, amount, single_select, multi_select, ai OPTIONAL: icon, rules_config, formula_config, format_config

On a grid, the column is always created on the user's currently mounted view: you do not (and cannot) choose a different one, and you do not ask which view. With no grid (an assistant app, or a creation off-grid), pass root: the view the user named, one of companies, people, invoices, transactions, account_balances. If the user named no view, ask which one before calling.

Naming: name must be unique within the current view. If a name conflict is likely, ask the user to disambiguate before calling rather than retrying after a failure response.

Position: the new column is auto-placed at the end of the view. You cannot set position via this tool.

Side effect: creating a column on a populated view automatically schedules an asynchronous recompute of all rows. You will not receive a tracking handle — values appear in the grid as workers finish.

Returns { success: true, custom_column_id, name } on success, or { success: false, error } on failure.

Create a shared-expense group in this workspace: people who split what they paid, such as a dinner, a trip or a flat share. The person who asks becomes its first member: group.created_by_person_id is their own person id. It writes only inside Well and sends nothing.

A group holds one currency for every expense and repayment, and converts nothing. Add the other people with well_create_expense_group_member.

Call it only after the person said yes to creating this group, in this conversation.

Read outcome: written with group, or refused means nothing was written. reason names why: group_not_found (no such group in this workspace), person_not_found (a person id names no person of this workspace), not_a_member, payer_not_a_member, from_not_a_member or to_not_a_member (that person is not a member of the group: add them first), currency_mismatch (the group holds one other currency), invalid_amount, invalid_weight, no_shares, duplicate_share, same_person, already_a_member, caller_not_a_member or caller_not_a_person_here (the call names no person of this workspace).

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Add one person of this workspace as a member of a shared-expense group. Only a member can pay a line, hold a share or take part in a repayment. It writes only inside Well and sends nothing.

person_id is a person record of this workspace, such as one well_create_person returned. A person already in the group is refused with already_a_member, and nothing changes.

Call it only after the person said yes to adding this member, in this conversation.

Read outcome: written with member, or refused means nothing was written. reason names why: group_not_found (no such group in this workspace), person_not_found (a person id names no person of this workspace), not_a_member, payer_not_a_member, from_not_a_member or to_not_a_member (that person is not a member of the group: add them first), currency_mismatch (the group holds one other currency), invalid_amount, invalid_weight, no_shares, duplicate_share, same_person, already_a_member, caller_not_a_member or caller_not_a_person_here (the call names no person of this workspace).

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Add one expense to a shared-expense group: who paid, how much, and how it splits between members. It writes only inside Well and sends nothing.

payer_person_id paid amount (a plain decimal in the group's currency). shares lists every member who owes a part, each with a whole weight: equal weights split equally, a weight of 2 owes twice a weight of 1. The payer is in shares when they owe a part too. The line and its shares are written together, or not at all. Well splits the amount exactly by weight: never compute the parts yourself.

Call it only after the person said yes to this expense and its split, in this conversation.

Read outcome: written with expense_line_id, or refused means nothing was written. reason names why: group_not_found (no such group in this workspace), person_not_found (a person id names no person of this workspace), not_a_member, payer_not_a_member, from_not_a_member or to_not_a_member (that person is not a member of the group: add them first), currency_mismatch (the group holds one other currency), invalid_amount, invalid_weight, no_shares, duplicate_share, same_person, already_a_member, caller_not_a_member or caller_not_a_person_here (the call names no person of this workspace).

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Record one repayment in a shared-expense group: a member paid another member back. It records what already happened: it moves no money, writes only inside Well and sends nothing.

from_person_id paid to_person_id the amount (a plain decimal in the group's currency) on settled_on (YYYY-MM-DD), by method_code. Both must be members of the group.

Call it only after the person said yes to recording this repayment, in this conversation.

Read outcome: written with expense_group_settlement_id, or refused means nothing was written. reason names why: group_not_found (no such group in this workspace), person_not_found (a person id names no person of this workspace), not_a_member, payer_not_a_member, from_not_a_member or to_not_a_member (that person is not a member of the group: add them first), currency_mismatch (the group holds one other currency), invalid_amount, invalid_weight, no_shares, duplicate_share, same_person, already_a_member, caller_not_a_member or caller_not_a_person_here (the call names no person of this workspace).

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Open a Stripe-hosted page for one of three card moments: add_card (a new card), recollect_card (a card group-3 of well_list_payment_cards saved by another person, which must be re-entered on this workspace's own Stripe customer before it can charge here), or complete_authentication (a bank's 3-D Secure check).

Returns url, a link on checkout.stripe.com, billing.stripe.com, hooks.stripe.com or invoice.stripe.com; expires_at, when the page stops working; and then, the tool to call once the user is back (well_list_payment_cards). Hand the url to the widget or open it; never type it into the conversation, never ask for or relay what the page itself collects (a card number, an expiry, a security code), and never read it back from a tool result — this tool returns no card data by design, so there is none to relay.

complete_authentication is refused with authentication_unavailable for now: Well holds no billing offer whose charge the page could finish. Give the bank-check link the payment receipt carries instead, or send the owner to the billing page.

Only a workspace owner or admin opens a hosted payment link. error_reason: missing_key (recollect_card without card_ref, or complete_authentication without offer_id), no_membership (the caller has no active membership in the workspace, or no workspace is in context), not_admin (the caller is a member but not an owner or an admin), authentication_unavailable (see above), billing_off (billing is not active on this Well instance), no_customer (the workspace has no Stripe customer yet; send the owner to the billing page first), failed (Stripe did not return a session).

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Render an existing invoice as a print-ready PDF and attach it as the invoice's source document. The invoice shortcut of well_generate_document: it prints the invoice in its own chosen design, ink and locale. Use well_generate_document instead to choose another design or to print values that are not an invoice in Well.

The letterhead carries the issuing company's own mark when Well has one on file, and otherwise sets the issuer's name as text. Never promise a logo.

Use this tool when the user asks to generate, render, or attach a PDF for an invoice that already exists in the workspace. This does NOT email or send the invoice anywhere — it only creates and attaches the file. A request to email or send an invoice is not a request for its PDF: do not call this tool for it.

REQUIRED: invoice_id (the invoice must already exist)

Refused if the invoice is already linked to a REAL ingested document (an upload, a connector import, or a provider-issued PDF) — that source of truth is never overwritten.

Returns { success: true, invoice_id, document_id, reference_number, file } on success, or { success: false, error } on failure.

file carries the rendered PDF's name and size plus the links to fetch it. Hand the user download_url when they ask for the PDF itself.

• download_url saves the PDF and signed_url opens it in a browser. Both work with a plain HTTP GET and no auth header, and stop working at expires_at.

• preview_url is a PNG image of the first page, for showing the document; add page=N for page N, up to page_count. Same token and expiry.

• sheet_url is the document's HTML sheet, which the card draws with zoom and pan. Same token and expiry.

• When the user wants to do more with a PDF already generated (attach it to an email, upload it elsewhere, read or analyse it), fetch download_url with a plain HTTP GET.

• If the links have expired, call this tool again to refresh the same document and its links.

• app_url opens the document in Well and never expires.

• The links grant access to the file on their own: share them only with the user.

Render values through an invoice template this workspace built from its own invoice, and store the resulting PDF.

Give the template's document_id and input: the invoice's values, in the same shape the built-in invoice designs take. Call well_list_generative_documents with kind "invoice" to read that shape as a JSON Schema. Values that do not match are refused with the path and reason of the first problems found (at most 50), so fix them and call again.

The template must already be kept by the user. A template still awaiting review, or one that was declined, refuses to render.

Totals are never supplied: the subtotal, the tax rows, each lot's subtotal and the grand total are computed from the lines when the template runs, so a printed total can never disagree with the lines above it.

The PDF is stored as its own document and the tool returns its document_id.

Create an invoice in Well from data you extracted by reading an invoice (your own OCR) — you send the structured fields, not the file.

Well persists the invoice + its line items + payment means using the same pipeline as uploaded documents. Fill every field you can read from the document:

• issuer / receiver: { name (required), company_id?, domain?, tax_id? }

• A draft may be saved before it is complete: with status "draft", leave out the issuer, the receiver, issue_date, currency or line_items you do not know yet, and never invent one. On such a draft a party you do send carries its company_id, currency is required as soon as there is a line, and payment_means is left out. The answer's missing_fields names what the draft still lacks. Any other status needs every part

• invoice_number (the invoice's own number, read from the document; leave it out for a draft, Well numbers drafts itself), reference_number? (a reference printed apart from the invoice number; never the invoice number itself; ignored on a draft), issue_date (YYYY-MM-DD), due_date? (YYYY-MM-DD; leave it out on a draft the person gave no due date: Well sets the customer's usual terms, else 30 days after the issue date), currency (ISO 4217)

• line_items[]: { name, quantity?, unit_price, currency?, tax_rate? } — never send totals: Well computes them from the lines, each line held to the currency's minor units

• printed_grand_total? — the grand total printed on a document you read. Well still stores the computed total; when the printed one differs by more than rounding, the answer carries printed_total_mismatch { printed_grand_total, computed_grand_total }: tell the user both figures

• payment_means?[]: { type, iban?, bic?, scheme? }

• status?: draft | issued | paid | canceled — create an invoice the user is still reviewing as "draft", then issue it with well_issue_invoice once the user confirms; issuing gives it the next invoice number and locks it

• document_type_code?: "380" invoice | "381" credit note (state it: an invoice with no document type cannot post); corrects_invoice_id? — the issued invoice a credit note corrects, required for a credit note. An issued invoice cannot be edited: correct it with a credit note, then create a new invoice

ONE CALL IS THE WHOLE WRITE. This tool takes the invoice's status and both parties' company ids, so a create never needs a well_update_invoice after it:

• The user asked to DRAFT an invoice → pass status: "draft" here.

• You already found the company (well_query_records, well_get_entity) → pass its company_id on that party. Naming the party without its id re-resolves it, which can attach the invoice to the wrong company or create a duplicate one.

Creating and then patching the same invoice writes twice and shows the user two confirmations for one action. Put the intent in this call.

The answer carries the saved invoice's status, customer_name, currency, grand_total, issue_date, design_layout (null until a design is chosen) and lines. The card shows them, so the reply does not list them again.

Start building a reusable invoice template from one of the user's own invoices, a PDF already uploaded to this workspace.

Pass the document_id of that PDF. The build reads every page's text, fonts, colours, rules and boxes, marks which of them carry the invoice's data, and assembles a template that copies everything else from the page. It renders the template back and compares it against the original; a template that fails a check goes back for repair, and only one that passes every check is judged by a reviewer. The PDF may run over several pages of one size, at most 30, and must carry a real text layer: a scanned image fails the job with that reason.

This returns as soon as the job is queued; it does not wait for the template. Asking twice for the same PDF while a build runs returns the same job. A build that cannot finish within its time and cost limits stops without a template; offer the built-in designs instead. A build waits its turn when the service is busy, and one that never gets a turn before the queue's last delivery also ends without a template.

A finished template is NOT usable yet. It lands awaiting review, and only the user's own keep, after seeing it beside their invoice, makes it the workspace's design: call well_create_workspace_invoice_design only once the user said to keep it.

Ask for a change to an existing invoice template, described in plain language.

Pass the template's document_id and what the user wants different, for example "move the logo to the right", "show the VAT number under the company name", "drop the notes section".

This queues a revision. The revision is a NEW template document that points at the one it revises; the current template is not edited and keeps working in the meantime.

A revision needs its own keep. It lands awaiting review just like a first build, and only the user's own keep, after seeing it, makes it the workspace's design.

This returns as soon as the job is queued; it does not wait for the revised template. The revision waits its turn when the service is busy, and one that never gets a turn before the queue's last delivery ends without a template. A revision that comes out identical to a template already stored saves nothing and says so.

Create a new person (contact) in the current workspace.

Use this tool when the user asks to add, create, or register a new contact, employee, or person.

REQUIRED: first_name OPTIONAL: last_name, job_title

After creation, enrichment runs asynchronously in the background.

Returns { success: true, person_id, full_name } on success, or { success: false, error } on failure.

Create a product in the current workspace: a good, a service, a plan or a collection the workspace sells or buys. A variant, a collection member or a dated price nests under a parent product.

Use this tool when the user asks to create or add a product, a service, a plan, a variant or a price.

REQUIRED: name, supply_type (good, service, plan or collection), status (draft, active or archived), availability (in_stock, out_of_stock, preorder or discontinued). Ask the user when they did not say one of these; never guess it. OPTIONAL: sku, description, unit_price (a decimal string) with its currency, parent_product_id, vendor_company_id, product_type_project_id. A price for one company or one project is a dated row under its parent: parent_product_id, valid_from (YYYY-MM-DD) and scope_company_id or scope_project_id, with valid_to to close it.

A collection has no parent, no price and no SKU. Two live products cannot share a SKU: the call then fails, and well_list_products finds the existing one.

Returns { success: true, product } on success, or { success: false, error } on failure.

Create a project in the current workspace. A project is any tracked business object with a name, a kind and a status: a campaign, an ad, an audience, a flow, a deal, a cost center, a project, a property, a pipeline or a pipeline stage.

Use this tool when the user asks to create, add or start tracking one of these.

REQUIRED: name, kind, status. Ask the user for the kind or the status when they did not say it; never guess it. OPTIONAL: start_date and end_date (YYYY-MM-DD), amount (a decimal string) with its currency, parent_project_id (the project this one nests under; read it with well_list_projects).

Each kind admits its own fields; the call fails on any other and nothing is written:

• deal: status draft, active, paused, won or lost (or archived); an end_date and an amount, no start_date; it does not nest.

• project: status draft, active, paused, completed or archived; dates and an amount; it nests only under a project.

• campaign, ad, audience, flow: status draft, active, paused, completed or archived; dates, no amount; only an ad nests, under a campaign.

• cost_center, property, pipeline, pipeline_stage: status active or archived; no dates, no amount. A cost_center nests only under a cost_center; a pipeline_stage must nest under a pipeline.

Two live pipelines, pipeline stages or cost centers with the same parent cannot share a name: the call then fails, and well_list_projects finds the existing one. Other kinds may share a name.

Returns { success: true, project } on success, or { success: false, error } on failure.

Add a supplier to Well's provider catalog, from the draft of a well_lookup_provider result, and link it to this workspace. A portal the web found joins the catalog every workspace uses. A link the person gave stays with this workspace only.

Call it only with the draft_ref of a well_lookup_provider "draft", in the turn where you showed that draft; the confirmation Well shows is the person's yes. Never edit the ref. A correction ("the portal is X", "call it Y") is a new well_lookup_provider call, which returns a new draft.

Nothing runs in the browser. The supplier then shows as a tile on the collect page, and a fetch of its invoices opens its portal address.

Read outcome. "created": the supplier is added; use provider.provider_id. "exists": another catalog row already held this portal address, and that row is the one linked. When provider.counterparty_matched is false, the missing-invoice list and the fetch preview still give that supplier row no provider: never say the row is linked. On refusal_reason "draft_ref_expired" or "draft_ref_invalid", look the supplier up again. On "slug_unusable", say Well could not add it and keep the row on manual upload.

Create one workspace schedule: a job Well runs on a clock or on an event, with nobody in the chat. A schedule is either a prompt (a written instruction a headless run follows) or a method (a registered function name plus params).

Use it whenever the user wants something done or sent at a later time, on a rhythm or when an event happens.

A schedule covers three kinds of job:

• Once, at a set time: "send me a poem at 1:45am", "remind me Friday to pay Kepler". Send max_occurrences 1, run_after at that moment (ISO 8601 with an offset) and a cron_expression that matches that time of day. The run is the message or the job itself. A day with no time runs at 09:00 in the user's time zone: say that time in the cadence_label and in your confirmation. If the start time passed before confirmation, propose a new time.

• Recurring, on a rhythm: "every Monday 9am send me the runway". Send a cron_expression and no max_occurrences.

• On an event: "each time a payment is matched to an invoice". Send a trigger_name from well_list_schedule_triggers. A message for the user is a job like any other. Well sends the user the run's result after a run that succeeds, so for a message or a reminder set status_report to "on_success" and write the instruction so the run puts the message itself (the poem, the reminder line) in its result. On WhatsApp the message arrives as written inside the 24 h window; outside it the user first gets a notification with a short summary, and the full result arrives after they reply. A to-do ("add a to-do", "I need to file X by Friday") is a task, not a schedule.

REQUIRED: name, kind ("prompt" or "method"), routine_summary, cadence_label, status_report, timezone, approved_tools and verified. Send exactly one: cron_expression for a clock, trigger_name (from well_list_schedule_triggers) for an event. An event routine takes no run_after or max_occurrences. For a prompt: instruction (the detailed brief the run follows to the letter, with every decision it must make alone). For a method: method_name, and method_params when the method takes any.

The user never reads the instruction, the cron or a trigger name: the instruction is the detailed brief for the run, and a person does not read a contract. Show the user only the routine_summary, when it runs (with the status report choice) and the permissions, in plain words, and never paste the instruction, a cron expression or a trigger name into the chat. The confirmation card shows the same three things, built by Well from the stored schedule.

routine_summary and cadence_label are written for the user, in the language of the conversation, as plain text with no markdown. routine_summary says what will happen, and who or what outside Well each change reaches. cadence_label says when it runs. For a clock it says the rhythm in words and says the same thing as cron_expression: write both in the same call. Well computes the next run dates from cron_expression and shows them beside cadence_label, so a label that disagrees with the cron is visible to the user. For an event it says the event in plain words, such as "Each time a Qonto payment is matched to an invoice", and never the trigger_name. OPTIONAL, for a clock routine only: run_after (ISO 8601 with an offset: no run happens before it), max_occurrences (a whole number of runs, then the schedule completes; 1 runs once).

cron_expression is a standard 5-field cron: minute, hour, day of month, month, day of week. A seconds field is refused. timezone is an IANA name such as Europe/Paris, and a cron is read in it. A cron whose day-of-month and day-of-week fields are both restricted fires when either one matches. To tie a weekday to its nth occurrence in the month, leave day-of-month as * and write the weekday, then #, then n, in the day-of-week field. A clock routine does not run on Sunday in the user's time zone unless the user asked for Sunday, has a business meeting that Sunday, or often writes to Well on Sundays. When the user asks for a routine on Sunday, or on all seven days of the week, name Sunday in the day-of-week field, as 0 alone or inside a list or range that holds each day asked for: a * there does not ask for Sunday. A one-off at a set time always runs. A request never to run anything on Sunday changes no routine: Sundays are already held back by default. For a cron, two runs of a schedule must be at least 30 minutes apart, and the rhythm must fire at least once a year. A rhythm outside that range is refused, never adjusted: explain the rule to the user and let them choose a rhythm that keeps it.

status_report is the user's own answer to the report question: "on_error", "on_success", "both", or "none" when they did not ask for a message. Well sends the report itself after each run; never write it into the instruction.

approved_tools is the consent record: the write tools the user signed off before the schedule was armed, as entries { tool, connector? }. The tool of each entry is the exact name of a write tool in your own toolset, one entry for each change the user approved; a read tool or a guessed name is refused, and so is any tool that invites members, buys credits, changes the plan, manages the subscription or sends email: a routine cannot do those, so tell the user instead of listing them. It is required, and [] means the routine only reads. At run time a scheduled run is told to make only the changes the list describes. A method schedule always sends [].

purpose is optional and names the job when a recipe of the schedule skill names it, such as "weekly_missing_invoices_total" for the missing-invoices total. Send it exactly as the recipe names it, and leave it out for any other routine. Well finds a routine by its purpose, never by its text, so a member never gets the same routine twice.

verified is required. false saves a draft that runs nothing and draws no card. true asks to arm the schedule: in Well's chat the schedule runs only after the user approves the confirmation card, and anywhere else it is saved as a draft. Both are required so that a forgotten flag or list is an error, never a default. Only a call that arms a schedule (verified: true) asks the user for approval, through a confirmation card in Well's chat, and the schedule is armed only when the user approves it. Outside Well's chat no card can be drawn, so verified: true arms nothing there: the call saves the schedule as a draft, and the user arms it from Well's chat. Saving or editing a draft, pausing, resuming and cancelling draw no card. Editing the routine_summary, the cadence_label, the instruction, the method, the rhythm, the time zone, the start, the end limit or approved_tools returns the schedule to a draft, which runs nothing until it is armed again.

The result states status and next_run_at. Quote them to the user, and say the stored approved_tools in plain words, never as tool names.

WORKFLOW: 1. Load the /schedule skill and follow it. 2. Show the user the routine_summary, when it runs and every permission in plain words, and get an explicit yes. 3. Call this tool once, with verified: true. 4. In Well's chat, wait for the user to approve the card, then quote status and next_run_at. Anywhere else, quote the draft status and tell the user to arm the routine from Well's chat.

The conversation that produces a good schedule (what the run needs, which jobs cannot run alone, the rhythm advice and the permission list the user signs off) belongs to the /schedule skill. Load it before proposing a schedule.

Do NOT use this to run a job once now; the skill that owns the job does that. Do NOT use this to change a schedule that exists (use well_update_schedule), or to add a to-do (use the tasks tool). A scheduled run never calls this tool.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Mint a one-time, short-lived upload slot for a bank-statement file.

Use this when the user has a statement file (PDF, or a large CSV/XML) to import; the file's bytes do not travel through the model. It returns a single-use upload URL + token; the client (or the user) POSTs the raw file bytes to that URL, and the resulting document enters the exact same import pipeline as an in-app upload (detection, dedup, promotion).

This result renders a card in widget-capable hosts right away — do not wait for a poll to make it appear. One statement file per call: mint a separate slot for each file. Once the client has uploaded the file bytes, call well_get_statement_import_result with the document_id below one time to learn the outcome. The card polls the import result itself until it settles, so call that tool again only if the user asks.

The token authorizes exactly ONE upload to this workspace and expires in 15 minutes. It is burned on first use — a second upload needs a new slot. It cannot be used for anything other than a statement upload.

The response's document_id is PRE-ALLOCATED at mint time — the upload has not happened yet, and this exact id is what the document will carry once it does. A call to well_get_statement_import_result before the upload lands is a normal "not_found_yet", not an error.

Create a task for a member in the current workspace.

Use this tool when you found something a member should look at or act on — a real request made of them, a claim to follow up on, an anomaly worth a review — and no existing task already covers it.

REQUIRED: title, executor_type, dedup_key (a stable id for the thing you found — the same source re-checked later must pass the same dedup_key, so it is never created twice). OPTIONAL: description, assigned_to_id (defaults to you, the caller), due_date, priority.

A call whose dedup_key matches an earlier call returns the task that already exists; it never creates a second one. A routine may use this tool only within its own per-run cap.

Returns { success: true, task_id, title } on success, or { success: false, error } on failure.

Make a built invoice template the workspace's own invoice design, after the user kept it.

Call well_get_workspace_invoice_design_offer first, with the same document_id, and show the user what it returns: the legal mentions text, whether a logo was cut from the invoice, and the company that issued the invoice, named in words. When that company is not the workspace's own, say so. Call this tool only after the user saw the template beside the invoice it was built from, saw that list, and said to keep it. Ask the user, for each of the two, whether to keep it or remove it, and pass the answer: keep_logo and keep_legal_mentions are required and have no default. Never pass true for a logo or a text the user did not keep. Pass the issuer_relation and the offer_token that the read returned: a keep made on a different reading or a different offer is refused.

Pass the template's document_id. The keep approves the template, so from then on every new invoice drafted in this workspace opens on this design and prints with it, except for a customer that keeps a design of its own; the result names those customers so you can offer to switch them. One draft can still take another design, and an issued invoice never changes. Keeping again replaces the workspace's design with the new one. Only a workspace owner or admin can keep a design.

A kept legal mentions text is saved as a note of the workspace, unless the template prints none of it: then no note is saved and legal_mentions_note_id is null, so tell the user the mentions were not kept. A removed logo or text is left out of every invoice printed with the design. When the template still prints the removed mentions in a form that cannot be found line by line, the keep is refused: ask for a revision that removes them (well_create_invoice_template_revision), then keep that revision.

Define one company as a customer of this workspace: records that the workspace's own company bills it.

REQUIRED: entity_id and entity_kind, both from a row of well_list_customers. Call it only after the user chose that row on the card; never pick a customer from a name alone. A registry row's entity_id adds the company to the workspace first, then defines it.

The write is idempotent: defining a customer that is already defined succeeds with created: false. It never edits the company itself, and it refuses the workspace's own company. To bill the customer, pass the returned entity_id as the invoice's receiver company.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Read what this workspace has already billed, and flag which of the lines the user just described equal a past line. Use it before well_create_invoice_from_data, when the invoice's lines come from the user's words ("two days of consulting, and the hosting").

Pass lines: one entry per line the user described, each with a line_key (a fresh UUID you choose for that line and keep for the whole conversation, never its position in the list), its name, its sku when the user gave one, and its quantity, unit_price and tax_rate when the user stated them ("3 days at 600" is quantity 3, unit_price 600; tax_rate is a percentage, 20 for 20%). Leave a figure out when the user did not state it. Never invent one. unit_price is in currency, the invoice's: a price the user stated in another currency ("50€ a day" on an AED invoice) is converted first with well_get_fx_quote (base the price's currency, quote the invoice currency, amount the unit price), and its converted_amount is passed as unit_price. Never leave such a price out unless the rate tool returns no_rate, never pass it unconverted, and never convert it yourself. Pass customer_id (the entity_id of the pre-selected or chosen customer) when you know the customer, so the lines already billed to them rank first. Pass currency (the invoice's ISO 4217 code, e.g. "EUR") when you know it, so only past lines billed in that currency come back and match: a price billed in another currency does not hold.

Returns items: the workspace's distinct past sales lines (one product billed in two currencies is two items), newest first (customer's own lines ahead of the rest), each with item_id, name, sku, unit_price, currency, tax_rate, times_billed (counted inside the recent window, not a lifetime total), last_billed and billed_to_customer. Returns matches: one entry per sent line, matched_on "sku" or "name" with the item_id of the past line it equals, or both null when no past line equals it, plus requested: the quantity, unit_price and tax_rate you sent for that line, echoed unchanged (null for a figure you did not send). Returns totals: items_total, tax_total and grand_total of the lines in requested, computed by Well in currency (each line's total and tax held to the currency's minor units, a line with no quantity counted once, a line with no unit_price and an exact match at the matched past item's unit_price, a line with no tax_rate at the vat_default rate), or null when you passed no currency, a line still has no unit price, or a line has no known tax rate (none stated and a null vat_default.rate). These are the figures to show the user. NEVER compute a total or a tax yourself, and never send one to a create tool: Well computes them from the lines. Well does not match on the other figures.

Returns vat_default when you passed customer_id: the VAT rate a line opens with, worked out by Well from the issuer's country and the customer's country (rate in percent, or null when a country is unknown; basis: "domestic" the issuer's own country's standard rate, "intra_eu_reverse_charge" or "intra_eu_no_vat_id" a customer in another EU country, 0, "export" a customer outside the EU, 0, "unknown" no answer). The card shows that rate on every line that has none stated, ready to edit. NEVER ask the user for a VAT rate and never type one yourself: pass tax_rate only when the user stated one in their own words. A stated rate wins over vat_default.

When the lines belong to a draft already saved (the person changes its lines, quantities or currency), pass its invoice_id and, on each line that is already on the draft, its line_id from the lines of the last invoice answer. Then a figure you did not send is the draft's saved one: requested carries the saved quantity, unit price and tax rate, and when currency differs from the draft's currency the saved prices come converted by Well at the rate of the issue date, with fx_conversion (from_currency, to_currency, rate, rate_date, source) naming the rate. In Well's chat a call without invoice_id reads the newest draft this conversation created for the same customer the same way. draft_invoice_id names the draft the figures came from, and each match of a saved line carries its line_id. NEVER ask the person for a price the draft already holds, in any currency, and never convert a price yourself. In Well's chat, write the answered lines to the draft with well_update_invoice and its line_items, never a delete and a new create.

A match is exact equality only: the same sku, or the same name once case and spacing are ignored. A null is not proof the line is new. Read items and judge whether a near name is the same thing. Only invoices this workspace issued or was paid for are read, never drafts, canceled invoices or invoices it received. A past price is a suggestion, so confirm it with the user before it goes on an invoice.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Delete an event from one of the user's own Google calendars.

Use this tool when the user asks to cancel, delete or remove a meeting or an event. Find the event first with well_list_calendar_events or well_get_calendar_event. Skip the lookup only when the user gave its event_id and either the event is not repeating or the user gave the exact start of the occurrence.

REQUIRED: event_id, scope, notify_attendees. scope is "occurrence" to delete just one meeting of a repeating event, or "series" to delete all of them; for a single event either value deletes that event. For one occurrence of a repeating event, also send occurrence_start, a timestamp with an offset (2026-10-12T10:00:00+02:00): the exact start the user gave, or else the occurrence_start value the list returned for it. Never guess it: if the user gave only a day, look the occurrence up with well_list_calendar_events first. For a repeating event, ask the user whether they mean this one occurrence or the whole series, and pass their answer as scope. Never assume it. Ask the user whether the guests should be emailed about the cancellation, and pass their answer as notify_attendees (true or false). Never assume it. Only the user's own calendars can be changed. If the user has not granted calendar access, the call fails with calendar_scope_not_granted and a link: give that link to the user as it is.

Returns { success: true, event_id } on success, or { success: false, error } on failure.

Delete a company from the current workspace (soft delete).

Use this tool when the user asks to delete, remove, or archive a company.

REQUIRED: company_id

This soft-deletes the company and its company_person relationships. Linked people records themselves are NOT deleted. Invoices and documents referencing the company are preserved.

Returns { success: true, company_id } on success, or { success: false, error } on failure.

Delete a custom column from the current view (soft delete).

Use this tool when the user asks to delete, remove, or archive a custom column.

REQUIRED: custom_column_id

This soft-deletes the column. Existing CustomColumnValue rows are NOT cascade-deleted — they remain in the database, orphaned to a hidden column. This is normal for soft deletes; do not warn the user about it unless asked.

Returns { success: true, custom_column_id } on success, or { success: false, error } on failure.

Delete an invoice from Well (soft delete).

REQUIRED: invoice_id

Soft-deletes the invoice. Linked line items and payment_means rows are NOT cascade-deleted — they remain in the database, orphaned. The delete is reversible only at the database level.

Delete the link to the web page that shows one draft invoice, so the address no longer opens for anyone who has it. Call it when the user asks to stop sharing, delete or revoke the draft link. Only a workspace owner or admin can.

REQUIRED: invoice_id (the invoice whose draft link stops).

The invoice itself is unchanged. A later well_get_invoice_draft_link for the same draft makes a new address; the deleted one never opens again. When outcome is "no_live_link", say the invoice had no live link; never say a link was stopped.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Delete the customer page of one issued invoice: the page whose address and QR code the invoice prints, and that well_mint_payment_link gives as portal_url. After the delete, that address no longer opens for anyone, including from a PDF or a message already sent, and its card payment link is turned off at the provider. Call it only when the owner asks to delete, stop or cancel an invoice's customer page or payment link; never on your own. The invoice itself stays.

Pass invoice_id: the invoice's id, or the number the owner named it by (INV-2026-0148).

The result's outcome:

• deleted: tell the owner the page and its address no longer open. A later well_mint_payment_link makes a new page with a new address; the deleted one never opens again.

• no_live_link: the invoice has no customer page; say so, and never say one was deleted.

• provider_link_kept: nothing was deleted, and message says why. Give connect_url as a plain link when it is present. Never retry on your own.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Delete a person (contact) from the current workspace (soft delete).

Use this tool when the user asks to delete, remove, or archive a contact.

REQUIRED: person_id

This soft-deletes the person and its company_person relationships. Linked companies themselves are NOT deleted. The authenticated user cannot delete their own person record.

Returns { success: true, person_id } on success, or { success: false, error } on failure.

Reset one saved workspace preference, so the setting falls back to the workspace default or to none. scope: "member" resets the CALLER's own override; scope: "workspace" resets the workspace value, and the un-namespaced workspace default needs an owner or admin. Only an owner or admin can pass member_id to reset another member's action_trust level.

Known keys: invoice_default_layout, invoice_design, action_trust, preferred_name, form_of_address, mail_sender_choice, timezone, bank_account_offer, invoice_payment_account, payment_link_reconnect_offer, sunday_routines, customer_facts_note_id. For action_trust the namespace is the kind code, and resetting it makes Well ask the person how to treat that kind again, on the next action of the kind. Resetting a level needs no confirmation for action_trust. A reset can lift a member to a workspace default of act_alone, and that is a raise: the server refuses it over MCP, as it refuses any raise to act_alone.

The result includes previous_value: the value the row held before it was removed, or null if there was none.

Delete a product from the current workspace (soft delete).

Use this tool when the user asks to delete or remove a product, a service, a plan, a variant or a price. Find the product_id first with well_list_products. To stop selling a product but keep it, change its status to archived with well_update_product instead.

REQUIRED: product_id.

A product a connected tool synced in (synced: true) is not deleted: the next sync would bring it back. A product that variants, collection members or dated prices nest under is not deleted either: move or delete those first. In both cases the call fails and nothing is deleted.

Returns { success: true, product_id } on success, or { success: false, error } on failure.

Delete a project from the current workspace (soft delete).

Use this tool when the user asks to delete or remove a project, a campaign, a deal, a cost center or a property. Find the project_id first with well_list_projects. To close a project but keep it, change its status with well_update_project instead.

REQUIRED: project_id.

A project a connected tool synced in (synced: true) is not deleted: the next sync would bring it back. A project that other projects nest under, that a product names as its price scope or its type, or that a forecast plans for, is not deleted either: move or delete those first. In both cases the call fails and nothing is deleted.

Returns { success: true, project_id } on success, or { success: false, error } on failure.

Log the user out of WhatsApp. This is the way to log out of WhatsApp or unlink a number: it removes the link between the user's WhatsApp number and their Well login, in every workspace of that login. The next message from that number gets a fresh sign-up link. The user's phone stays on their profile.

Call it when the user asks to log out of WhatsApp, unlink or disconnect their number, or start fresh on WhatsApp, in any language. Examples: "log me out of WhatsApp", "unlink my number", "disconnect my WhatsApp", "start fresh on WhatsApp", "déconnecte-moi de WhatsApp", "me déconnecter de WhatsApp", "délier mon numéro", "repartir de zéro sur WhatsApp". Never tell the user this cannot be done. It is not for starting a new conversation topic, and not for disconnecting a connector.

Omit person_id for the user's own number. An owner or admin who asks to unlink another member's WhatsApp passes that member's person_id: it removes the number that member proved in this workspace only. Anyone else is refused.

The result is status "unlinked" with how many links were removed, or "not_linked" when no number was linked. When still_reaches_workspace is true, the member proved the same number in another workspace, so it still reaches this workspace: tell the user so, and do not say the member is logged out here.

Stop the workspace link of one role, when the user asks to stop, cancel or delete the invitation link into their own workspace. From then on the link admits nobody. The people who already joined through it stay in the workspace.

Pass role: admin or member, the role of the link to stop. Ask the user which role when they named none.

workspace_link_deleted is true when a link was stopped and false when no link was live for that role. A later well_get_workspace_invite_link for that role makes a new link, and the stopped one never works again. Only an owner or admin of the workspace may stop a link; otherwise workspace_link_refusal is INSUFFICIENT_PERMISSIONS and nothing changes.

Get a grounded description of ONE entity — what it is, using its real field values and one hop of its related records, never a guess. Reach for this on a SPECIFIC question about one already-identified entity that wants a short inline answer: "does this person pay on time", "anything unusual about this invoice", "summarize this company's payment history". An open-ended "tell me about X" / "show me all you got on X" / "everything you have on X" / "what do you have on X" ask is NOT this tool: call well_show_record_graph_summary for it, even for a single entity, because that card carries the entity's graph plus its written summary.

Resolve X to its record id first (well_query_records or well_get_entity), then call this tool with that root + id — never a guessed id or a name string.

Returns description (what this is), positive (an unusually good fact, when one stood out), and flag (an unusual or concerning fact, when one stood out) — positive and flag are "" when nothing stood out, which is expected and not an error. Set deep_search=true only when the ask needs the workspace's recorded notes/context on this entity too, not for a plain describe.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Show an email draft on a card so the user can read it, edit it and send it. Nothing is sent by this call. The only thing it stores is each linked document's durable download link, which stays the same on every call.

REQUIRED: invoice_id, document_ids, transaction_id, task_id or links_no_file: true: a draft that names none of them is refused with attachment_required. links_no_file: true is for a plain email about no invoice, no document and no transaction (a question to a supplier, a reply), when the user asks to see or edit the draft first; it cannot be combined with the three ids. To send an email the user dictated, well_send_message is the tool, not this one. subject and body are required too, except with an invoice_id: leave them out and Well words them from the invoice, in the language it prints in (a credit note's email names it a credit note and the amount it credits). Optional: to, cc, bcc, purpose (a few words on what the email is for).

to holds the addresses the user gave. With an invoice_id and no to, Well fills to with the customer email the invoice prints, so do not look the address up yourself. With a task_id and no to, Well fills to with the email of the company the task names, when it knows one. When no address is known, pass to: [] and draw the card anyway: the card asks the reader for the address. Never ask for it in text first.

For an email about an invoice, pass its invoice_id: Well links that invoice's own PDF itself. Only an issued invoice can be emailed: a draft is refused with invoice_not_issued (offer Finalize instead) and a canceled one with invoice_canceled. Do not pass a document_id for an invoice: the document_id a create or extract call returned is the invoice's source data, not its PDF, and is refused. document_ids are other PDFs of this workspace to link; anything that is not a PDF is refused. An invoice with no PDF yet is refused with invoice_pdf_missing: call well_generate_document with its invoice_id, then call this tool again.

For an email about an open anomaly task (for example writing to a supplier about a detected issue with no invoice or document to link), pass its task_id: Well checks the task and fills the recipient, you write the subject and body from what the task found. A task that is not an anomaly task is refused with task_not_anomaly, and a closed one with task_closed: only an open anomaly-alert task satisfies this.

Write the body as plain paragraphs separated by a blank line. The user's own email app cannot carry a file, so Well adds each document's download link as the last paragraphs of the body, and the card shows them. The link does not expire: it stops when the document is deleted or printed again in place, or when the user asks to stop sharing it (well_revoke_document_shares). Never write that a file is attached ("Please find attached"); write for example "You can download the invoice here:" as the last line of your text, and the link follows it. Never write the link yourself. The user edits the draft on the card and presses "Send via your email app" there, which opens their email app with the message prefilled. Do not call well_send_email_draft yourself, and do not tell the user the email was sent until they say so.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Email a link to the person's own address, from Well's mail, so they can open it on a computer.

The recipient is never an input: the email goes to the verified address of the signed-in account, and only there. It sends at once and shows no card, because it writes only to the person's own address. Use it when the person asks to get the link by email ("email me this link", "envoie-moi le lien par mail").

kind and the value it needs:

• collect, extension_install, mcp_instructions: url, the Well link exactly as a tool result or the page gave it. A link outside the page the kind allows is refused.

• invoice_draft: invoice_id of a draft invoice. The email opens that draft in Well.

Returns sent: true with to_masked, the masked address, or error_reason: no_email (the account has no verified address), link_refused, forbidden, rate_limited or send_failed. On every refusal nothing was sent.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Queue invoice collection for named counterparties. This creates one durable backlog task per counterparty. The browser agent (a provider that carries a blueprint or a real portal URL) or the manual-upload route picks up each task later.

Call this tool only after the user explicitly confirms the launch. Never call it on your own initiative.

Get counterparty_company_ids from well_list_missing_invoices. This tool takes no period argument: a collection task belongs to a counterparty, not a month.

A repeat call for a counterparty that already has a non-terminal task reuses that task (already_active: true) instead of creating a second one.

provider.has_blueprint and provider.has_portal_url on an enqueued row state which counterparties a browser agent will visit (either one is enough), and which fall back to manual upload (neither).

Creating the tasks launches nothing in the browser. Inside Well the tasks page and the chat card start and track them. From outside Well, hand the user THIS result's collect_url to start the runs, never the collect_url of well_preview_invoice_fetch: this link carries the task each run answers, so the tasks follow the runs and well_wait_for_process can report each vendor. Give the link as returned and never edit it. It names every enqueued counterparty whose provider has a blueprint or a real portal URL, at most 25 portals; a counterparty past that ceiling appears in collect_url_omits instead of on the link. A counterparty with provider: null, or with neither has_blueprint nor has_portal_url, is routed to manual upload and is not on the link. collect_url is null when no enqueued counterparty can go on a link. Never tell the user the link covers a counterparty it does not name.

Use well_preview_invoice_fetch first to see what a fetch would cover — it is read-only and launches nothing. Use well_enqueue_close_invoice_fetch instead of this tool when you are inside a close run: it is the same action, scoped to that run's flow_run_id. Use this tool outside a close run.

Report the counts back to the user: how many tasks were enqueued, how many of those were already active, and how many counterparties were skipped, with each skip's reason.

Turn a table you built into a spreadsheet file (CSV) and return the link that downloads it. Use it for rows that are not Well records, such as one line per person read from a shared group chat or a pasted list. For Well records (transactions, invoices, companies), use the records export instead.

Pass columns, the headings in order, and rows, one array of cells per row with one cell per column. A null cell prints empty.

Nothing is saved to the workspace's records or memory. Anyone who holds the link can download the file, for 15 minutes and a few downloads: share it only with the person who asked.

Returns url, or refusal_reason: "not_a_member" (the caller is not an active member of this workspace), "too_large" (the table is over 512 KB) or "unavailable" (this deployment cannot serve files).

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Find when the user is free, or when the user and other workspace members are all free. Use it when the user asks when they are free, which slots are open, or when a meeting could fit. It reads the user's own synced calendars: every timed event that is not cancelled blocks its time, and all-day events do not. It returns the free slots between 09:00 and 18:00 in the user's time zone, or between the working_hours the user named. To find a time that suits workspace members too, pass their person ids in member_person_ids: it then returns only the slots where the user and every connected member are free, and a member's private meeting blocks time like any other. It never shows what anyone's events are, only the shared free slots: time outside a slot is busy and the reason is never given. A member whose calendar is not connected to Well is listed in members_not_connected and is not counted: tell the user that member's free time was not checked. Someone outside the workspace, such as a guest, cannot be checked: say so and do not guess when they are free. If truncated is true, some calendar events could not be read: tell the user the check is incomplete and give incomplete_check.message; never suggest a time after incomplete_check.checked_until. If capped_range is set, the range was longer than 31 days and only its first 31 days were searched: tell the user the range was shortened and to which date, and offer to search the rest; never suggest a time beyond searched_to_date. If the result has a note, give it to the user as it is: it invites them to connect their own calendar.

The result's connection describes the user's own calendar. Its state is one of "connected" (say nothing about it), "syncing" (the first sync has not finished: say the result can be incomplete), "stale" (say the result can be out of date and give last_synced_at as the time of the last update), "needs_reconnect" (say Well lost access to the calendar, that the result holds only what was synced before, and give reconnect_link once) or "not_connected" (say the user's own calendar is not connected and give reconnect_link once, unless the note already gave it). When the state is not "connected", never call the result complete or up to date, and never call a time free on its strength alone. A null connection means the state could not be read: say nothing about it.