qui_requeue_scan_directory_no_match

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 offers no information about side effects, mutability, permissions, reversibility, or error behavior. The only hint is the HTTP method 'POST' and the endpoint name 'requeue-no-match,' which vaguely implies a mutation, but this is far too thin for safe invocation.

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 two sentences with no filler. The first sentence identifies the endpoint, and the second concisely explains the argument-passing convention. Every word earns its place, and the structure is appropriately front-loaded with the core action.

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 no annotations and zero schema coverage, this description is incomplete. It fails to explain the operation's purpose, when to use it, what the request body should contain, or what the output represents—even though an output schema is said to exist. The description is a bare HTTP wrapper that leaves the agent with many unanswered questions.

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 input schema is a generic 'arguments' object with no property definitions (0% schema description coverage), so the description's instruction to pass path variables directly in arguments, query values in arguments.params, and a request body in arguments.body adds essential structural meaning. This clearly explains how to route parameters, even though it does not enumerate the specific endpoint parameters like {directoryID} or the expected body shape.

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 specifies the exact HTTP endpoint but does not explain what the operation does in domain terms. It simply says 'Call qui's POST /dir-scan/directories/{directoryID}/requeue-no-match endpoint,' which is a technical instruction rather than a clear purpose statement. The endpoint is unique enough to distinguish it from siblings, but the agent is left guessing what 'requeue-no-match' actually accomplishes.

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 is provided about when to use this tool versus alternatives. The description only explains how to structure arguments, not the context or scenario in which this operation should be invoked. Given the many sibling tools for directory scanning (e.g., qui_scan_directory, qui_reset_scan_directory_files), this lack of usage guidance is a significant gap.

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