Perspective AI

onboarding_start

Sets up a new account from inside the agent. Use it when another tool reports that the user's account is not set up yet.

Behavior:

Call it with no arguments first. It returns status "options" with where the user can go: join a workspace they were invited to, join a team found by their email domain (automatic, or by request to its admins), or start their own. Ask the user which they want. When there is nothing to choose (no invite, no team), it skips straight to status "start".
Call it again with action "create", or action "join" plus the workspace_id of one option. It returns status "start" with a perspective_id: take the getting-started conversation as the user with perspective_participate (action "start" with that perspective_id, then "respond" to each question). Answer from what you know about the user and ask them what you don't. When the conversation is complete, call this tool again to confirm the account is set up, then retry the tool you were using.
Joining by request returns status "requested": the team's admins get an email and the user is emailed when approved. Suggest the user start their own workspace meanwhile (action "create") so they can use Perspective while they wait; the team workspace is added to their workspaces on approval. If they wait instead, calling this tool after approval offers that workspace as an invite.
Returns status "browser" with only a browser_url when this server's onboarding conversation cannot finish the setup by itself: give the user the link and wait for them to finish there.
Returns status "onboarded" when the user already finished setting up. On a workspace-scoped connection, only workspaces in its scope the user was invited to are offered; with none, it returns status "unavailable".
Right after a getting-started conversation ends, the tool waits for its setup to finish before answering, so calling it again (or retrying the original tool) then is safe. If setup is still running after that wait, it returns status "pending": call it again in a few seconds and do not start another conversation.

When NOT to use this tool:

The user's account is already set up — use workspace_get_default.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "onboarding_start"
  }
}

Input Schema

Name	Required	Description	Default
`action`	No	Omit to list the options. 'create' starts the user's own workspace; 'join' joins the workspace named by workspace_id.
`workspace_id`	No	With action 'join': the workspace_id of the chosen option.

Output Schema

Name	Required	Description	Default
`status`	Yes
`message`	Yes
`options`	No
`browser_url`	No
`perspective_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026
- addedInput schema / properties / workspace_id / maxLength
```
Added value: +128
```
AddedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description goes well beyond them: it discloses the status machine (options/start/requested/browser/onboarded/unavailable/pending), the email-and-approval side effect, the waiting behavior after a conversation, and a safe-retry guarantee. This is exactly the mutation/async context annotations cannot express.

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

Conciseness4/5

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

Front-loaded with purpose and trigger, then organized under a 'Behavior' bullet list and a 'When NOT to use' header. It is long, but the density is warranted by a multi-state onboarding flow; a few bullets (e.g., the requested/browser edge cases) could be trimmed without loss.

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?

For a stateful, multi-step onboarding tool this covers the full lifecycle an agent must navigate: initial probing, branching, waiting, failure-to-browser fallback, and completion detection. An output schema exists, yet the status enumeration is still useful for control flow, and nothing needed to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100% and the enum is already documented, so the schema carries the baseline. The description adds value by explaining the ordering and conditional relationship between calls (no args lists options; 'join' requires workspace_id from an offered option), which the schema alone leaves implicit. It doesn't add syntax detail beyond that.

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 specific verb and resource ('Sets up a new account from inside the agent') and explicitly ties invocation to a trigger condition ('when another tool reports that the user's account is not set up yet'). It also names the sibling it is not (workspace_get_default) and enumerates the internal statuses, so an agent can distinguish this from workspace_list/workspace_get without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (trigger from another tool's error), a full step-by-step flow including call-with-no-args first, and a dedicated 'When NOT to use' block naming the alternative (workspace_get_default) for already-set-up accounts. Alternatives and exclusions are both covered.

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

All Perspective AI 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.