doola

Canonical 'where am I?' entry point — call this ONCE per user session, at the start, right after the OAuth handshake. No arguments required; customerId is read from the bearer. The response's `suggestedNextStep` (the tool to call next) and `nextActionInput` (a {tool, arguments} template: call that tool and replace every <placeholder> in `arguments` with the user's real answer) drive the next call. DO NOT call this before every formation call. Each formation tool's response already carries nextAction + nextActionInput — trust that and move on. Re-calling get_company_onboarding_status between steps just adds latency and burns rate limit without changing the plan. Only call this AGAIN when one of these is true: (a) the user returns mid-flow after a long pause and asks 'where are we?', (b) you need to verify state after an unexpected error or a failed call, or (c) the user switched companies via switch_active_company. Outside those cases, treat the first call's state as authoritative for the rest of the session. Derivation mirrors /web's onboarding routing (Company.gql): each step is marked completed when its corresponding Company / Customer field is populated. If the customer has no active company yet (post-OAuth, pre-formation), the response points at start_formation. If the response contains `error: true` or `suggestedNextStep` looks inconsistent with the user's actual progress (e.g. you just saved the company name but the response steers you back to it), the upstream data fetch likely transiently failed. Wait ~10 seconds and call this tool again before deciding what to do next — do NOT redo earlier steps the user has already completed.

get_company_onboarding_status

Accepts doola's Terms of Service (https://www.doola.com/terms-of-service) for the Starter package on the user's behalf and creates the Stripe checkout for the formation. Show the user doola's Terms of Service (https://www.doola.com/terms-of-service) and ask whether they agree. Only once they say yes, call create_checkout_session with {termsAccepted: true}. Returns `pricing` (the first-year list price: quote `pricing.summary` VERBATIM and never call it 'charged today'), `chargeSummary` (what Stripe charges today after any discount: quote it VERBATIM), `checkoutUrl` (paste it verbatim into your reply, never a placeholder), `checkoutSessionId` (keep it for verify_payment), and `companyId` / `companyName` (the company being paid for: name it to the user). Refused with PRECONDITIONS_NOT_MET until start_formation has saved the name, country and company name.

create_checkout_session

Returns the active company's full profile — basic info (name, state, entity type, EIN, industry, dashboard status, formation filing date), member list, responsible party, addresses, name options, and provisioned services. Mirrors what the customer sees on /web's Company Information page (https://app.doola.com/company). Use when the customer asks 'tell me about my company', 'what's my EIN?', 'who are the members?', or similar — distinct from `get_company_onboarding_status` which returns derived next-step routing rather than raw company data. To inspect a different company, call `switch_active_company` first.

get_company_info

Returns every company the authenticated customer owns — call when the user asks 'which companies do I have?', wants to switch context, or before starting a brand-new formation so you know whether a previous attempt is already in progress. The entry with `isActive: true` is the one every other formation tool currently operates on; call `switch_active_company` to point at a different one. To create a new in-progress company, call `start_new_company`.

list_companies

Call this when the user wants something none of the other tools can do. Describe the goal and the kind of tool that would help in `context`. Doing so records the request for doola's team and changes nothing on the customer's account. It returns no new tools, so after calling it tell the user this isn't available here and point them to the doola dashboard.

report_missing_capability

Saves the company's post-payment details: industry and description, backup names, registered and mailing addresses, the IRS responsible party, and either an LLC's members with their ownership or a C-Corp's officers, directors and share structure. Every field is optional and is saved as given, so save each answer as soon as the user gives it; the response lists what is still `missing` and its nextAction / nextActionInput name the next step. Refused with PRECONDITIONS_NOT_MET until verify_payment has confirmed payment.

save_company_details

Lists the industries a company can be filed under. Match the user's description of their business against the list, offer the 3-5 closest entries, and pass the one they pick, verbatim, as `industry` to save_company_details. Read-only; takes no arguments.

search_industries

Starts the user's LLC or C-Corp formation: saves their legal name (only when the profile lacks it), their country of residence, the company name, and the formation state and entity type. Every field is optional and is saved as given, so call it as soon as you have an answer. state and entityType default to a Wyoming LLC, so call it with {} when the user has no preference. Never invent a company name. The response's nextAction and nextActionInput name the next step.

start_formation

Begin a brand-new company formation alongside any existing companies the customer already has — call when the customer explicitly asks to form a SECOND (or further) company. Creates an empty in-progress Company row, links it to the customer, and pins it as the active company so the next tool calls operate on it. After this, follow the standard formation flow from its first step; the response names it. The previously active company is untouched and remains in `list_companies` — the customer can switch back via `switch_active_company`.

start_new_company

Files the company with its formation state through doola's registered agent and emails the SS-4 and Form 8821 to the responsible party for signing. Filing cannot be undone. Call it ONLY after presenting a complete summary table of everything collected and the user explicitly replied 'submit', with {userConfirmed: true}. Refused with PRECONDITIONS_NOT_MET, listing `missing`, while any earlier step is incomplete.

submit_formation