softglaze-browser-mcp

Overview Schema Source Related Servers Discussions Admin

Update a profile

update_profile

Idempotent

Edits a browser profile’s name, group, tags, notes, start URL, proxy, and CAPTCHA-fix settings after user confirmation, without altering fingerprints, passwords, 2FA, or cookies.

Instructions

Changes a profile's name, group, tags (replaces the list), notes, start URL or proxy (proxyId, or null to remove it), and can apply CAPTCHA fixes: tz-auto, lang-auto, geo-auto (follow the proxy) and webrtc-safe. Asks the user first. Never changes the fingerprint, passwords, 2FA or cookies, and never deletes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "update_profile"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`name`	No
`tags`	No
`fixes`	No
`group`	No	Group id or name; null removes it from its group.
`notes`	No
`proxyId`	No
`startUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well past the annotations by disclosing semantic behaviors: tags are a wholesale replacement rather than a merge, proxyId accepts null to remove the proxy, the fixes follow the proxy when geo-auto is set, and the user is prompted before applying. The explicit never-changes list (fingerprint, passwords, 2FA, cookies) plus 'never deletes' reinforces the destructiveHint=false annotation with concrete boundaries.

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?

One front-loaded sentence names the mutable fields first, then tacks on the CAPTCHA-fix detail and the safety boundaries; every clause carries information. It is a long run-on that could be split into behavior and constraints, but there is essentially 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?

For an 8-parameter mutation tool with no output schema and thin schema descriptions, the definition covers field semantics, replacement-vs-merge behavior, removal semantics, and the safety envelope. Remaining gaps are minor: no mention of error behavior for an unresolved group name or of the confirmation flow's mechanics.

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?

With schema description coverage at only 13%, the description carries the param burden and does most of it: it maps name/group/tags/notes/startUrl/proxyId to their meaning, explains null-removal for proxy, and spells out the four enum values of fixes including that geo-auto follows the proxy. It does not mention that group accepts either an id or a name, nor the tag count/length constraints, so a small gap remains.

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 (changes) plus the exact set of mutable fields (name, group, tags, notes, start URL, proxy) and clarifies scope with an explicit negative list (fingerprint, passwords, 2FA, cookies, deletion). An agent can immediately tell this is a partial-update tool and not create_profile or assign_proxy.

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?

Usage is implied by the field enumeration and by 'Asks the user first', which signals a confirmation-gated path, but there is no explicit when-to-use versus when-not guidance. Notably absent is any routing against siblings that overlap (assign_proxy for proxy changes, move_profiles_to_group for grouping), leaving the agent to infer which tool to pick.

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