Skip to main content
Glama

web_login

Opens a visible browser window so a person can log in or pass a challenge manually, then saves cookies to a profile for later fetches.

Instructions

Open a visible browser window so a person can log in or pass a challenge by hand, then save the cookies to a profile. Use when a fetch returns blocked_reason naming a login wall or a challenge no automatic tier clears. Without profile the domain's auto profile is used and later fetches pick it up on their own; name a profile to reuse it explicitly. Move it to another machine with web_profile.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe page to open in the visible window: the login form, or the blocked page itself.
profileNoProfile to save the cookies under. Default: the domain's auto profile, which later fetches use on their own.
timeout_sNoSeconds to wait for the person to finish; closing the window finishes early. Default 300.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the mutation nature is known. The description adds substantial context beyond that: the window is visible, a human must act, behavior on profile omission (domain auto profile that later fetches pick up automatically), and reuse semantics. It doesn't state what happens if the timeout elapses without success, but that is a minor gap.

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

Conciseness5/5

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

Front-loaded with the action, then the triggering condition, then the profile nuances and the sibling pointer. Every sentence carries information; no filler.

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?

No output schema exists, and the description does explain the key side effect (cookies saved to a profile, later fetches reuse them). For a 3-param human-in-the-loop tool with annotations covering the safety profile, only the failure/timeout outcome is left implicit.

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 all three parameters are documented in the schema itself, and the description's notes on `profile` (auto profile vs. named reuse) largely restate it. It adds the cross-fetch consequence that later fetches pick the profile up automatically, but that is marginal over 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+resource (open a visible browser window) and the outcome (save cookies to a profile), which is clearly distinguishable from the solve_* captcha siblings and browser_open. An agent can tell this is the human-in-the-loop fallback rather than an automatic solver.

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?

Explicitly names the trigger condition: use when a fetch returns `blocked_reason` naming a login wall or a challenge no automatic tier clears, which routes the agent after the solve_* tools have failed. It also names web_profile as the tool for moving the profile to another machine.

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