Skip to main content
Glama

vibeside_hmr_clear

Clear cached HMR dev server telemetry, compiler errors, and rebuild duration records to reset diagnostics.

Instructions

Clear all cached HMR dev server telemetry events, compiler errors, and rebuild duration records.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.17.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations present, the description carries the full behavioral burden. It does disclose the destructive scope precisely (which three record categories get wiped), which is real value beyond the name; but it omits irreversibility, whether an active browser/session connection is required, idempotency, and error behavior.

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?

A single sentence with the verb front-loaded and no filler. Every element of the enumeration earns its place by defining the blast radius of the clear operation.

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?

For a zero-param, no-output-schema tool this is close to adequate, but it is a destructive operation with no annotations and no statement about whether results are returned, whether a connected browser is required, or whether the clear is reversible. A short clause covering those would make it complete; as written the agent knows what is cleared but not the conditions or consequences.

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?

The tool takes zero parameters with an empty object schema, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies no argument is needed by framing the action as clearing all cached records.

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 (clear) plus a precisely enumerated resource set (cached HMR dev server telemetry events, compiler errors, rebuild duration records), so the agent knows exactly what data this affects. It is distinguishable from siblings like vibeside_telemetry_clear or vibeside_clear_dom_telemetry by the HMR scope, but it never names a sibling or explicitly contrasts scopes, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use guidance, no prerequisites, and no alternatives. It never mentions that vibeside_hmr_telemetry is the read counterpart or that other clear_* tools target different telemetry streams, so the agent must infer usage and disambiguation entirely on its own.

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