disconnect_channel
Disconnect a channel: erases its stored credentials and revokes the provider token where the network supports it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes |
Disconnect a channel: erases its stored credentials and revokes the provider token where the network supports it.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the critical destructive effects: stored credentials are erased and the provider token is revoked, with the honest caveat 'where the network supports it'. It stops short of stating irreversibility, whether the channel record/posts survive, or what auth level is required.
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 well-formed sentence with the action front-loaded and the consequences attached; no filler whatsoever.
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 destructive, annotation-free mutation with no output schema, the description covers the main side effects but omits irreversibility, how partial failure behaves when the network does not support token revocation, and what a successful response indicates — gaps an agent would want before calling it.
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 coverage is 0% for the single required parameter, so the description would need to compensate — it adds nothing about whether channel_id is the internal id from list_channels or a provider-side identifier, nor any format hints. The parameter name is fairly self-explanatory, keeping this at a minimum-viable 3.
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 ('Disconnect a channel') and immediately qualifies the effect (credential erasure, token revocation), making it trivially distinguishable from the sibling connect_channel. An agent knows exactly what this does without opening the schema.
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 only implied by the name's opposition to connect_channel; there is no explicit when-to-use guidance, no mention of alternatives (e.g. using list_channels to obtain channel_id, or rotate_my_key for credential refresh), and no statement of prerequisites or when not to use it.
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.