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

Annotations already cover readOnly/destructive, but the description adds substantial behavior the agent could not otherwise know: results are ordered newest first, and rows above the caller's role visibility are omitted entirely rather than blanked, with an explicit rationale. That redaction rule is a material behavioral fact that affects how an agent should interpret an apparently complete timeline.

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?

Three tight sentences with the resource and its contents front-loaded, followed by the safety and redaction notes. Nearly every clause earns its place; the em-dash explanation of why rows are omitted is slightly verbose but justified by the non-obvious behavior it clarifies.

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?

With no output schema, the description does the work of describing the returned rows (event types, ordering, redaction) well, and annotations cover the safety profile. The remaining gap is pagination: for a chronology that could be long, an agent gets no guidance on paging through results.

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%, so the description must carry the parameter burden, and it does not. 'One person's' implicitly scopes person_id, but limit and offset are never mentioned — no pagination semantics, no note that limit caps at 100, no indication of default page size or whether the newest-first ordering interacts with paging.

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?

States a specific resource (one person's chronology) and enumerates exactly what it contains: application creation, stage changes with reasons, internship starts, form submissions. This is clearly distinguishable from siblings like hr_get_person or get_person, which read a single record rather than a history.

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 'One person's chronology' — an agent can infer it should call this when it needs the historical sequence for a known person. However, there is no explicit when-to-use/when-not guidance and no named alternative (e.g. hr_get_person for current state versus this for history), so routing still requires inference.

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