Skip to main content
Glama

start_account_workspace

Launch an isolated browser workspace for one account without starting a course or exam, so you can inspect or manage that account session separately.

Instructions

Launch one isolated account browser without starting any course or exam.

Input Schema

NameRequiredDescriptionDefault
account_idYes
browser_modeNominimized

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.9.4

TDQS

B3.1/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden; it does add the meaningful trait that the browser is 'isolated' and that no course/exam session is started. It says nothing about lifecycle (does it persist until close_account_workspace?), permissions, failure modes, or what is returned, leaving significant behavioral gaps.

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?

A single front-loaded sentence with the key constraint ('without starting any course or exam') placed immediately after the action. No filler, though the brevity comes partly at the cost of missing detail.

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

Completeness2/5

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

For a tool with zero annotation coverage, no output schema, and 0% parameter documentation, the description is too thin: browser_mode semantics, lifecycle/cleanup relationship to close_account_workspace, and whether a course browser must be attached later are all unaddressed.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate and does not: account_id and browser_mode are never explained. In particular, browser_mode's default 'minimized' hints at a set of allowed modes, but no values or effects are described.

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

Purpose4/5

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

States a specific verb ('Launch') and resource ('isolated account browser') plus a scope exclusion ('without starting any course or exam'), which separates it from start_course_browser and open_course_exam. However, it does not address the nearby sibling open_account_browser or attach_course_browser, so differentiation is only partial.

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

Usage Guidelines3/5

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

The exclusion clause implies the intended context (bare browser, no learning task), but no alternative is named and no precondition (e.g., account must be logged in) is stated. Usage is implied rather than routed.

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

Deploy Server

Other Tools