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

The description says the tool logs and records into a timeline, which is a write operation, but annotations declare readOnlyHint=true. This is a direct contradiction: 'append-only' and 'Zambo records the report' cannot be read-only in any meaningful sense. The appended nature also strains the idempotentHint=true 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?

Two compact sentences with no filler. The core purpose is front-loaded, the scope is stated immediately, and the behavioral caveat about Zambo's claims is kept to one clear sentence.

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 tool with ten parameters, nested objects, and no explicit parameter elaboration in the description, the summary is too thin to be fully complete. More importantly, the contradiction with readOnlyHint undermines trust in the documented behavior, and the description omits relevant redaction/hashing behavior that would clarify how inputs are handled.

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 100%, so the schema already documents the ten parameters, including redacted_inputs_hash and timestamps. The description adds high-level context about logging external actions but does not add meaning beyond the schema. This matches the baseline of 3 for high schema coverage.

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 states a specific verb and resource: logging an action into an append-only job timeline. It also clearly distinguishes the tool by saying Zambo records the report but does not claim it ran or observed the action, which sets it apart from audit tools that report first-hand observations.

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 phrase 'action performed outside Zambo' gives a clear when-to-use condition, and 'does not claim it ran or observed the action' helps avoid misuse. It does not name sibling tools or explicit alternatives, so it misses some exclusionary guidance, but the intended context is well implied.

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