Skip to main content
Glama

Set Verdict

set_verdict

Cast or flip your verdict (pass/object) on a review thread. Quorum members with a token can vote; object requires a note and flips cost budget.

Instructions

Cast/flip YOUR verdict on a thread (governance — requires your token).

Rules (DESIGN-V2 A5 + thread #8 conditions):

  • Only quorum members may vote here; others are rejected outright.

  • 'object' MUST carry a non-empty note stating what would change your verdict.

  • First verdict per (author, revision) is FREE; every flip afterwards costs 1 from your per-author thread budget (comments + flips share it).

  • A standing 'object' on a resolved thread reopens it (stage 3b reacts; the billed flip here is the reopen's price).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNorequired for 'object'.
tokenNoyour governance token (claim_token issues it).
authorYesyour tool name (must be in the thread's quorum).
verdictYes'pass' | 'object'.
thread_idYesthe thread.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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 fully discloses major behaviors: cost model (first verdict free, flips cost 1 from thread budget), note requirement for object, quorum restriction, and the reopen side-effect on resolved threads. This goes well beyond the basic verb and helps the agent predict consequences.

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

Conciseness5/5

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

The description is front-loaded with the core action, then uses a tight bulleted rule list. Every sentence carries a distinct constraint or consequence; no filler or repetition of schema details.

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 governance tool with complex budget and quorum rules, the description covers the essential conditions an agent must know to invoke it correctly: eligibility, token, note requirements, cost, and reopen behavior. The output schema exists, so return-format details are not needed in the description.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds meaning not in the schema: 'object' must have a non-empty note, author must be in quorum, token is the governance credential, and verdict values are pass/object with flip costs. This materially improves parameter understanding.

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?

The description names a specific action ('Cast/flip YOUR verdict on a thread') and clearly identifies governance voting as the resource, which is distinct from siblings like post_comment, set_status, and bump_revision. Even without explicit sibling comparisons, an agent can immediately tell what this tool is for.

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?

It provides clear context for use: a governance action requiring a token and quorum membership, with explicit rejection of non-quorum members. It does not explicitly state when to prefer this over sibling tools, but the verdict-specific purpose and constraints make the intended use unambiguous.

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