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

Goes well beyond the annotations by disclosing the required trade:propose scope (PAT), the append-vs-replace default, the 4000-char truncation behavior, and an explicit safety statement that it never executes a trade or moves funds. This meaningfully clarifies the destructiveHint=true annotation for the replace mode.

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?

Front-loads the core action and default mode, then layers scope and safety constraints. The parenthetical about the upsert path and approval flow is slightly dense but each clause carries useful information.

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 3-parameter mutation tool with no output schema, the description covers the action, default behavior, auth requirement, side-effect boundaries, and truncation. An agent has everything needed to invoke 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?

Schema coverage is 100%, so day, mode, and body_md are already documented in the schema, including the append default and truncation. The description restates the append default but adds no new syntax or format detail beyond the schema, so baseline 3 applies.

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 verb and resource ('Append (default) or replace a markdown note on one diary day') and names the underlying operation (diary_day_notes upsert). It is clearly distinguishable from read_diary_day and the propose_trade family, and the 'Diary-only' clause bounds the scope.

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?

Gives clear context: default is append, replace is the alternative, and it notes the same write path used by the agent-chat approval flow and daily_prep. It does not explicitly say when to prefer this over read_diary_day or when not to use it, so it stops short of full when/when-not guidance.

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