Skip to main content
Glama

Har Clear

har_clear

Clear buffered HAR entries and/or the replay corpus for a specific tab to reset captured network data before new recordings or replays.

Instructions

Drop buffered HAR entries (recording=True, default) and/or the replay corpus.

Ex: har_clear('t0') → {"cleared_entries":42} Ex: har_clear('t0', recording=False, replay=True) → {"cleared_replay":120}

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>"
    },
    "name": "har_clear"
  }
}

Input Schema

NameRequiredDescriptionDefault
replayNo
tab_idYes
recordingNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It says what is dropped, but does not disclose whether the operation is irreversible, whether it errors when no recording is active, whether an in-progress recording session is affected, or any permission requirements. The example outputs give partial signal about result shape only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two lines: a front-loaded statement of what is dropped, followed by two compact examples that each earn their place by showing a distinct parameter combination and return shape. No filler.

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

Completeness3/5

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

An output schema exists, so return values need not be spelled out, and the description is adequate for parameter selection. But as a destructive tool with zero annotations, it should say more about irreversibility and interaction with an active recording session.

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 description coverage is 0%, so the description must compensate — and it does for the two meaningful flags: 'recording=True, default' and 'replay' are both explained and the second example demonstrates their combination. tab_id remains unexplained, keeping it short of a 5.

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?

States a specific verb and resource: drops buffered HAR entries and/or the replay corpus, with the default mode called out. It is distinguishable from har_record_start/stop and har_dump by being the destructive clear operation, though siblings are never named.

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 two examples implicitly show two usage modes (clear only recording entries vs. clear only replay corpus), but there is no explicit when-to-use/when-not or reference to alternatives such as har_record_stop or har_replay_load. Usage must be inferred from the examples.

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