stop_proxyStop an active proxy on a specified port and retrieve recording statistics, including client-to-server and server-to-client frame counts.
停掉指定端口的代理, 返回录制统计 (c2s/s2c 帧数)。
| Name | Required | Description | Default |
|---|---|---|---|
| port | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| c2s | Yes | ||
| s2c | Yes | ||
| port | Yes | ||
| status | Yes | ||
| target | Yes | ||
| recorded | Yes |
Changes observed during successful MCP inspections.
v0.6.1Output schema / additionalPropertiesPrevious value: -trueNew value: +falseOutput schema / descriptionAdded value: +"stop_proxy 输出: 双向录制统计。"Output schema / propertiesAdded value: +{
+ "c2s": {
+ "type": "integer"
+ },
+ "port": {
+ "type": "integer"
+ },
+ "recorded": {
+ "type": "integer"
+ },
+ "s2c": {
+ "type": "integer"
+ },
+ "status": {
+ "type": "string"
+ },
+ "target": {
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "status",
+ "port",
+ "target",
+ "recorded",
+ "c2s",
+ "s2c"
+]v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that this is a mutating, non-idempotent, non-destructive action. The description adds the return behavior (recording stats with c2s/s2c frame counts) beyond the annotations, but it does not disclose side effects such as whether in-flight traffic is dropped, whether recording is preserved, or what happens if the port has no active proxy.
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 compact sentence with no filler. The action and return value are front-loaded, and the format is appropriate for a simple one-parameter tool.
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 low complexity, the description plus annotations and output-schema presence largely cover what an agent needs to invoke it: supply a port and expect recording statistics. The main gap is usage guidance, but that is already accounted for in the usage_guidelines dimension.
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?
With 0% schema description coverage, the description carries the burden for the port parameter. The phrase '指定端口的代理' does clarify that the port identifies which proxy to stop, which is the key semantic relationship. However, it does not explain what the port represents precisely, valid ranges, or error conditions for invalid ports.
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 opens with a clear action: '停掉指定端口的代理' (stop the proxy on the specified port), naming both the verb and the resource. It also states what the tool returns, which further disambiguates it from siblings like start_proxy and stop_listener.
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?
There is no guidance about when to use this tool instead of related siblings such as stop_listener or start_proxy. It also does not mention prerequisites, such as whether the proxy must already be running, or any conditions under which this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.