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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the description is free to add real value — and it does: retention-window limits, the mutual exclusion of tail and cursor, ordering semantics (observedAt for tail vs delivery order for cursor pages), and the caveat that empty results indicate no retained matches rather than runtime health. What is missing is default page size behavior and how much data a request can return.

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?

One dense paragraph, front-loaded with what the tool reads and filtered by, followed by pagination and semantics. Every clause carries information; the only cost is that the tail/cursor/pagination clauses run together as a single long sentence that is harder to parse than it needs to be.

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 9-parameter, no-output-schema, zero-coverage read tool, the description covers filtering, pagination modes and result semantics well, but leaves the agent without limit/default-paging knowledge or any sense of the response shape. It is adequate to call correctly in the common case but not 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% across 9 parameters, so the description must carry the load: it explains level, category, from/to format (UTC, exactly three fractional digits, half-open interval) and the tail/cursor constraint. But limit (1–100) and the projectId/deploymentId scoping are never mentioned, leaving roughly a third of the parameters documented only by their type and bounds.

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 opens with a specific verb and resource ('Read retained logs') and scopes it with the exact filters available (level, build/runtime category, time window). The deployment scoping comes from the tool name rather than the sentence, and no sibling (project logs, function logs, deployment events) is named to disambiguate when to reach for this one instead.

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?

Useful operational rules are given (tail=true cannot be combined with a cursor; cursor pages follow delivery order; empty means no retained matches). However there is no guidance on when this tool should be chosen over eurobase_list_project_logs, eurobase_list_function_logs or eurobase_list_deployment_events, and the 'optional ... (both required)' phrasing for from/to leaves the caller guessing whether the pair is mandatory.

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