Skip to main content
Glama
Sign In
TimWongUp

AgentNave

by TimWongUp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Publish answers under review or keep them private

decide_answers
Idempotent

Atomically decide held answers: publish shares responses with peers while private keeps them between boss and seat; repeats are idempotent and changes are rejected.

Instructions

Decide held answers atomically: publish shares with peers; private keeps between boss and seat. Repeating a decision is idempotent; changing it is rejected. Parallel rounds commit after all decisions; serial rounds then start the next seat. Returns after local commit when no work/review remains: finished needs no further call; running/review requires wait.

Input Schema

NameRequiredDescriptionDefault
round_idYes
decisionsYesseat_id -> publish or private

Output Schema

NameRequiredDescriptionDefault
errorNo
statusYes
entriesYes
round_idYes
committedYes
decisionsYes
pending_reviewYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.49.0
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed3 schema fields changedv0.35.0
    • changedInput schema / $defs / Decision / enum
      Previous value: -[
-  "publish",
-  "discard"
-]New value: +[
+  "publish",
+  "private"
+]
    • changedInput schema / properties / decisions / description
      Previous value: -"seat_id -> publish or discard"New value: +"seat_id -> publish or private"
    • changedOutput schema / $defs / Decision / enum
      Previous value: -[
-  "publish",
-  "discard"
-]New value: +[
+  "publish",
+  "private"
+]
  3. Changed5 schema fields changedv0.31.0
    • addedOutput schema / $defs / CommittedEntryPayload
      Added value: +{
+  "properties": {
+    "kind": {
+      "enum": [
+        "task",
+        "answer",
+        "absent",
+        "forward",
+        "host"
+      ],
+      "title": "Kind",
+      "type": "string"
+    },
+    "message_id": {
+      "title": "Message Id",
+      "type": "string"
+    },
+    "round": {
+      "title": "Round",
+      "type": "integer"
+    },
+    "seat": {
+      "title": "Seat",
+      "type": "string"
+    }
+  },
+  "required": [
+    "message_id",
+    "kind",
+    "round"
+  ],
+  "title": "CommittedEntryPayload",
+  "type": "object"
+}
    • addedOutput schema / properties / entries
      Added value: +{
+  "items": {
+    "$ref": "#/$defs/CommittedEntryPayload"
+  },
+  "title": "Entries",
+  "type": "array"
+}
    • addedOutput schema / properties / error
      Added value: +{
+  "title": "Error",
+  "type": "string"
+}
    • addedOutput schema / properties / status
      Added value: +{
+  "enum": [
+    "running",
+    "review",
+    "finished",
+    "failed",
+    "cancelled",
+    "interrupted"
+  ],
+  "title": "Status",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "round_id",
-  "decisions",
-  "pending_review",
-  "committed"
-]New value: +[
+  "round_id",
+  "decisions",
+  "pending_review",
+  "committed",
+  "entries",
+  "status"
+]
  4. Addedv0.23.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: annotations already declare idempotentHint=true, but the description explains the exact semantics (repeat OK, change rejected), plus atomicity across seats, parallel-vs-serial commit ordering, and the post-commit finish-state contract. This is the kind of operational detail an agent cannot get from structured fields.

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?

Front-loaded with the action and its two outcomes, then the commit/return semantics. Dense and telegraphic ("finished needs no further call") but nearly every clause carries operational meaning; a slightly less clipped phrasing would read better without losing content.

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?

Given an output schema exists, return values needn't be spelled out, yet the description still supplies the commit-ordering and next-step state contract that the schema won't convey. The only real gap is round_id provenance and whether the decisions map must cover all held seats.

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

Parameters4/5

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

Schema covers decisions ("seat_id -> publish or private") but round_id has no description, giving 50% coverage. The description compensates by explaining what 'seat' means in context and the effect of each publish/private value, though it never clarifies round_id's role or how to obtain it.

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

Purpose5/5

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

States the specific verb (decide) and resource (held answers), and defines both enum outcomes inline: 'publish shares with peers; private keeps between boss and seat.' This differentiates it clearly from the other lifecycle siblings (run_round, wait, handover).

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 concrete decision-point rules: repeating a decision is idempotent, changing it is rejected, and 'running/review requires wait' explicitly routes the agent to the wait sibling when work remains. It does not enumerate every alternative (e.g. cancel/handover) but leaves little ambiguity about when to call this versus waiting.

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