logs_search

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

No annotations are supplied, so the description carries the burden; it does disclose one genuinely useful behavioral trait — it returns the newest matching lines in oldest-first order. However, it says nothing about default result size (only in the schema), whether logs are ephemeral or cleared elsewhere, or how 'before' interacts with 'from'/'to' for paging.

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 dense sentence with the resource scope front-loaded and the return ordering appended. Nothing is wasted, though the phrase "returns the newest matching lines, oldest first" is slightly compressed and could read ambiguously at first pass.

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 ten-parameter, fully self-documenting, read-only search tool with no output schema, the description adequately covers scope and result ordering. Remaining gaps — pagination interaction and log lifecycle — are minor given the schema already explains cursor and limit semantics.

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 coverage is 100%, so all ten parameters are already documented with their own syntax examples (console grammar for q, relative time forms for from, cursor semantics for before). The description only restates the filter dimensions already present in the schema, adding no meaning beyond it — baseline 3 applies.

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?

Uses a specific verb ("Search") plus a well-scoped resource ("the suite's log") and enumerates the dimensions it can filter on, so an agent knows immediately this is a cross-emulator/function log query. It does not name or distinguish itself from the sibling logs_facets, so the boundary with that tool is left implicit.

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?

Usage is implied by the scope statement (searching console output across emulators and functions), but there is no explicit when-to-use guidance, no mention of when to prefer logs_facets, and no note about logs being cleared by emulators_clear. An agent must infer the selection criteria.

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