Fetch

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

Annotations declare readOnlyHint=false and destructiveHint=true, but the description neither confirms nor contradicts this, and it omits crucial context: which HTTP methods are permitted, whether arbitrary paths are allowed, what authentication scopes apply, whether side effects can occur, and whether the tool is rate-limited. For a tool that can mutate the active project, this is a large 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?

The description is a single short sentence, front-loaded and without waste. It is efficient, though its brevity comes at the cost of completeness rather than being optimally informative.

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 destructive, open-ended API request tool with a rich parameter set and no output schema, the description is severely lacking. It should explain the permissible scope (which APIs), method restrictions, authentication behavior, and any safety warnings. With no output schema, the description also fails to indicate the structure of the response.

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 all three parameters (body, path, method) are documented in the schema with examples. The description adds no additional semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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 generic verb-resource pair ("Make an authenticated API request to the active project") but is essentially a raw HTTP escape hatch that could be confused with many siblings like api, cli, or integrations_execute. It does not specify what resources are reachable, what the response looks like, or how it differs from a direct API tool. It restates the tool's nature rather than carving out a distinct purpose.

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 when-to-use, when-not-to-use, or alternative guidance. With ~90 siblings including api, cli, and many resource-specific tools, an agent has no way to know whether to call fetch or a dedicated tool. This is a serious omission.

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