Skip to main content
Glama

aiworkhub_manager_review_finding_dispose

Record an audited confirmation or dismissal of a reviewer finding, requiring counter-evidence for dismissal and contract citations for HIGH findings while keeping an idempotent receipt.

Instructions

MANAGER WRITE: record one audited disposition of one reviewer finding.

dismissed needs non-empty counter_evidence and lifts that finding's refinement_required blocker at accept. A HIGH finding may only be dismissed, and its counter_evidence must cite the contract (a path:line or card:/kb: quote; otherwise review_finding_disposition_contract_citation_required); the receipt is manager_signed. A CRITICAL finding can never be disposed. A replay is idempotent; changing a disposition needs a reason and keeps the prior receipt in history. Frozen once the target is accepted. Bound server-side to the reviewer receipt and candidate digest; never edits the report or accepts the target.

Reproduction runs only on dismissal. When the finding's reproduction is a spec (pytest: or probe:) and the disposition is dismissed, the coordinator first runs it in the validation sandbox on the candidate and on its base, and stores the signed receipt with the disposition. A confirmed disposition needs no proof and never runs it. Only a failed test, or a probe's assertion failure or explicit exit 1, counts as failed; any other error is unrunnable. A reproduced finding can be dismissed only when counter_evidence cites the contract as for HIGH (manager_signed); otherwise review_finding_reproduced_not_dismissable and nothing is stored. not_reproduced or pre_existing may replace counter_evidence for a LOW/MEDIUM finding (HIGH still needs the citation, CRITICAL never); unrunnable changes nothing. A replay reuses the stored receipt.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>",
      "request_id": "<request_id>",
      "reviewer_request_id": "<reviewer_request_id>",
      "finding_id": "<finding_id>",
      "disposition": "<disposition>"
    },
    "name": "aiworkhub_manager_review_finding_dispose"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonNoFree-text reason recorded with the disposition; required to change an existing disposition.
task_idYesId of the target task card whose reviewer finding is being disposed.
finding_idYesId of the reviewer finding to dispose, e.g. reviewer:<lens>:<id>.
request_idYesId of the target worker request the reviewer examined.
dispositionYesconfirmed keeps the finding as a real defect; dismissed rejects it, needs counter_evidence, and lifts that finding's refinement_required blocker at accept (HIGH needs a contract citation; CRITICAL never).
counter_evidenceNoEvidence that the finding is wrong; must be non-empty when disposition is dismissed, unless a not_reproduced or pre_existing reproduction receipt stands in for a LOW/MEDIUM finding.
reviewer_request_idYesId of the verified reviewer request that reported the finding; it must be bound to the target request.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.84
    • changedInput schema / properties / counter_evidence / description
      Previous value: -"Evidence that the finding is wrong; must be non-empty when disposition is dismissed."New value: +"Evidence that the finding is wrong; must be non-empty when disposition is dismissed, unless a not_reproduced or pre_existing reproduction receipt stands in for a LOW/MEDIUM finding."
  2. Changed1 schema field changedv0.12.80
    • changedInput schema / properties / disposition / description
      Previous value: -"confirmed keeps the finding as a real defect; dismissed rejects it, needs counter_evidence, and lifts only a LOW/MEDIUM finding's refinement_required blocker at accept."New value: +"confirmed keeps the finding as a real defect; dismissed rejects it, needs counter_evidence, and lifts that finding's refinement_required blocker at accept (HIGH needs a contract citation; CRITICAL never)."
  3. Changed1 schema field changedv0.12.74
    • changedInput schema / properties / reason / description
      Previous value: -"Optional free-text reason recorded with the audited disposition."New value: +"Free-text reason recorded with the disposition; required to change an existing disposition."
  4. Changed7 schema fields changedv0.12.67
    • addedInput schema / properties / counter_evidence / description
      Added value: +"Evidence that the finding is wrong; must be non-empty when disposition is dismissed."
    • addedInput schema / properties / disposition / description
      Added value: +"confirmed keeps the finding as a real defect; dismissed rejects it, needs counter_evidence, and lifts only a LOW/MEDIUM finding's refinement_required blocker at accept."
    • addedInput schema / properties / finding_id / description
      Added value: +"Id of the reviewer finding to dispose, e.g. reviewer:<lens>:<id>."
    • addedInput schema / properties / reason / description
      Added value: +"Optional free-text reason recorded with the audited disposition."
    • addedInput schema / properties / request_id / description
      Added value: +"Id of the target worker request the reviewer examined."
    • addedInput schema / properties / reviewer_request_id / description
      Added value: +"Id of the verified reviewer request that reported the finding; it must be bound to the target request."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the target task card whose reviewer finding is being disposed."
  5. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Well beyond the annotations (readOnly=false, destructive=false, openWorld=false): discloses that replay is idempotent, that changing a disposition needs a reason and retains the prior receipt in history, that receipts are manager_signed, that the call is bound server-side to the reviewer receipt and candidate digest, and that the coordinator runs a reproduction in the validation sandbox. Also explains the ownership model (never edits report, never accepts target), which is exactly the side-effect profile a caller needs.

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

Conciseness3/5

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

Front-loaded with the core statement, which is good, but the reproduction paragraph is dense and re-states the counter_evidence citation rule already given earlier ("otherwise review_finding_reproduced_not_dismissable"), and the run-on sentences about confirmed/dismissed dispositions force re-reading. The content earns its place but the ordering could be tightened considerably.

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 7-parameter manager write with an output schema (so return values need no explanation), the description covers preconditions, failure codes, idempotency, immutability after accept, sandbox reproduction behaviour, and the exact conditions under which each disposition may be recorded. Nothing an agent needs before calling it is missing.

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 already 100%, so the baseline is 3; the description adds conditional semantics on top, notably the HIGH-only contract-citation requirement on counter_evidence, the reason requirement for changing an existing disposition, and the rule that not_reproduced/pre_existing receipts may substitute for counter_evidence on LOW/MEDIUM findings. It does not, however, say anything about how finding_id or reviewer_request_id are formed or validated beyond what the schema states.

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?

Opens with a specific verb+resource+scope ("record one audited disposition of one reviewer finding") and immediately bounds it against neighbours by stating it "never edits the report or accepts the target", which separates it from accept/reject-review siblings. An agent can identify the operation without opening the schema.

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 rich when/when-not rules per disposition: dismissed requires counter_evidence and lifts the blocker, confirmed needs no proof, HIGH may only be dismissed with a contract citation, CRITICAL can never be disposed, and the tool is frozen once the target is accepted. It does not explicitly name an alternative tool to use for the accept path, so routing guidance is implied by exclusion rather than stated as a sibling choice.

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