api_get

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

With no annotations present, the description carries the behavioral transparency burden. It adds only the claim '(safe)', which is useful for a GET-based tool, but it does not explain API_BASE resolution, response behavior, error handling, or whether authentication is required.

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 one compact sentence with no filler. 'Generic' and '(safe)' add useful meaning, though the overall brevity sacrifices informational richness.

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 tool with three parameters, no output schema, no annotations, and zero schema description coverage, this description is far from complete. It never defines API_BASE, explains how path/query/headers are combined, or describes what the response looks like, leaving the agent to guess at important invocation details.

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 0%, and the description adds no direct guidance for 'path', 'query', or 'headers'. The phrase 'against API_BASE' weakly implies that path is relative to the base URL, but query and header semantics are left entirely to inference.

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 identifies a concrete operation: a generic GET against API_BASE, which distinguishes it from the method-specific siblings api_post, api_put, and api_delete. However, API_BASE is left undefined and the relationship to api_probe is not addressed, so the purpose is clear but not fully specified.

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 word 'Generic' implies this is the catch-all for raw GET requests, and '(safe)' suggests it is appropriate for read-only operations. Still, it provides no explicit guidance about when to use this tool versus api_probe, nor any exclusions or conditions.

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