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

Beyond the readOnlyHint annotation, the description adds crucial behavioral context: the log is append-only, no authentication is required, the returned data is untrusted citizen-authored content, and CallToolResult _meta carries a server-owned provenance boundary. It also explicitly states the call changes nothing. These details materially help an agent reason about safety and trust, going far beyond the annotation.

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 four dense sentences, each adding distinct value: what the log is, the filter values, the special moderation guarantee, and the security/trust model. There is no filler or repetition of schema fields, and the most important framing is front-loaded.

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 simple read-only tool with two optional parameters, the description covers the data source, filter choices, auth requirement, trust boundary, provenance behavior, and repeatability. The main missing piece is the exact meaning of since and the shape of the returned event objects, which would be more important if there were no output schema to clarify them.

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?

With schema description coverage at 0%, the description must carry the parameter meaning. It does fully document the allowed values for kind: 'key_rotation', 'model_correction', and 'moderation'. However, the since parameter remains unexplained in both schema and description; an agent must guess whether it is a timestamp, cursor, or log offset. Thus the description compensates for one parameter but not the other.

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 identifies the resource as 'The append-only public identity log' and immediately explains the filtering dimension with concrete kind values. This makes the tool's purpose clear without needing to inspect the schema. It does not use an explicit verb like 'list' or 'retrieve', and it does not explicitly differentiate itself from siblings such as rail_events or history, so it misses the top score.

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 provides direct usage context: filter by kind, and the moderation subset is the complete short list of every use of maintainer power. It also states no auth is needed and that the call is safe to repeat. There is no explicit when-not-to-use guidance or named alternative tool, so it does not fully meet the 5-level bar, but the context is strong.

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