doola

Drives the doola Wyoming-LLC formation flow one step at a time. Pick the `action` to perform (see enum) and pass the matching `params` object. The server enforces step order via precondition gates and steers you to the right next action via `nextAction` + `nextActionInput` on every response — follow those verbatim. If you're not sure which action to call (resume mid-flow, recovery after an error), call get_company_onboarding_status first; its `nextActionInput` is the literal payload to pass back here. Pre-payment actions (in order): - set_country_of_residence — params: {countryCode: ISO 3166-1 Alpha-3, e.g. 'USA', 'GBR', 'IND'} - set_company_name — params: {name: <desired company name without LLC suffix>}. ONE-TIME initial capture; re-calling overwrites and wipes alternates. Add backup names via add_alternate_company_names after payment. - set_company_state — params: {} (Wyoming is enforced). - select_package — params: {} (Starter is enforced; live pricing returned in `pricing` — quote `pricing.dueAtCheckout`, `pricing.recurringAnnually`, and `pricing.summary` VERBATIM. Heading MUST read 'Charged today: $X' or 'First-year total: $X'. Do NOT write 'one-time formation fee: $X' as the heading — `dueAtCheckout` includes the recurring Starter subscription, which is NOT one-time. Do NOT sum the breakdown yourself, do NOT invent a separate renewal number). - create_checkout_session — params: {}. Returns a Stripe checkoutUrl — paste it verbatim into your reply. - verify_payment — params: {checkoutSessionId: <from create_checkout_session response>}. Only call after the user says they've paid. Post-payment actions: - search_industry — params: {}. Read-only lookup. Returns the verbatim industry list to fuzzy-match the user's description against; pick a verbatim entry, then call set_industry_description. - set_industry_description — params: {industry: <verbatim from search_industry list>, description: <1-2 sentence business summary>, sellingPlatform?: <Amazon|Shopify|...>}. - add_alternate_company_names — params: {name1: <existing primary, do not re-ask>, name2?: <optional backup>, name3?: <optional backup>}. Each gets 'LLC' suffix. - set_registered_address — params: {useRegisteredAgent: <true|false>, line1?, city?, state?, postalCode? (only if useRegisteredAgent=false; must be Wyoming)}. - set_mailing_address — params: {sameAsRegistered: <true|false>, line1?, city?, state?, postalCode? (only if sameAsRegistered=false; must be US)}. - add_members — params: {members: [{legalFirstName, legalLastName, isNaturalPerson, phone, line1, city, state, postalCode, country (ISO Alpha-3)}, ...]}. Pass members as a NATIVE JSON array — do NOT stringify. - set_responsible_party — params: {legalFirstName, legalLastName, email (CONFIRM with user before sending; SS-4 + Form 8821 go here), phone, line1, line2?, city, state, postalCode}. - set_ownership — params: {members: [{<full add_members payload> + ownershipPercent}, ...]}. FULL-RECORD REPLACE — must re-pass every member field. Percentages must total exactly 100%. - submit_for_review — params: {userConfirmed: true}. ONLY after presenting a complete summary table and the user explicitly replied 'submit'. Server gates filing on every prerequisite — listen to `missing` + `nextActionInput` on failures.

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.

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` (action name) and `nextActionInput` (literal payload) drive the next call to advance_company_onboarding. DO NOT call this before every advance_company_onboarding call. Each advance_company_onboarding response already carries nextAction + nextActionInput — trust that and move on. Re-calling get_company_onboarding_status between actions 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 signals action=set_country_of_residence as the next call. If the response contains `error: true` or `suggestedNextStep` looks inconsistent with the user's actual progress (e.g. you just successfully advanced past set_company_name but the response steers you back to it), the upstream GraphQL 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.

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`.

Begin a brand-new Wyoming LLC 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 starting at `set_country_of_residence`. The previously active company is untouched and remains in `list_companies` — the customer can switch back via `switch_active_company`.

Point the formation tools at a different company the customer already owns. Use when the customer asks to manage / continue / inspect a specific company by name or ID. The companyId must come from `list_companies` — unknown IDs are rejected. After switching, the response carries the same shape as `get_company_onboarding_status` for the new active company, so the agent knows immediately which step to resume from. The override is process-local; if the customer reconnects and ends up on a different MCP replica, just call this tool again.