Skip to main content
Glama

Turn Global Privacy Control on or off

browser_set_gpc
Destructive

Enable or disable the Global Privacy Control signal so browser requests carry Sec-GPC: 1, or stop sending it.

Instructions

Enable or disable the Global Privacy Control signal (requests then carry Sec-GPC: 1). MEASURED: the parameter is { gpc: boolean }, not { value: boolean } — the latter is rejected with "Value of gpc should be of type boolean". Marionette-only, so Firefox must run with --marionette.

Input Schema

NameRequiredDescriptionDefault
gpcYestrue to send Sec-GPC, false to stop sending it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses the actual behavioral effect on outgoing requests and the environment prerequisite. It stops short of saying whether the setting persists across sessions or is per-profile only, which matters for a state-changing privacy toggle.

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 effect, then the parameter caveat, then the runtime prerequisite — a sensible order with no filler. The parameter-shape warning is slightly redundant against a schema that already names the key `gpc`, costing a bit of tightness.

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 a one-boolean-parameter tool with annotations and no output schema, the definition covers purpose, effect, and prerequisite adequately. Only the persistence/scope question and sibling routing are unaddressed.

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 the schema already documents `gpc` as 'true to send Sec-GPC, false to stop sending it'. The 'MEASURED' note reinforces the exact key name and the error text, which helps recovery from a malformed call, but adds little semantic meaning beyond the schema itself — baseline 3.

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 pair (enable/disable) and a concrete resource (the Global Privacy Control signal), plus the observable effect of the request header Sec-GPC: 1. It is clearly distinguishable from the sibling browser_get_gpc, which reads rather than sets the signal.

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?

The description gives a hard prerequisite (Marionette-only, Firefox must run with --marionette), which is genuinely useful usage guidance. However, it never says when to reach for this versus browser_get_gpc or the broader tracking-protection/pref tools, so the choice between siblings is left to inference.

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