Skip to main content
Glama
Sign In
vivac

vivac

by JAAvila-Of
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Park a node: not now

vivac_park

Park work someone asked to defer and record their reason, optionally with a return date so it rejoins the brief; add the node first if it is missing.

Instructions

Park work the person said to defer, with their reason; optional until returns it to the brief on that date. If no node exists, add it first. Never invent deferral or reopen parked work unasked.

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_park"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoNode ID or alias, e.g. t4.
untilNoReturn date (YYYY-MM-DD); omitted means no scheduled return.
reasonNoWhy this choice or deferral, not just its result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.22.1
    • changedInput schema / properties / id / description
      Previous value: -"The node to park. Defaults to the current focus."New value: +"Node ID or alias, e.g. t4."
    • changedInput schema / properties / reason / description
      Previous value: -"Why it waits: the person's own words when they said not now. Read back verbatim under DO NOT TOUCH NOW."New value: +"Why this choice or deferral, not just its result."
    • changedInput schema / properties / until / description
      Previous value: -"YYYY-MM-DD, a day after today: the node comes back in vivac_brief under BACK FROM PARKED on that day. Leave it out to park with no return date."New value: +"Return date (YYYY-MM-DD); omitted means no scheduled return."
  2. Changed1 schema field changedv0.17.4
    • addedInput schema / properties / until
      Added value: +{
+  "description": "YYYY-MM-DD, a day after today: the node comes back in vivac_brief under BACK FROM PARKED on that day. Leave it out to park with no return date.",
+  "type": "string"
+}
  3. First observedv0.17.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already signal a non-read-only, non-idempotent, non-destructive mutation, so the safety bar is partly covered. The description adds real behavioral substance beyond that: the deferral removes the item from the brief and an 'until' date auto-returns it, and the reason must come from the person rather than be fabricated. It omits any note on permissions or how a park is later undone.

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 tight clauses with the core action front-loaded and no filler. The middle clause ('optional until returns it to the brief on that date') is grammatically compressed to the point of being slightly cryptic on first read, which costs it a point.

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 three-parameter, no-required-field mutation with no output schema, the description covers the action, the effect of the optional date, the prerequisite, and the constraint against fabricated deferrals. What remains uncovered — return shape and the exact unpark path — is modest, but not fully implied by the annotations.

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 all three parameters (id, until, reason) are already documented, making the baseline 3. The description reinforces the semantics — 'with their reason' clarifies the reason must be user-sourced, and 'optional until' matches the nullable return date — but adds no format or edge-case detail beyond the schema.

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 opens with a specific verb and effect: 'Park work the person said to defer' — parking means deferring a node, and the title reinforces it. It implicitly touches siblings ('If no node exists, add it first' relates to vivac_add; 'reopen parked work' relates to vivac_open) but never names an alternative, so the differentiation is inferential 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.

Usage Guidelines4/5

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

Gives a clear trigger ('work the person said to defer') plus a guardrail ('Never invent deferral') and an explicit exclusion ('reopen parked work unasked'), which is stronger than most. It stops short of 5 because it never names the sibling tool to use instead for the reopen/add case, leaving that routing to inference from the sibling list.

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