Skip to main content
Glama
adrianczuczka

mason

by adrianczuczka
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

review_decision

Prepare a decision review: returns the full record and history, any operative accepted revision, provenance, changes and previews for both sets of anchors, and a reviewToken.

Instructions

Prepare a decision review: returns the full record and history, any operative accepted revision, provenance, changes and previews for both sets of anchors, and a reviewToken. For accepted-guidance inspection use inspectionScope operative on both prepare and inspect; pending proposals remain unassessed. Default all scope covers both revisions. After source inspection, record inspect with inspector, note and token to report no contradiction found without human acceptance. For human review, prepare with all scope, then record accept, reaffirm, or retire with its token, the authorized reviewer, and a reason. Acceptance replaces the operative revision; retirement withdraws the entire record including its proposal. Acceptance requires owner, source, readable Git HEAD, and committed anchor changes. Changed records or code invalidate the token. Identities and approvals are recorded assertions for normal PR review, not authenticated proof.

Input Schema

NameRequiredDescriptionDefault
idYesDecision id from get_context or save_decision
dirYesAbsolute path to the project root directory
noteNoReview rationale; required for a verdict. Cite evidence for the decision.
actionNoPrepare is read-only. Inspect records an agent assessment without approval; accept, reaffirm and retire require an authorized review.prepare
reviewerNoIdentity of the actual reviewer; required for a verdict. Never invent one.
inspectorNoActual agent or person performing inspection; required for inspect. Does not claim human approval.
reviewTokenNoToken from the prepared review; rejects stale record or code revisions
inspectionScopeNoFor prepare/inspect only: all covers the full record and both anchor sets (default); operative covers only an active accepted revision, leaving a pending draft unassessed. Use the same scope when submitting its token.all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.22.0
    • changedInput schema / properties / action / description
      Previous value: -"Prepare is read-only. Other actions record an explicitly authorized review."New value: +"Prepare is read-only. Inspect records an agent assessment without approval; accept, reaffirm and retire require an authorized review."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "prepare",
-  "accept",
-  "reaffirm",
-  "retire"
-]New value: +[
+  "prepare",
+  "inspect",
+  "accept",
+  "reaffirm",
+  "retire"
+]
    • addedInput schema / properties / inspectionScope
      Added value: +{
+  "default": "all",
+  "description": "For prepare/inspect only: all covers the full record and both anchor sets (default); operative covers only an active accepted revision, leaving a pending draft unassessed. Use the same scope when submitting its token.",
+  "enum": [
+    "all",
+    "operative"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / inspector
      Added value: +{
+  "description": "Actual agent or person performing inspection; required for inspect. Does not claim human approval.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
  2. Addedv0.17.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so: it distinguishes read-only prepare from mutating actions, states that changed records or code invalidate the token, lists acceptance prerequisites (owner, source, readable Git HEAD, committed anchor changes), and spells out effects (accept replaces the operative revision; retire withdraws the entire record). It even discloses the trust caveat that identities and approvals are recorded assertions, not authenticated proof.

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?

The purpose is front-loaded and every sentence adds distinct information (returns, workflow, requirements, caveats) with no filler. It is dense and somewhat run-on, but given the multi-action complexity the density is largely earned.

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

Completeness5/5

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

There is no output schema and no annotations, yet the description explains the return payload (record, history, accepted revision, provenance, changes, previews, token), the action workflow, mutation effects, prerequisites, and the invalidation/trust caveats. An agent has essentially everything needed to call it correctly.

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 documents every parameter including tokens, scopes, and role-required fields. The description reinforces scope/token coupling and token staleness but adds little meaning that the schema does not already supply, so the baseline 3 applies.

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 opening clause states a specific verb+resource (prepare a decision review) and enumerates the payload (full record, history, operative revision, provenance, previews, reviewToken). It clearly covers the multi-action lifecycle of a decision record. It stops short of explicitly contrasting itself with siblings like save_decision or save_verification, so it earns a 4 rather than 5.

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

Usage Guidelines5/5

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

It routes the agent through concrete alternatives and conditions: use inspectionScope operative on both prepare and inspect for accepted-guidance inspection, record inspect to report no contradiction without human acceptance, and for human review prepare with all scope then accept/reaffirm/retire with the token. Each action's trigger condition is stated, leaving little to inference.

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