disconnect_wifi
Disconnects from the active Wi-Fi network to stop wireless connectivity when you need to go offline.
Instructions
Disconnect from the current WiFi network
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Disconnects from the active Wi-Fi network to stop wireless connectivity when you need to go offline.
Disconnect from the current WiFi network
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is covered. The description adds nothing further: it doesn't say what happens if no network is connected, whether the change is reversible, or that the machine falls back to another interface. For a state-changing network tool this leaves a real gap.
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?
One short, front-loaded sentence with the action verb first and no filler. It is appropriately sized for a zero-parameter tool, though it is sparse enough to leave the reader wanting a bit more context.
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?
Annotations carry the safety profile and there are no parameters or output schema to explain, so the description is barely sufficient. It still omits the practical postcondition (loses connectivity, likely falls back to wired/Ethernet) that an agent needs to reason about consequences.
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?
The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies the target network is whatever is currently joined rather than a named argument.
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?
"Disconnect from the current WiFi network" states a specific verb and resource, so the action is unambiguous. It doesn't explicitly distinguish itself from the sibling toggle_wifi, which could also disconnect the network, but the intent is still clear.
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?
Usage is implied by the verb (tear down the active WiFi connection), but the description never says when to prefer this over toggle_wifi or how it relates to connect_wifi. No prerequisites or exclusions are given, so the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.