memo_signal_remember

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

Annotations provide some coverage: idempotentHint=true aligns with the 'idempotent' trait in the description, and destructiveHint=false suggests a safe write. The description adds 'durable' and mention of epoch/fence semantics are NOT in the description. However, with idempotentHint already in annotations, the description adds modest context by describing the write as idempotent, but largely restates annotation info rather than revealing behavior like return semantics or what 'stale epochs rejected' means for the caller.

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?

One concise sentence, no filler or fluff. Accurate for its limited scope, though it sacrifices explanatory depth for brevity. The sentence earns its place but doesn't add behavioral richness.

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?

This is a write operation with no annotations on error conditions, side effects, or return value. While an output schema exists and parameters are covered, the description doesn't clarify the semantic model of a 'watcher' or how this differs from related tools (memo_signal_list, memo_state). The term 'operational watcher' is unexplained domain jargon that the description assumes the reader knows.

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 documents all 5 parameters with reasonable descriptions (epoch as monotonic watcher with stale rejected, fence as leadership token, marker as stable idempotency key, etc.). The description adds minimal parameter insight beyond the schema; the only added semantic is that 'marker' serves as a 'stable idempotency marker,' which partially overlaps with the schema. Baseline 3 is correct given full 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 it remembers a 'durable, idempotent operational watcher marker,' which names the resource (marker) and some traits (durable, idempotent) but uses jargon-heavy terms ('operational watcher marker') that are ambiguous without further context. It doesn't clearly distinguish this from the many sibling memo_* tools like memo_signal_list or memo_state, nor explain what a 'watcher' is in this domain.

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?

No explicit when-to-use vs alternatives guidance is given in the description. The name and sibling list suggest this is related to signal management (memo_signal_list exists), but nothing states when to prefer this over memo_signal_list or other tools. 'Operational watcher marker' implies a niche use case but the description provides no context on triggers or scenarios.

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