Skip to main content
Glama

ck_review_feedback

Approve or deny a submitted review, attach feedback notes or structured annotations, and unblock or halt the execution gate so agent plans proceed only when authorized.

Instructions

Approve or deny a submitted review and attach feedback notes or structured annotations. Write operation — updates the review record and unblocks or halts the execution gate. review_id (required) is the ID returned by ck_review_submit. decision must be approved or denied. feedback_notes is freeform text for the reviewer's rationale. annotations is a key-value object for machine-readable metadata. This tool is human-facing: agents call ck_review_submit to create a review, then a human (or authorized agent) calls ck_review_feedback to record the decision. After approval, the submitting agent can proceed with execution; after denial, the plan should be revised and resubmitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
decisionYesGovernance decision: allow, warn, block, or escalate to human.
review_idYesUnique identifier of the review to query or act on.
session_idNoOptional session scope: when supplied, decisions on a review from another session are denied instead of applied.
annotationsNoStructured key-value annotations for machine-readable metadata.
reviewed_byNo
feedback_notesNoFreeform feedback notes from the reviewer.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
updatedNo
decisionNo
review_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.13
    • addedInput schema / properties / session_id
      Added value: +{
      +  "description": "Optional session scope: when supplied, decisions on a review from another session are denied instead of applied.",
      +  "type": [
      +    "integer",
      +    "string"
      +  ]
      +}
  2. Addedv0.3.81
  3. Removedv0.3.73
  4. Changed1 schema field changedv0.3.38
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "decision": {
      +      "type": "string"
      +    },
      +    "review_id": {
      +      "type": "integer"
      +    },
      +    "updated": {
      +      "type": "boolean"
      +    }
      +  },
      +  "type": "object"
      +}
  5. Addedv0.3.27
  6. Removedv0.3.25
  7. Changed4 schema fields changedv0.3.17
    • addedInput schema / properties / annotations / description
      Added value: +"Structured key-value annotations for machine-readable metadata."
    • addedInput schema / properties / decision / description
      Added value: +"Governance decision: allow, warn, block, or escalate to human."
    • addedInput schema / properties / feedback_notes / description
      Added value: +"Freeform feedback notes from the reviewer."
    • addedInput schema / properties / review_id / description
      Added value: +"Unique identifier of the review to query or act on."
  8. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as a non-read-only, non-idempotent, non-destructive write. The description adds that it updates the review record, unblocks or halts an execution gate, is human-facing, and has different downstream consequences for approval versus denial. This is rich behavioral context beyond the structured hints.

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 description is front-loaded with purpose and write behavior, then moves to parameters and workflow. It is somewhat long and repeats the approved/denied constraint, but most sentences add useful usage or consequence context.

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 human-in-the-loop write tool with an output schema, the description supplies the full workflow, required inputs, and the approval/denial consequences. Remaining omissions like session_id semantics are minor and largely covered by the schema.

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 description coverage is 83% and already documents most parameters, but the description adds that review_id comes from ck_review_submit, that decision must be approved or denied, that feedback_notes is reviewer rationale, and that annotations are machine-readable metadata. It does not cover session_id or reviewed_by, so it enhances rather than fully replaces the schema.

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 action: approve or deny a submitted review and attach feedback notes or annotations. It clearly distinguishes this decision-recording tool from ck_review_submit (creation) and ck_review_status (query) by naming the review lifecycle context.

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?

Explicitly says this tool is human-facing and that agents call ck_review_submit first, then a human or authorized agent records the decision here. It also describes what to do after approval or denial, giving clear when-to-use and next-step guidance.

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