qui_get_rss_rules

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

The annotation readOnlyHint=true already signals a read-only operation, and the description's mention of GET is consistent. However, it adds little beyond the annotation—no details about error behavior, required instance existence, or rate limits. It provides some value by explaining how arguments map to the request, but not enough to exceed baseline.

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?

A single, well-formed sentence with no fluff. It front-loads the endpoint and gives a brief, structured explanation of argument passing. Highly concise and readable.

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?

The description is too generic to be complete for this tool. It fails to state the purpose in plain language (e.g., 'get all RSS rules for an instance'), which is critical given the many RSS-related siblings. It also omits required parameters. The output schema covers return values, but the input side is incomplete, and the lack of use-case context makes the tool hard to select correctly.

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?

The schema is empty (only a generic 'arguments' blob, 0% coverage), so the description should compensate. It vaguely says to pass path variables in arguments but never lists them (e.g., instanceID is clearly needed from the path but not named). It also doesn't mention any query parameters or body fields for this specific endpoint, leaving the agent guessing.

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 the specific endpoint (GET /instances/{instanceID}/rss/rules) and the resource (RSS rules), which distinguishes it from siblings like qui_get_rss_items or qui_set_rss_rule. It doesn't explicitly say 'retrieve' but the HTTP method and path imply fetching rules. A clearer verb would make it 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?

No guidance on when to use this tool versus alternatives. It doesn't say 'use this to list all RSS rules for an instance' or contrast with related tools like qui_set_rss_rule or qui_get_rss_items. The generic argument-passing convention applies to all tools, not this one specifically.

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