Raw Request

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

With no annotations to carry the burden, the description does disclose the core behavior: it performs a GET request and requires the path to start with /api/. However, it does not describe response shape, error behavior, authentication expectations, or how params_json is handled behind the scenes, leaving some behavioral ambiguity in an otherwise generic escape-hatch tool.

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 compact, front-loaded with the essential 'escape hatch' concept, and every part contributes value. The two examples are practical and demonstrate both parameters without unnecessary prose.

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 that this is a generic raw API request tool, the description is largely complete: it defines the path constraint, the HTTP method, and when to use it, with examples covering both optional and required parameter usage. It relies on the external API's own endpoint conventions for response details, which is acceptable for an escape hatch, though a note about the response format would make it fully self-sufficient.

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%, so the description must compensate. It gives meaningful semantics for path by requiring the /api/ prefix and provides an example showing params_json as a JSON string used for query parameters. However, the description never explicitly explains that params_json is a JSON-encoded query parameter object, how it is serialized, or that it is optional beyond the schema default.

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 this as an escape hatch for GET requests to any Atlas Przetargów API endpoint, with the explicit path requirement that it must start with /api/. It distinguishes itself from dedicated tooling by stating it is for endpoints not covered by dedicated tools, and the examples reinforce the intended resource and call style.

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 explicitly states when to use this tool: for endpoints not covered by dedicated tools. This directly signals that if a specialized sibling tool exists, it should be preferred, giving the agent a clear routing rule. It also constrains the HTTP method to GET, which is an important usage boundary.

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