dialogbrain

browser_create_identity

Create a browser identity for a website the person must sign in to (or sign up on) themselves, and get back a link to give them. Opening the link shows a live browser on the site; when they have signed in they press 'I'm logged in, save session' and the identity becomes active, after which browser.open / browser.attach_identity work with it. Use browser.handoff instead for an identity that already exists and is active. For a plain username + password sign-in form WITHOUT captcha or 2FA, pass username, password and confirm_sign_in_stored=true and the platform signs in itself (admin or owner only): the answer is status 'active' on success, or the reason plus the human link when the site wanted more (a captcha, a code). When the site refuses the username or password, an identity created by this call is deleted again (status 'deleted'); one that already existed is left as it was. The password is kept encrypted in the workspace's secret store and used to sign in again when the session expires.

Input Schema

Name	Required	Description
`url`	No	The first page the person lands on, e.g. a signup page. Must be on the same domain as origin. Omit to start on the origin.
`name`	Yes	Name for the identity, unique in the workspace (e.g. 'stripe_main'). A pending identity of the same name is resumed.
`origin`	Yes	The site the identity is for, an https address (e.g. https://dashboard.example.com).
`password`	No	The site's own password for username. Stored encrypted, never returned or logged.
`username`	No	The site's own login (email or username). With password, the platform signs the identity in itself instead of waiting for a person. Admin or owner only.
`in_workspace`	No	Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
`confirm_sign_in_stored`	No	Required true with username and password: the an admin or the owner of the workspace confirms that the platform stores this sign-in encrypted, types it into the site's login form in its own browser and keeps the session (the disclosure a person accepts in the sign-in window). Journalled. OMIT when not signing in.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 28, 2026

addedInput schema / properties / confirm_sign_in_stored

Added value: +{
+  "description": "Required true with username and password: the an admin or the owner of the workspace confirms that the platform stores this sign-in encrypted, types it into the site's login form in its own browser and keeps the session (the disclosure a person accepts in the sign-in window). Journalled. OMIT when not signing in.",
+  "type": "boolean"
+}

addedInput schema / properties / password

Added value: +{
+  "description": "The site's own password for username. Stored encrypted, never returned or logged.",
+  "type": "string"
+}

addedInput schema / properties / username

Added value: +{
+  "description": "The site's own login (email or username). With password, the platform signs the identity in itself instead of waiting for a person. Admin or owner only.",
+  "type": "string"
+}

AddedOct 26, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Well beyond what the annotations carry: it discloses the pending→active lifecycle gated on the person pressing 'I'm logged in, save session', the permission restriction (admin or owner only), encrypted password storage in the workspace secret store plus reuse on session expiry, and precise failure semantics (status 'active', or reason + human link; identity deleted on rejected credentials, pre-existing identity left untouched). Only the concurrency/journaling aspects covered by the schema description are left out; a 5 would need the return shape or timing/cost behavior.

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 the core action and the returned link, then the alternative, then the automated path. Every sentence carries information, though the block is dense and the 'status active / reason plus human link' clause is packed in a way that takes a second read.

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?

No output schema exists, so the description carries the return contract itself, and it does: a link, status 'active' on success, 'deleted' on credential rejection, or the failure reason plus human link. For a 7-parameter, stateful, permission-gated tool this is complete enough to call correctly on the first try.

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%, so baseline is 3, but the description adds real cross-parameter semantics the schema cannot: username + password + confirm_sign_in_stored=true triggers platform-side sign-in, and omitting confirm_sign_in_stored means wait for a human. It also ties the outcome to that mode (status 'active' vs human link).

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+resource (create a browser identity for a site), the artifact returned (a link to give the person), and the downstream state transition (identity becomes active). It explicitly distinguishes itself from browser.handoff (existing/active identities) and browser.attach_identity/browser.open, so an agent can route 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 a clear when-to-use condition (site the person must sign in to themselves), an explicit alternative with its selecting condition (browser.handoff for an identity that already exists and is active), and a fully specified alternate mode (plain user/password form without captcha or 2FA, admin/owner only). Exclusions are spelled out, not implied.

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

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

browser_create_identity

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources