Skip to main content
Glama

verdict

Record supported, refuted, or inconclusive status for a hypothesis with optional evidence in one call; use record_check to attach evidence without changing status.

Instructions

Record supported, refuted or inconclusive plus optional evidence in one call. The rare record_check action attaches evidence without changing status.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
dataYes
stateYes
issuesYes
coverageNo
replayedYes
operationYes
request_idNo
api_versionYes
continuationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=false; the description adds real value by disclosing that status plus optional evidence can be written atomically in one call, and that record_check leaves status untouched. It still omits mutation-side behavior an agent would care about: whether an existing verdict is overwritten, how expected_revision conflicts surface, and how ambiguous NodeRef resolution errors behave.

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?

Two sentences, no filler, and the core operation is front-loaded before the exception branch. Every sentence contributes a distinct fact.

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

Completeness3/5

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

An output schema exists so return values need not be explained, and the two action branches are covered. But for a non-read-only mutation on a hypothesis node, the description says nothing about concurrency handling, overwrite semantics or initiative scope, which are the likely failure modes an agent needs to know.

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% and the $defs document NodeRef, Verdict and Evidence in detail, so the schema carries most of the load. The description adds only marginal semantics - that evidence is optional in the default branch - leaving expected_revision and request_id entirely to the schema text.

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 description pairs a specific verb ('Record') with the exact resource domain (supported/refuted/inconclusive verdicts) and mentions the second action variant 'record_check', so an agent knows this tool sets a hypothesis verdict. It does not distinguish itself from siblings such as claim, revise or review, leaving some ambiguity about which node-mutating tool to pick.

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

Usage Guidelines3/5

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

'The rare record_check action attaches evidence without changing status' gives a usable cue for choosing the non-default branch over the default 'decide'. However, there is no guidance on prerequisites (initiative scoping, when a verdict should be issued versus revised later) or on when to prefer siblings like revise or review.

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