Simulate offline, slow network, or latency conditions in Electron apps to test how UI and behavior react under poor network conditions.
Emulate network conditions (offline, slow network, latency)
| Name | Required | Description | Default |
|---|---|---|---|
| latency | No | ||
| offline | No | ||
| sessionId | Yes | ||
| uploadThroughput | No | ||
| downloadThroughput | No |
Changes observed during successful MCP inspections.
v1.0.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say whether the emulation persists after the call, whether it is scoped to the given session, whether omitted parameters are reset or left unchanged, or what permissions/state are required. The parenthetical merely restates the parameter names rather than describing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no padding, and the core purpose is front-loaded. It is arguably under-specified rather than over-long, but it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation-style tool with zero annotation coverage and no output schema, a one-line description is inadequate. Critical context — session scoping, persistence, reset behavior, throughput units — is missing, leaving the agent unable to call this correctly beyond the most obvious case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description must compensate and does not. It loosely gestures at 'offline' and 'latency' (two of five params) but says nothing about sessionId (the only required parameter), uploadThroughput, or downloadThroughput, nor their units or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Emulate network conditions') and names the main modes in parentheses, so an agent knows this throttles/degrades the connection. It does not differentiate itself from the sibling reset_network_conditions or explain the relationship between the two, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites (e.g. an active session must exist), and no mention of the sibling reset_network_conditions that would undo this. The agent must infer that this is the counterpart to the reset tool 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.