DoneOnce › Help › Your AI assistant in DoneOnce

Your AI assistant in DoneOnce

DoneOnce has an MCP server — the standard way an AI assistant (Claude, ChatGPT and others) plugs into an app. Once connected, you can ask your assistant things like "add the Garcias at 12 Oak St, biweekly on Tuesdays", "who is behind on payments?" or "send Ana the estimate for the pool cleaning", and it does the work inside your DoneOnce, as you.

It can do exactly what you can do in the app, and nothing more: a tech's assistant sees the day and the book, the office's sees the money. Anything that sends money or messages is described to you first and done only after your yes.

Connect Claude (claude.ai or the desktop app)

1. In Claude, open Customize → Connectors, press + and choose Add custom connector.
2. Name it DoneOnce and paste this URL: https://mcp.doneonce.app/mcp
3. Press Add, then Connect. A DoneOnce window opens: sign in with your DoneOnce email and password and press Approve.

That is all — no token to copy. Claude's Free plan allows one custom connector; paid plans more.

Connect Claude Code

In a terminal:

claude mcp add --transport http --scope user doneonce https://mcp.doneonce.app/mcp

Then type /mcp inside Claude Code, choose doneonce and sign in the same way.

Other assistants

Any assistant that supports remote MCP connectors with sign-in (OAuth) works with the same URL. A program that can only send a fixed header can use a token instead: in DoneOnce, Settings → Agents → How to connect → With a token, mint one, and send it as Authorization: Bearer <token>.

Staying in control

• Every connection lasts 90 days; then your assistant asks you to approve again.
• Settings → Agents lists every connection with when it was last used. Revoke ends one at once. Reconnecting the same assistant replaces its previous connection.
• If your role changes, your assistant's access changes with it on the very next request.

For the assistant reading this

• You act as the person who connected you, with their permissions; the server re-checks them on every call. A refusal is the server's own sentence — relay it, do not guess around it.
• Money is integer cents. A tool marked get a yes first changes money or sends something to a customer: say what you are about to do and wait for the person's yes.
• Setting up a new business, in this order: the business profile → zones (the ZIPs it serves and which weekday each one runs) → categories and the price list → clients, each with an address → their recurring services → the team. Use find_client before adding a client, so nobody is entered twice.
• A whole spreadsheet of clients goes in through the import below, never one add_client at a time. A team or a price list of several lines does go in one at a time (add_crew_member, add_price_list_item): show the person the whole list and ask for one yes.
• To check what landed: list_clients gives how many clients there are and each one's standing services (a client with no service has an empty list). One-off work with a start and an end — replace a pump, a deep clean — is add_job; list_jobs reads them.
• The last step is the week. Imported and new standing services start on nobody's route. week_plan shows each person's standing days and the queue, with a suggestion for each queued service from its zone (the zone's weekday and, if the zone has one, its person). Show the person the queue with the suggestions, get one yes, then place_service each one (its serviceId, the crew member, all the weekdays it runs). Read week_plan again and report the week. Give each person who drives a route their working days and workday minutes (update_crew_member) — the schedule measures each day against them.
• What is done in the app, not here: scheduling a job on a day, reordering a day's stops, and connecting Stripe (connect_onboarding_link gives the link; the person opens it). Tell the person so when you finish, with the concrete next step.

Bringing a whole client list (for the assistant)

The person hands you their spreadsheet — an export from Jobber, Housecall Pro, QuickBooks, Excel or Google Sheets. Two tools, always in this order:

1. import_book with the file as text, exactly as given, header row first. Never re-type, clean or summarize rows: the server reads the file with the same rules the app's Import CSV uses, and nothing is written yet. Name the columns only if the guess in the answer is wrong (mapping: name, street, zip required; phone, email, category, day, frequency, notes optional; null leaves one out). If the whole address sits in one column ("12 Oak St, Stuart, FL 34994"), leave it: with no ZIP column the server reads each ZIP off the end of the address (zipFromAddress: true in the answer) and refuses, with its reason, a row that has none.
2. Show the person the answer in plain words: how many become clients, how many get a weekly or every-other-week service and on which weekday (the zone that covers the ZIP decides it, then the file's day column), which rows are refused and why, which get no service and why, and the new categories. If a column was misread, fix mapping and preview again.
3. commit_import with the importId, only after their yes. Call it again while remaining is above 0 — it continues where it stopped and never writes a row twice. Then report the totals: created, services, duplicates, failed (each failure comes with its reason).

What lands: each client with its address as the primary one (gate codes and notes on the address), its category, and its standing service, unplaced — then week_plan and place_service put each one on a crew, as above (or the office does it from the week's queue in the app). Monthly and one-time services are left for the person to add in the service dialog; the preview names those rows. Set the zones up before the import if the business has them, so the weekdays come out right.