Skip to main content
Glama
Sign In
CDPM

CDPM

by IGELHARINE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Block requests

browser_block

Blocks tab network requests matching URL patterns so they fail; add, remove, or clear rules for the current session.

Instructions

Blocks tab network requests matching URL patterns (they fail). add adds, remove removes, clear removes all rules you set. Patterns: * any chars, ? one char. A bare domain matches every request containing it ("ads.example.com" → "ads.example.com"). A trailing * is added automatically so query strings still match (".png" → ".png*"). The tab skips the cache while rules exist. Rules last only while this Claude session is alive and are shown to other agents in the header. With no args, shows current rules.

Input Schema

NameRequiredDescriptionDefault
addNoURL patterns to block
tabNoTarget tab: number (1, 2…) or ID ("t7"). Use the stable ID when agents share a slot. Required for action tools when there are multiple tabs.
slotYesBrowser slot 1-30. "3", "slot 3", "browser 3" → 3. If the user gives a port like 14052, subtract 14049.
agentNoYour display name, shown to other agents. Subagents must always set it. Default "claude-1e1b".
clearNoRemove all rules set by this session
removeNoPatterns to unblock
summaryNoOne-line note of what you are doing (e.g. "comparing laptop prices"). Shown in browser_status (not the status line). Omit to keep the previous one.
multiSlotNotrue only when one agent must handle several slots together (e.g. comparing). Normally omit (one agent = one slot; use subagents for the rest)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.10
    • changedInput schema / properties / agent / description
      Previous value: -"Your display name, shown to other agents. Subagents must always set it. Default \"claude-68d9\"."New value: +"Your display name, shown to other agents. Subagents must always set it. Default \"claude-1e1b\"."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it states that matching requests fail, that the tab skips its cache while rules exist, that rules live only for the session, that they surface in the header to other agents, and that there is no-arg readback. These are exactly the behavioral traits an agent cannot infer from structured fields.

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 core action and consequence, then compresses a lot of pattern/lifecycle detail into relatively few sentences. Slightly dense and a couple of clauses ('add adds, remove removes') echo the schema, but nothing is wasted.

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-param, no-output-schema, no-annotation tool, the description covers lifecycle, cache behavior, cross-agent visibility, pattern semantics, and no-arg readback. Slot/tab/agent/multiSlot semantics are left entirely to the schema, which is acceptable at 100% coverage but keeps it short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), but the description adds real meaning for the pattern values used by add/remove: wildcard syntax (* and ?), bare-domain expansion, and automatic trailing-wildcard append for query strings. This is genuine semantics beyond the schema descriptions of 'URL patterns to block'.

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?

Specific verb + resource ('Blocks tab network requests matching URL patterns') plus the observable effect ('they fail'), which distinguishes it from the sibling browser_network inspection tools. An agent can tell what this does and what changes in the browser without opening the 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 description explains each action mode (add/remove/clear) and the default behavior ('With no args, shows current rules'), giving clear context for how to invoke it. It stops short of naming alternatives or when-not-to-use (e.g. browser_network vs blocking), so it is not a full 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