Skip to main content
Glama
Sign In
vivac

vivac

by JAAvila-Of
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Close the focus and step back

vivac_pop

Closes a completed focus and returns to its parent, recording the outcome and next step; unresolved closure conditions block closure unless forced.

Instructions

Close completed focus and return to its parent with outcome/next. Unresolved closure conditions refuse; do not pop merely to clear the stack. Pop again only if the parent is also settled.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "vivac_pop"
  }
}

Input Schema

NameRequiredDescriptionDefault
nextNoNext step for whoever resumes; outcome alone does not capture it.
forceNoClose over unresolved conditions, leaving a trace.
outcomeNoWhat was completed; for a record start with Record:.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.22.1
    • changedInput schema / properties / force / description
      Previous value: -"Close anyway, over open closure conditions. Leaves a trace that it happened."New value: +"Close over unresolved conditions, leaving a trace."
    • changedInput schema / properties / next / description
      Previous value: -"What to pick up next, for whoever comes back. Without it the stop leaves nothing to pick up: the outcome is what was finished, not what comes next."New value: +"Next step for whoever resumes; outcome alone does not capture it."
    • changedInput schema / properties / outcome / description
      Previous value: -"What happened. Read back later, so leaving it out costs the next reader the point of the node."New value: +"What was completed; for a record start with Record:."
  2. Changed1 schema field changedv0.17.9
    • changedInput schema / properties / next / description
      Previous value: -"What comes after, when it differs from the outcome."New value: +"What to pick up next, for whoever comes back. Without it the stop leaves nothing to pick up: the outcome is what was finished, not what comes next."
  3. First observedv0.17.1

TDQS

A3.6/5.0
Behavior3/5

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

The annotations already declare this is a non-readOnly, non-destructive, non-idempotent mutation, and the description stays consistent with that. It adds genuinely useful behavior the annotations cannot express: unresolved closure conditions cause a refusal, and the forced path leaves a trace. What it omits is the consequence of a refusal (state left unchanged?) and how the recorded outcome surfaces afterward.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action, and each clause carries distinct information about preconditions or sequencing. The phrase 'with outcome/next' is slightly compressed but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-parameter stack mutation with no output schema, the description covers purpose, refusal semantics, and repeat-call conditions. The main remaining gap is that the force parameter's trade-off is only hinted at through 'resolved conditions refuse', leaving the agent to consult the schema for what forcing actually records.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines next, force, and outcome in detail; baseline 3 applies. The description's 'return to its parent with outcome/next' reinforces that both fields travel to the parent, but it says nothing extra about force or the 'Record:' convention for outcome.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Close completed focus') plus the resulting effect ('return to its parent'), which is well beyond the tautological title. It never names its obvious counterpart vivac_push by name, so an agent must infer the push/pop pairing from the stack metaphor rather than from explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real when-not guidance ('do not pop merely to clear the stack') and a precondition for repeated invocation ('Pop again only if the parent is also settled'). It stops short of naming alternatives such as vivac_done or vivac_park for finishing work without unwinding the stack, which would have made routing unambiguous.

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

Deploy Server

Other Tools