clear_logs

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe, non-destructive nature is captured. The description explains that the log cannot be cleared, which is the tool's behavior is to explain. However, the description does not reveal what the output is (likely an explanation string or boolean), nor does it disclose what happens if the device parameter is null. Since annotations cover the safety profile, the baseline is moderate; the description adds minimal behavioral context beyond the core explanation, so a 3 is appropriate.

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 sentence, which is concise and front-loaded. It states the core purpose clearly without any fluff. No unnecessary words. However, it is too short to provide the usage and parameter context that would make it more helpful, but for conciseness, it earns a 4 for efficiency.

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 tool has one parameter, an output schema, and annotations all available, but the description is minimal. It explains the limitation but doesn't tell the agent what to expect as output, how to specify the device, or why the tool exists (i.e., why not just call clear_logs on the router). Given the explanatory nature, the description should clarify that it's a no-op or query that returns a reason, which is missing. The output schema exists, so return format might be redundant, but the purpose context is insufficient. The tool is relatively simple, so a bit more description would make it complete; currently it's incomplete.

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 has only one parameter 'device' with no description, and schema description coverage is 0%. The description does not mention the parameter at all. The parameter is likely a device identifier, but the tool description doesn't explain its role in the explanation. With 0% coverage and no description context, the tool fails to compensate, so the score is low. However, with only one param, the lack of detail is less harmful than multiple undocumented params, but still a gap.

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 says 'Explains why MikroTik's in-memory log cannot be cleared on demand.' It clearly identifies the resource (logs) and the limitation (cannot be cleared), but the verb 'Explains' suggests this tool provides an explanation, not an action. It is distinct from siblings like get_logs or export_logs but the purpose is not to perform an operation. The title 'Clear Logs' implies the action of clearing, which is contradicted by the description's explanatory nature. This vagueness in action leads to a score of 2 — not a tautology but not a clear action verb either.

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 explicit guidance on when to use this tool versus alternatives. Sibling tools like get_logs, search_logs, and get_log_statistics exist, but the description doesn't mention them or contrast usage. The description implies it's for understanding the log-clearing limitation, but that context isn't fleshed out. No exclusions or when-not-to-use guidance is provided, so this is minimal guidance at best.

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