Skip to main content
Glama

Start session

steel_session_create
Destructive

Create a cloud browser session configured with profile, proxy, viewport, or guest mode to automate form filling and screenshots, with human handoff for logins and CAPTCHAs.

Instructions

Billed; profiles/credentials via session_options; release.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
guestNoFresh browser; skip profiles.
deviceNoClass.
viewportNoPixels.
block_adsNoAds.
namespaceNoName; not secret.
use_proxyNoProxy.
profile_idNoUUID; not secret.
timeout_msNoLifetime ms.
configurationNoPlan token.
solve_captchaNoCAPTCHA.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.0

TDQS

C2.8/5.0
Behavior4/5

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

With only openWorldHint/destructiveHint annotations, the description adds meaningful behavioral context: the operation is billed, and the created session must be released, which suggests a chargeable, long-lived resource. It doesn't go into consequences, but it reveals cost and lifecycle beyond the annotations.

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

Conciseness2/5

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

The definition is extremely short, but it is under-specified rather than economically structured; the fragments are not front-loaded with the core purpose and read as disconnected warnings rather than a purposeful summary.

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 10-parameter, billed, destructive-flagged creator with no output schema, the description omits crucial context: what the call returns (e.g., session id), how billing is triggered, what 'release' implies, and any setup prerequisites. The cost/lifecycle hints are useful but far from complete.

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 description coverage is 100%, so the schema already documents all 10 parameters. The prose description adds no parameter-level detail; 'profiles/credentials via session_options' is a routing hint, not semantics for any specific parameter. Baseline 3 is appropriate.

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

Purpose2/5

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

The description never states the core action; it is a fragment list ('Billed; profiles/credentials via session_options; release.') that forces the agent to infer 'create session' from the name/title. It also doesn't differentiate this creator from siblings like steel_session_live_view beyond the title.

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 fragments imply some usage boundaries: credentials/profiles should go through steel_session_options, and the caller should later release the session. However, there is no explicit when-to-use, prerequisites, or exclusion guidance for the other sibling tools.

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