Skip to main content
Glama

mark_verdict

Records an agent's checked-work verdict as an AGENT diamond on a committed shape or sheet point, with an optional note; it changes no quantities.

Instructions

Mark the agent's VERDICT on work — the pencil half of the approval family, and the only half an agent can mint. Two actors exist on the record: the estimator's APPROVED ring is ink, minted solely by a human's click at the canvas's Approve tool; this tool mints the AGENT diamond and structurally nothing else — it takes no actor input to misuse. Target the work either way: shape_id anchors the mark ON a committed shape (a room at its area centroid, a run at its on-path midpoint, a count marker at its point) and records WHAT was marked — the shape_id stays on the record as provenance, and the glyph keeps its own anchor even if the shape is later deleted; or sheet + at drops the mark at a sheet point (image px). Exactly one target. Optional text rides the record through every export; the glyph itself always reads AGENT. A verdict touches no quantity and gates nothing: it is the agent's signed claim that it checked this work — pencil beside the estimator's ink, never in its place. The mark renders as the graphite AGENT diamond on the canvas and in the marked set, the marked-set cover tallies the split ("Approval stamps: N estimator-approved · M agent-marked"), and the record rides the annotations payload through export_takeoff / import_takeoff and the app's own saves. One mark per shape (re-mark = delete_verdict, then mark again); list_annotations returns the inventory in verdicts[]; undo_last steps over a mark exactly like any other mutation. Coordinates are image px at render scale 2.0: PDF pt × 2, origin top-left, y down (the browser canvas's native space). Sheet payloads carry dims in both px and pt.

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": "mark_verdict"
  }
}

Input Schema

NameRequiredDescriptionDefault
atNoSheet-point mode: where the AGENT diamond renders (image px)
textNoOptional short note riding the record and every export — the glyph always reads AGENT
sheetNoSheet-point mode: the sheet, together with at
shape_idNoMark a committed shape (list_shapes has the ids) — anchored on the shape, recorded as provenance. Exactly one target: this OR sheet + at

Output Schema

NameRequiredDescriptionDefault
atNoWhere the AGENT diamond renders (image px) — absent only when the marked shape rides a sheet from a file this session hasn't loaded (#152)
idYesThe minted record id ("apr-…")
tsYesISO-8601 mint time
noteYes
textNo
actorYesAlways agent — this tool is structurally incapable of minting the estimator's seal
sheetYes
shape_idNoShape mode: the committed shape this verdict is about
conditionNoShape mode: the marked shape's finish tag, resolved

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.31
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / at / additionalItems
      Added value: +false
    • addedOutput schema / properties / at / additionalItems
      Added value: +false
  2. Addedv0.1.12

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses that the actor is fixed to AGENT and cannot be set by input, that shape_id survives shape deletion as provenance, that one mark per shape is allowed, how undo_last treats it, and that the record rides the annotations payload through export/import. Coordinate space (image px, scale 2.0, origin top-left, y down) is spelled out.

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 core action, then targeting, then behavior; the ordering is logical. It is dense and runs long, with rhetorical metaphor ('pencil beside the estimator's ink') and a full rendering/export paragraph that could be tightened without losing information.

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?

For a 4-param mutation tool with no annotations, nearly everything an agent needs is present: target modes, immutability of the actor, one-per-shape limit, undo interaction, export persistence, and coordinate conventions. An output schema exists, so return-value detail is correctly left out.

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 coverage is 100%, so baseline is 3, and the description earns above that by explaining anchor semantics for shape_id (area centroid, on-path midpoint, point marker) and for sheet + at, plus the exact-one-target constraint. The text parameter's export-riding behavior is also clarified beyond the schema wording.

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 a specific verb and resource ('Mark the agent's VERDICT on work') and immediately differentiates it from the estimator's APPROVED ring, which only a human can mint. It also implicitly separates itself from delete_verdict by naming re-marking as delete-then-mark.

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?

Gives explicit targeting rules ('Target the work either way... Exactly one target'), the re-mark path ('re-mark = delete_verdict, then mark again'), and discovery routes (list_shapes for ids, list_annotations for inventory). It also states what the tool does NOT do ('touches no quantity and gates nothing'), which is genuine when-not guidance.

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