doola

Switch Active Company

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.

Input Schema

Name	Required	Description
`context`	No	Optional, for analytics only. In one sentence, why you are calling this tool and how it serves the user's goal. Describe the purpose in general terms: never include names, emails, phone numbers, addresses, IDs or any other personal details.
`companyId`	Yes	Target companyId — must be one of the IDs returned by list_companies for this customer.
`llm_model`	No	Optional, for analytics only. Your exact model identifier from your system prompt (e.g. "claude-opus-4-8"), or "unknown" if unsure. Never guess.

Output Schema

Name	Required	Description
`email`	No	Customer email
`error`	No	true if an error occurred
`message`	No	Human-readable status or instruction
`blockers`	No	Prerequisites still unmet, in flow order. Same vocabulary as the `missing` array submit_for_review returns. Empty array when formation is fully complete.
`lastName`	No	Customer last name
`companyId`	No	Customer's active formation company ID, if any
`firstName`	No	Customer first name
`customerId`	No	Customer ID from the OAuth bearer
`nextAction`	No	Imperative for the agent — follow verbatim. Null when formation is complete.
`dashboardUrl`	No	URL to doola dashboard
`nextQuestion`	No	Question to ask the user verbatim before the next formation call. Null when no question is needed.
`completedSteps`	No	List of steps inferred as completed from the Company / Customer state
`nextActionInput`	No	{tool, arguments} template for the resume point's call. Replace every <placeholder> in arguments with the user's real answer. Null when formation is complete.
`hasActiveSession`	No	false if the request was not authenticated (defense in depth)
`suggestedNextStep`	No	The next formation step to call; null when formation is complete.
`countryOfResidence`	No	ISO Alpha-3 country code if set

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnly=false, destructive=false, openWorld=false) by disclosing that the switch is a process-local override, that it may be lost on a different MCP replica and should simply be re-invoked, and that unknown IDs are rejected. It also tells the agent the response mirrors get_company_onboarding_status, which is exactly the context a mutating tool needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the action and the trigger condition, then the ID constraint, then the return-shape and replica caveats. Every sentence carries information an agent needs at decision time.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, and the description still explains that the response matches get_company_onboarding_status, telling the agent how to use the result to resume onboarding. Prerequisite sourcing, error behavior, and state lifetime are all covered for this stateful switch operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline applies; the companyId constraint is already documented in the schema. The description repeats the list_companies provenance rule and adds the consequence ('unknown IDs are rejected'), which is useful but only marginally beyond the schema, and it says nothing about the analytics-only fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb ('point the formation tools at') and resource ('a different company the customer already owns'), making the scope of the change unambiguous. It is clearly distinct from siblings like list_companies (discovery) and get_company_onboarding_status (status read).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use it when the customer asks to manage/continue/inspect a specific company by name or ID, and routes to list_companies as the required source of IDs. It also covers the reconnect/replica retry case, though it never states when not to use it (e.g., when the company is already active).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All doola tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.