Skip to main content
Glama

Route Add

route_add

Install a browser request interception rule to match URLs, methods, headers, or resource types and apply block, fulfill, continue, modify, tee, or redirect actions.

Instructions

Install rich interception rule. action: block|fulfill|continue|modify|tee|redirect.

MATCH (AND of any provided): url_pattern substring (cheap, default) url_regex re.fullmatch method GET/POST/... resource_type Document/XHR/Fetch/Script/Stylesheet/Image/Font/Media/... header_match {header_lower: regex} — re.search per header status_min/max response-stage filter (forces response-stage interception)

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": {
      "tab_id": "<tab_id>",
      "action": "<action>"
    },
    "name": "route_add"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNo
timesNo
actionYes
methodNo
statusNo
tab_idYes
captureNo
enabledNo
headersNo
new_urlNo
rule_idNo
body_b64No
delay_msNo
priorityNo
url_regexNo
new_methodNo
status_maxNo
status_minNo
url_patternNo
body_replaceNo
error_reasonNoBlockedByClient
header_matchNo
new_post_dataNo
resource_typeNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description must carry the full behavioral burden. It explains match semantics and response-stage forcing for status_min/max, but it omits key mutation behavior: rule persistence, precedence/priority effects, per-action required fields, validation behavior, and side effects of installing or replacing rules.

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?

The description is compact and front-loaded, with the tool's core action and match semantics presented immediately. The pseudo-schema formatting is efficient and avoids wasted prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex mutation tool with 24 parameters and no annotations. Although an output schema exists, the description is not complete enough to guide correct use of action-specific parameters or to explain lifecycle and precedence behavior.

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 0%, so the description must compensate. It adds useful meaning for key matching parameters—url_pattern as substring, url_regex as re.fullmatch, header_match as re.search—and for action values, but most of the 24 parameters (body, body_b64, body_replace, headers, new_url, new_method, new_post_data, delay_ms, priority, times, enabled, etc.) remain undocumented.

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?

The description gives a specific verb and resource: 'Install rich interception rule.' It also enumerates action modes, making the tool's basic function clear. It does not, however, distinguish route_add from nearby siblings like route_add_many, route_block_set, or block_urls.

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 implies usage by listing the supported actions and match criteria, but it does not state when to use route_add instead of route_add_many, route_block_set, or block_urls. There are no explicit exclusions or alternative-selection guidance.

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