Retrieve traffic stats and details for active connections, sorted by download volume, or close a specific connection by ID. Supports limiting the number of results.
查看当前全部连接的流量统计与明细(按下载量排序),可传 closeId 关闭指定连接
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 明细最多返回条数,默认 30 | |
| closeId | No | 关闭该 id 的连接(传此参数时不返回列表) |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It does disclose two useful traits: results are ordered by download volume, and the closeId mode both terminates a connection and suppresses the list. It is silent on permissions required to close a connection, whether the close is immediate/reversible, and rate or refresh considerations.
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 compact sentence front-loads the primary purpose (view connections and traffic stats) and appends the secondary mode (closeId) as a modifier. No padding or repetition; a 5 is withheld only because the dual-purpose nature could be structured slightly more explicitly.
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?
With no annotations and no output schema, the description should carry more weight. It covers purpose, ordering, and the destructive closeId branch adequately, but says little about what the 'traffic statistics and details' payload contains or what happens on close, leaving gaps for a connection-management tool.
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 both parameters (limit, closeId) are documented in the schema itself, so the baseline of 3 applies. The description reinforces closeId's side effect and the list ordering, but adds no syntax, units, or format detail beyond the schema.
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 and resource: view traffic statistics and details for all current connections, with an explicit ordering (by download volume). That is far more informative than the bare name get_connections. It does not need to differentiate from siblings since none of them (get_configs, list_proxies, set_mode, etc.) deal with live connections, but it also makes no explicit contrast.
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 rather than spelled out: the description notes that passing closeId closes the specified connection, which signals the tool's second mode of use. There is no statement of when NOT to use it, no prerequisites, and no reference to any alternative tool for connection handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.