gc_http

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions auth types and actions but does not disclose what happens on responses, how errors are surfaced, whether non-2xx responses throw or return, rate limiting, or whether the tool has network access constraints. For a tool that makes arbitrary external HTTP calls, this is a significant transparency gap.

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?

Two sentences, front-loaded with the core purpose and a compact enumeration of actions and auth types. No wasted words. Could arguably be considered slightly under-specified, but what's there is efficient.

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 generic HTTP client with 7 params, nested objects, no output schema, and zero annotations, the description is under-specified. It doesn't explain response formats, status code handling, error semantics, rate limits, or security considerations of making arbitrary external calls. The complexity of this tool type demands more context to be safely invoked by an agent.

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%, so the schema already documents all 7 parameters. The description adds the auth mechanism list (bearer, basic, header), which maps to the auth.type enum, and the action enum, but doesn't add semantics beyond the schema. Baseline 3 is appropriate since schema does the heavy lifting and the description provides marginal confirmation.

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 states it is a 'Generic HTTP client for external API calls' with a specific verb+resource. It lists the four supported actions (get, post, put, delete) and auth mechanisms, which distinguishes it from siblings like gc_relay or gc_mcpclient that handle other transport concerns. However, it doesn't explicitly differentiate itself from those siblings, keeping it at a 4 rather than 5.

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 usage ('external API calls') but doesn't provide when-to-use vs when-not-to guidance or mention alternatives. There's no guidance on when to prefer this over sibling tools like gc_mcpclient, gc_relay, or gc_control. The context is clear for a generic HTTP client but lacks explicit exclusions or alternative tool references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.