get_boot_errors

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

Annotations already declare readOnlyHint, openWorldHint (likely indicating data may change), idempotentHint, and destructiveHint=false, so the agent knows it's a safe read operation. The description adds no behavioral details beyond that—it does not specify whether logs are paginated, whether they include kernel messages, or how far back 'recent' goes. With annotations covering safety, a 3 is appropriate as it adds minimal value but doesn't contradict.

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 concise sentence of 8 words, front-loaded with the primary verb and resource. It is efficient and contains no fluff, but it could be slightly more informative without losing conciseness.

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 is simple (one parameter, no output schema) and annotations cover safety. However, the description lacks key details for correct invocation: what exactly 'lines' means (count? limit?), and potential return format (JSON array? string?). Given the low complexity, this is acceptable but not complete—agents might wonder if 'recent' refers to time or byte size. Slight improvements would make it more complete.

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% (the parameter has no description in the schema), so the description must add meaning. It does not mention the 'lines' parameter at all. The parameter name suggests a count of lines, but the description doesn't clarify whether it is a limit, number of entries, or how it interacts with 'recent'. Since the schema provides no guidance and the description doesn't, this is a gap, but the parameter name is somewhat self-explanatory.

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 states it retrieves recent error-level journal entries from the current boot, specifying the verb (get), resource (journal entries), and scope (current boot). It is distinguishable from siblings like get_logs and list_failed_services because it specifically scopes to error-level entries from the current boot, though it does not explicitly compare to those siblings.

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 implies when to use it (when you need error-level logs from the current boot) but does not provide explicit guidance on when not to use it or alternatives. For example, it doesn't mention that get_logs might be more general, or that list_failed_services is for failed services. The scope is clear enough for an agent to infer usage, but no exclusions are given.

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