Skip to main content
Glama

net_throttle

Simulate network and CPU conditions for a browsing session to test performance under throttling. Use presets or custom latency, throughput, and CPU slowdown; reset to full speed with 'none'.

Instructions

Emulate network + CPU conditions for the session (CDP). Use a preset (offline / slow-3g / fast-3g / fast-4g / none), or custom throughput+latency, plus an optional CPU slowdown factor (max 20x). 'none' (the default) resets everything back to full speed. The state persists across page_goto/reload until reset or the session closes (page_state shows it).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
presetNocanned profile; default 'none' resets to full speed
cpuRateNoCPU slowdown factor: 1 = none, 4 = 4x slower (max 20)
offlineNocut the network entirely (independent of preset)
latencyMsNocustom added latency, ms
sessionIdNo
uploadKbpsNocustom upload throughput, kilobits/s
downloadKbpsNocustom download throughput, kilobits/s

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly notes that the state persists across page_goto/reload until reset or session close, and that 'none' resets to full speed. This adds valuable context about side effects and persistence beyond the schema, though it does not address potential interactions with concurrent custom settings or return 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?

The description is concise, consisting of two sentences that front-load the core purpose and then enumerate key options, default behavior, and persistence. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.

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?

Given the tool has 7 parameters, no output schema, and no annotations, the description covers the main functionality well but leaves gaps: it does not clarify whether presets and custom throughput/latency can be used together, does not mention the sessionId parameter at all, and does not describe the return value or error conditions. These omissions could lead to incorrect invocation or unexpected 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 description coverage is high (86%), so the baseline is 3. The description reinforces preset names and the max CPU factor, and clarifies the reset semantics of 'none'. However, it does not explain how preset and custom parameters interact (e.g., whether they are mutually exclusive or can be combined), and it completely omits the undocumented sessionId parameter, leaving that gap unaddressed.

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 clearly states the tool emulates network and CPU conditions for a session via CDP, which is a specific verb and resource. It lists presets and custom options, distinguishing it from general network tools. However, it does not explicitly differentiate itself from the sibling 'net_slow', which might perform a similar function, so it misses an opportunity to clarify when this specific tool is needed.

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 explains how to use presets and custom parameters, but does not provide explicit guidance on when to choose net_throttle over alternatives like net_slow or net_intercept. It implies usage for throttling scenarios but offers no exclusions or direct comparisons to siblings, leaving the agent to infer the tool's niche.

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