Skip to main content
Glama
Sign In
svipall

svipall

by ilien-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

browser_setup

Manage the underlying browser for web fetching: check status, install Chrome for Testing, update, or remove it. Use when a fetch reports no usable browser.

Instructions

Manage the browser behind the browser, stealth, real and warm tiers. status (default) says which binary would run and why; install downloads Chrome for Testing (about 190 MB) when the machine has none; update replaces it with current stable; remove deletes it. Use when a fetch or web_status reports no usable browser. Nothing is downloaded unless asked.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
actionNostatus (default) | install | update | remove.
artifactNochrome (default, supports the headful real/warm tiers) | chrome-headless-shell (smaller, but cannot run headful and is more detectable).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.3

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true, so mutation and network access are already flagged. The description adds real value on top: the ~190 MB download cost, the default action (status), and the safety promise 'Nothing is downloaded unless asked' — behavior the annotations cannot express.

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 action enumeration, then the trigger condition, then the safety note — a logical order with no filler sentences. The opening 'browser behind the browser, stealth, real and warm tiers' is mildly jargon-heavy, keeping it just under a 5.

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 only two fully documented parameters, no output schema, and minimal annotations, the description carries the burden well: it covers all four actions, sizes, defaults, and when to invoke. It does not describe the shape of the status output, but that is a minor gap for a setup tool.

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, but the description goes beyond the schema's one-line summaries by explaining what each action does (status explains 'why', install downloads Chrome for Testing, update moves to current stable, remove deletes). That meaningfully enriches the action parameter.

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?

It names the resource (the browser binary behind the fetch stack) and enumerates each verb explicitly: status reports which binary would run, install/update/remove act on it. An agent can distinguish this management tool from the runtime siblings browser_open/browser_do without opening any schema.

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?

The trigger is explicit: 'Use when a fetch or web_status reports no usable browser.' This names the alternative signal that should route the agent here. It lacks an explicit negative case (e.g., don't call when a browser already works), so it stops short of a 5.

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