zalo_disconnectUnlink Zalo from Local MCP (removes the saved session on this Mac). Your chats stay in Zalo; this only disconnects this Mac, and Zalo tools stop working until you run zalo_connect again.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Optional: Zalo has one account. | |
| confirm | No | Ignored; kept for older clients. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / confirm / descriptionPrevious value: -"Must be true to disconnect. Without it the call returns a preview and changes nothing."New value: +"Ignored; kept for older clients."Input schema / properties / accountAdded value: +{
+ "description": "Optional: Zalo has one account.",
+ "type": "string"
+}Input schema / properties / confirm / descriptionPrevious value: -"Must be true to actually unlink."New value: +"Must be true to disconnect. Without it the call returns a preview and changes nothing."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds meaningful context beyond them: what actually gets destroyed (the saved session on this Mac only), what survives ('Your chats stay in Zalo'), and the downstream consequence (Zalo tools stop working). It doesn't cover edge cases such as calling it when not connected, which keeps it at a 4.
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?
Two compact clauses with zero filler, and the core effect (session removal on this Mac) is front-loaded before the reassurance and side-effect note.
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 parameterless, low-complexity disconnect tool with an output schema and explicit destructive annotations, the description covers everything an agent needs: scope of removal, data safety, and broken-tool state until reconnect.
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 100% and the schema itself explains both params ('account: Zalo has one account', 'confirm: Ignored; kept for older clients'). The description adds nothing about parameters, so the baseline 3 applies.
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+resource ('Unlink Zalo from Local MCP') with a parenthetical that pins the exact scope ('removes the saved session on this Mac'). This cleanly separates it from the sibling zalo_connect and the broader set of disconnect_* tools.
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?
Implies the usage condition clearly — Zalo tools stop working until you run zalo_connect again — which both tells the agent when this tool is appropriate and names the recovery action. It doesn't explicitly state exclusions (e.g., don't use if you only want to switch accounts), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.