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

Annotations already establish that this is a mutating, idempotent, non-destructive operation, but the description adds little beyond 'privacy-filtered project metadata.' It does not explain expected-version conflict behavior, whether details are replaced or merged, or what effects the update has on related context nodes.

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?

The description is short and single-sentence, which is structurally appropriate, but it is vague rather than economically informative. It earns partial credit for mentioning the resource and input source, but it omits essential operational context.

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 7-parameter mutation with no output schema and 0% schema description coverage, this description is severely inadequate. An agent cannot determine what the hosted update context note is, what privacy-filtered metadata means, why expectedVersion is required, or how idempotencyKey should be generated.

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 carries the full burden of explaining parameters, but it names none of them. required fields like projectId, noteId, idempotencyKey, and expectedVersion are completely unexplained, and the nested details object is not even hinted at.

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 the core operation ('Update ... context note') and names the resource ('hosted update context note'), which distinguishes it from unrelated update tools like update_finding or update_report. However, the phrase 'hosted update' is awkward and it doesn't clearly differentiate this from near neighbors like move_context_note, convert_context_note, or record_context_node.

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 guidance about when to use this tool versus context_note alternatives. It doesn't mention that this is for updating existing notes, that creation belongs elsewhere, or any prerequisites such as an existing note or project context.

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