Close the focus and step back

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

Annotations declare readOnly=false, destructive=false, idempotent=false, but the description adds behavior annotations cannot express: a node with open closure conditions refuses to close, and the tool steps back to its parent. That refusal/guard semantics is genuinely new context. It stops short of saying what the recording produces or how the parent transition behaves on force.

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-loaded with the action in the opening clause, and nearly every sentence does work (when to call, misuse warning, recursion). The prose is somewhat ornate ('the mistake that refusal exists to catch'), which costs a little density but stays within a reasonable size for a guarded mutation.

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?

No output schema exists, so the description must carry the behavior, and it covers triggering condition, refusal guard, and recursive stepping well. It leaves unstated what a successful close returns or how force interacts with the trace, which is a minor gap for a non-idempotent mutation.

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 already fully documents next, force, and outcome. The description only gestures at recording ('recording what came of it'), adding no syntax, format, or default guidance beyond the schema. 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?

The first sentence names a specific verb and resource ('Close the current focus and step back to its parent, recording what came of it') and ties the tool to the sibling vivac_push, so an agent can distinguish pop from push without opening either schema. The domain vocabulary ('focus', 'node') is consistent with the sibling naming.

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?

It states exactly when to call it ('once the work vivac_push opened is actually finished'), explicitly rules out a misuse ('not on a whim to clear the stack'), and even gives recursive guidance ('if the work also settles that node ... pop again'). Alternative-condition routing is explicit rather than inferred.

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