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

With no annotations, the description carries full disclosure burden, and it does volunteer two valuable traits: no digest email is sent, and scans lock for a few minutes so repeat calls can return the in-flight scan instead of a new one. It omits other important traits for an unannotated mutating action, such as whether it requires permissions or is reversible, what a successful result looks like, and whether a failed scan blocks future calls.

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, then the digest caveat, then the locking caveat, in decreasing order of importance. It is tight overall, with only mild redundancy between 'Run a scan ... right now' and 'This on-demand scan'.

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?

One string parameter and no output schema or annotations makes this a simple tool, and the description covers the two things an agent would otherwise get wrong: expecting an email and being surprised by the in-flight lock. Only the return value and error/authorization behavior are left implicit.

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?

The single parameter has 100% schema description coverage ('Watch id from list_watches'), so the schema already handles the semantics. The description only echoes the same idea with 'one watch' and adds no format, sourcing, or validation detail beyond the schema. Baseline 3 is correct when the schema does the work.

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: 'Run a scan of one watch right now.' The scope ('one watch', 'right now') is unambiguous and it distinguishes itself from scheduled scans, which is the closest behavioral neighbor. It stops short of naming any sibling tool, so the differentiation is conceptual rather than explicit.

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?

'Right now' plus the contrast with scheduled digests implies the use case: an agent that wants results immediately instead of waiting for the scheduled digest. However, it never states when NOT to call it, prerequisites (does the watch need to exist / be enabled?), or what to do if the returned scan is in-flight beyond 'repeat calls may report' it.

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