Capable

Finalize workspace setup

finalize_workspace_setup

DestructiveIdempotent

Commit onboarding answers into the workspace config; omitted fields stay untouched. active_motions records the confirmed motion choice and applies each motion's template; feature_templates applies standalone add-on templates (opted into during the interview) after the motion templates — an unknown feature key is skipped and named, never a failure; answers records checklist items without a dedicated field. Returns the updated workspace.

When to use: Call at the end of the interview once the user has confirmed the choices. Records the confirmed motion(s), applies their starter templates, and commits the answers — anything omitted keeps its default.

Example: Looks good — save those settings.

Input Schema

Name	Required	Description
`name`	No	The workspace's display name — answers the checklist's name item; until set it reads "<sign-up email domain> workspace".
`answers`	No	Answers to checklist items with no dedicated field, keyed by the checklist key (e.g. quoting_catalog); merged into the saved onboarding answers.
`framework`	No	Qualification framework whose fields are filled on opportunities; passing the current default (spiced) records it as a chosen answer.
`template_key`	No	Key of one extra starter template to apply beyond the chosen motions, from start_onboarding's available_templates; an unknown key is refused.
`active_motions`	No	The confirmed motion key(s) from start_onboarding's available_motions — saved as the workspace's active motions, each applying its matching template.
`pipeline_stages`	No	The default pipeline's stages, in order (which stages exist and their labels). An existing key keeps its role and entry requirements; an omitted is_closed / is_won keeps its stored value unless the flag you do send contradicts it.
`framework_custom`	No	Custom framework definition for framework 'custom', shaped {fields:[{key,label}]} — each key becomes a qualification field on opportunities.
`feature_templates`	No	Keys of standalone add-on templates opted into during the interview (e.g. quoting), applied after the motion templates; unknown keys are skipped and named, never refused.
`expected_active_motions`	No	Guard against saving over a newer choice: the active_motions you last read (state.active_motions from start_onboarding or show_workspace_setup; null when none). If the saved motions differ, nothing is saved and the result returns updated:false with the current motions.

Output Schema

Name	Required	Description
`updated`	No
`guidance`	No
`workspace`	No	The workspace's state — the same shape start_onboarding returns as `state`.
`workspace_url`	No
`active_motions`	No
`applied_template`	No
`applied_templates`	No
`skipped_feature_templates`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```

Changed9 schema fields changedOct 19, 2026

removedOutput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / additionalProperties
```
Removed value: -{}
```
removedOutput schema / properties / applied_template / additionalProperties
```
Removed value: -false
```
removedOutput schema / properties / applied_template / properties / applied / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
removedOutput schema / properties / applied_templates / items / additionalProperties
```
Removed value: -false
```
removedOutput schema / properties / applied_templates / items / properties / applied / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
removedOutput schema / properties / workspace / additionalProperties
```
Removed value: -{}
```

addedOutput schema / properties / workspace / description

Added value: +"The workspace's state — the same shape start_onboarding returns as `state`."

removedOutput schema / properties / workspace / properties

Removed value: -{
-  "framework": {
-    "anyOf": [
-      {
-        "type": "string"
-      },
-      {
-        "type": "null"
-      }
-    ]
-  },
-  "id": {
-    "format": "uuid",
-    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
-    "type": "string"
-  },
-  "name": {
-    "anyOf": [
-      {
-        "type": "string"
-      },
-      {
-        "type": "null"
-      }
-    ]
-  },
-  "pipeline_stages": {
-    "items": {},
-    "type": "array"
-  }
-}

Changed2 schema fields changedOct 19, 2026

changedInput schema / properties / expected_active_motions / description

Previous value: -"Optional guard against saving over a newer choice: the active_motions you last read (state.active_motions from start_onboarding or show_workspace_setup; null when none was confirmed). If the saved motions no longer match, nothing is saved and the result returns updated:false with the current motions and workspace."New value: +"Guard against saving over a newer choice: the active_motions you last read (state.active_motions from start_onboarding or show_workspace_setup; null when none). If the saved motions differ, nothing is saved and the result returns updated:false with the current motions."

changedInput schema / properties / pipeline_stages / description

Previous value: -"The default pipeline's stages, in order: the list sets which stages exist and their labels. A stage whose key already exists keeps its role and entry requirements, and an omitted is_closed / is_won keeps its stored value unless the flag you do send contradicts it."New value: +"The default pipeline's stages, in order (which stages exist and their labels). An existing key keeps its role and entry requirements; an omitted is_closed / is_won keeps its stored value unless the flag you do send contradicts it."

First observedOct 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds genuinely non-obvious behavior: omitted fields stay untouched, unknown feature keys are skipped-and-named (never a failure), while an unknown template_key is refused, and expected_active_motions acts as a concurrency guard returning updated:false. It stops short of explaining what gets destroyed or auth requirements, so not a 5.

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-loads the core action, then behavior, then when-to-use and an example. Dense but each block earns its place; slightly long for a config-commit tool.

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

Completeness4/5

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

With 9 params, nested objects, an output schema (return values need not be explained), and annotations covering safety, the description supplies the key behavioral context an agent needs. Remaining gaps are minor edge cases rather than blockers.

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 description coverage is 100%, so 3 is the baseline. The description exceeds it by disclosing ordering semantics (feature templates applied after motion templates) and the skip-vs-refuse distinction that the schema alone does not spell out.

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 — "Commit onboarding answers into the workspace config" — and immediately clarifies per-field behavior (active_motions, feature_templates, answers). This lets an agent distinguish it from siblings like update_workspace or show_workspace_setup without opening either schema.

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?

"When to use: Call at the end of the interview once the user has confirmed the choices" gives an explicit trigger condition. It does not name alternative siblings (e.g. update_workspace for later edits), so routing is clear but not fully contrastive.

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

All Capable 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.

Resources

Need Help?