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

With no annotations at all, the description carries the full burden and does a lot of work: it discloses the signing/authentication requirement over the full RPC body, the idempotency-key dual-source rule with precedence, the optimistic-concurrency conflict on stale if_seq, and an explicit prompt-injection warning about *_untrusted and agent-authored content. What it omits is what a successful append returns (seq, hash, vault head) and whether it is reversible, which for a vault-append is a meaningful gap.

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?

It is compact and every clause carries information, but it is front-loaded with signing and header plumbing rather than the core operation, and the header clause cannot be acted on given the input schema. Dense semicolon-chained clauses make it harder to scan than a purpose-first sentence followed by constraints.

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?

Not applicable.

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 8 parameters, so the description must compensate and mostly does not. It explains idempotency_key and if_seq semantics well, but the required `key`, the `content`/`content_base64` payload distinction, `tags`, and `content_type` are never mentioned, and it relies on an 'Idempotency-Key header' route that the schema's additionalProperties:false appears to forbid.

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 verb+resource is 'Append a put to my vault chain', which places it in the vault/memory family, but 'put' is protocol jargon and the description never says it stores keyed memory content alongside siblings memory_get/memory_list/memory_search. No sibling is named or differentiated, so the agent must infer from the name and the tag list.

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?

There is no when-to-use guidance and no comparison to alternatives such as notarize, add_reflection, or memory_get. The only conditional statement is 'A stale if_seq is a conflict', which is behavioral rather than usage guidance, and nothing signals when the agent should use this over other write paths.

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