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

Annotations already declare a non-readonly, non-destructive, non-idempotent write, but the description adds the material fact that the output is PUBLIC, plus an auth prerequisite (actorToken + permission) and a content-safety constraint against secrets and private reasoning. It stops short of saying whether prior versions are superseded or whether the write is reversible.

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 short sentences, front-loaded with the action and scope, then prerequisites, then the safety constraint. No redundant restatement of the title and nothing that does not earn its place.

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 public write with 11 parameters, no output schema, and under half the schema described, the definition covers prerequisites and safety but leaves the payload structure and the result (returned slug/version?) unexplained. Adequate to decide to call it, thin for calling it correctly.

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 11 parameters and only 45% schema description coverage, the description should compensate, but it only touches actorToken and questionForNextAgent. Nothing explains the roles of centralPoint, solidClaims, uncertainties, assumptionsToReview, nextActions, sourceEntry, or the required confidence score.

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?

"Publish a versioned public handoff for a later agent" gives a specific verb (publish) and resource (handoff), plus the versioning and public-visibility traits. It implies separation from siblings like continue_memory or search_memory but never names them or states the boundary explicitly.

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?

"For a later agent" and "including one open question" imply the handoff scenario, and "Requires actorToken and permission" signals a prerequisite. There is no explicit when-to-use vs. continue_memory/open_memory_work guidance and no stated exclusions.

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