Close the active TCP connection to KingstVIS while keeping the application running. Use this to end remote communication without terminating the logic analyzer software.
Close the TCP connection (KingstVIS keeps running).
| 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?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the TCP connection is closed and, importantly, that KingstVIS keeps running, which is a non-obvious behavioral trait. It does not mention side effects like losing unsaved state or whether reconnect is needed, but for a simple disconnect operation the disclosed behavior is sufficient.
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?
The description is a single short sentence that immediately states the action and includes the key caveat about KingstVIS continuing to run. Every word is necessary and no filler is present.
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?
Given the tool's simplicity—no parameters, no output schema, and a clearly named sibling set—the description fully covers what an agent needs to know to invoke the tool correctly. It specifies what the tool does and the one important behavioral consequence.
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 has zero parameters, so there is nothing for the description to add beyond the schema. Per the rubric, a tool with no parameters receives a baseline of 4, and the description satisfies that baseline.
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?
The description states a specific verb ('Close') and a specific resource ('the TCP connection'), and adds a clarifying parenthetical that KingstVIS keeps running. This clearly distinguishes it from similar lifecycle tools like 'stop' or 'connect'.
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?
The description implies the tool is used to close the TCP connection while keeping the application alive, which provides clear context for when to use it. It does not explicitly name alternatives or when-not-to-use conditions, but the parenthetical about KingstVIS staying running effectively communicates the main scope boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.