advance_company_onboarding
ChatGPTDrives 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.
advance_company_onboarding
ChatGPTDrives 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.
get_company_info
ChatGPTReturns 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
ChatGPTReturns 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_onboarding_status
ChatGPTCanonical '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.
get_company_onboarding_status
ChatGPTCanonical '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.
list_companies
ChatGPTReturns 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
ChatGPTReturns 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.
start_new_company
ChatGPTBegin 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.
start_new_company
ChatGPTBegin 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.
switch_active_company
ChatGPTPoint 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.
switch_active_company
ChatGPTPoint 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.
