Send HTTP requests from Android device automation, optionally routing through an audit proxy like mitmproxy. Certificate verification is off by default for self-signed proxy setups.
发 HTTP 请求（proxy 参数可接 mitmproxy 等审计代理；verify 默认关闭以适配自签代理证书）
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| body | No | 请求体（文本） | |
| proxy | No | 置空字符串则直连 | http://127.0.0.1:8080 |
| method | No | GET | |
| headers | No | ||
| timeout | No |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that verify is off by default and why (self-signed proxy certificates), which is useful behavioral context. However, it omits critical details such as authentication requirements, rate limits, error handling, or side effects. For a network tool with no annotations, this is insufficient.
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, front-loaded sentence that efficiently conveys the core purpose and two important configuration notes. It is concise and avoids unnecessary words. However, the inclusion of 'verify' (not a parameter) could confuse and slightly detracts from structure.
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 no annotations, no output schema, and only 33% schema coverage, the description should provide more behavioral context. It mentions proxy and verify but omits authentication, error handling, rate limits, and return format. It also references a non-existent parameter (verify), which is misleading. The description is not complete enough for an agent to use the tool reliably.
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 33%, so the description must compensate. It adds meaning for the proxy parameter (can accept mitmproxy, empty string for direct connection) and for verify (default off for self-signed certs), but verify is not even a parameter in the schema—this is a discrepancy. The description does not explain other parameters like method, headers, timeout, or body. It partially fills gaps but leaves much undocumented.
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 clearly identifies the action: sending an HTTP request. It distinguishes this from siblings like shell.run or knowledge.list by being a direct network operation. However, it does not explicitly differentiate from other potential HTTP-like tools (none exist in siblings), so it's clear but not maximally distinctive.
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 mentions that the proxy parameter can accept mitmproxy and that verify is disabled by default to accommodate self-signed proxy certificates, but it does not provide explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives or conditions for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.