Skip to main content
Glama

scout_login

Open a visible browser window for the user to sign in as a role and save that session for later attach calls. Use when attach is refused because no valid sign-in is saved.

Instructions

Open a visible browser window for the USER to sign in to the app as a role, and save that sign-in for scout_attach { role }. Use it when an attach is refused because no sign-in is saved for the role, or the saved one has expired. Tell the user first, in plain words: "A browser window is opening. Sign in there as you normally would; it closes by itself once you are in." The window saves once the user is back on the app with a new session (a round trip through a single sign-on provider is followed, not taken for the end) and closes. Never type credentials into it yourself. Returns once signed in and saved, or after waitSeconds with the window still open: then call scout_login again with the same role to keep waiting. Closing the window saves nothing. Needs a desktop: on a machine with no display, ask the user to run scenescout login <url> --role <name> where they can see the window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesWhere to sign in: the app's address or its sign-in page, e.g. http://localhost:3000/login
roleYesThe name to save the sign-in under, e.g. admin; scout_attach { role } signs in with it
browserNoBrowser to open. Default: the SCENESCOUT_BROWSER environment variable, else chromium
successUrlNoOnly when the user says how to tell: signed in once the URL's path contains this, or the URL starts with it (an absolute URL), instead of when a new session appears
projectPathNoAbsolute path to the project (the sign-in is saved in .scenescout/auth/ here), as for scout_attach. Omitted: the same folder an attach with no projectPath uses for this site, which the result names.
waitSecondsNoHow long this call waits for the user before returning with the window still open (default 120)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.17.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does: window is visible and closes itself, credentials must never be typed by the agent, a round trip through SSO is followed, closing the window saves nothing, the call returns after waitSeconds with the window still open and must be re-called to keep waiting, and a display is required. This is unusually rich disclosure of side effects, failure modes, and interaction contract.

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?

Purpose and trigger are front-loaded, and every sentence carries operational content (user-facing message text, save semantics, retry loop, headless fallback). It is long for a tool description, but the length is justified by the complexity; only slight trimming would be possible.

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?

With no annotations and no output schema, the description still covers return conditions, timeout behavior, save semantics, prerequisites (desktop/display), and the fallback procedure. Nothing an agent needs to invoke this correctly appears to be 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%, so the baseline is 3; the description goes beyond it by explaining the waitSeconds re-invocation loop (call scout_login again with the same role), the persistence semantics of role, and the projectPath default behavior. It adds real meaning rather than restating the schema.

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 (open a visible browser window for the user to sign in) plus the exact downstream artifact it produces (a saved sign-in for scout_attach { role }). An agent can distinguish this from scout_attach, scout_run_plan, and every other scout_* tool 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 an explicit trigger ('Use it when an attach is refused because no sign-in is saved for the role, or the saved one has expired'), names the related tool scout_attach, and provides an alternative path for headless machines (ask the user to run `scenescout login <url> --role <name>`).

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