Skip to main content
Glama

Delete a saved login

browser_remove_login
Destructive

Deletes saved logins for a given origin, optionally limited to one username, and reports how many were removed so you can verify the result.

Instructions

Delete saved logins. Give origin and optionally username; with username omitted, every login for that origin is removed. Reports how many were removed so the result can be checked.

Input Schema

NameRequiredDescriptionDefault
originYesOrigin whose logins should be removed
usernameNoOnly remove this username (default: all for the origin)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, so the safety profile is covered; the description adds the important detail the annotations cannot convey — that omitting username escalates a targeted delete into a bulk removal of all logins for the origin. It also discloses that a removal count is returned. It does not state irreversibility or whether password data is recoverable, which keeps it at 4.

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?

Three short sentences, front-loaded with the action, then the parameters, then the return behavior. Nothing is padded and each sentence carries a distinct fact.

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?

With no output schema, the description usefully covers the return value (a removal count) and fully explains the destructive scope. For a two-parameter tool with annotations already flagging destructiveness, that is close to complete; only recovery/permission caveats are absent.

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 coverage is 100% and both parameters already carry descriptions including the 'default: all' behavior, so the description is largely restating the schema. It reinforces the omission semantics but adds no format or syntax guidance beyond that. Baseline 3 applies.

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 and resource ('Delete saved logins') that is unmistakably distinct from the sibling read/write login tools (browser_list_logins, browser_add_login, browser_get_login_password). It also clarifies the bulk-vs-single scope, which no sibling name implies. It stops short of naming an alternative tool, so it lands at 4 rather than 5.

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

Usage Guidelines4/5

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

Explains the key selection decision the agent faces: supply username to target one entry, omit it to wipe every login for the origin. That is real when-to-use guidance for the tool's main branching point. No exclusions or prerequisite steps (e.g. verifying with browser_list_logins first) are stated.

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