Skip to main content
Glama

submit_verification_verdict

Submit a verifier's verdict on a pending finding to record evidence and update its status to confirmed, rejected, or ambiguous.

Instructions

Audit-plan only: submit the verifier's verdict on a pending-verification finding. verdict ∈ {confirmed, rejected, ambiguous}. Evidence (pre_output, post_output, etc.) is recorded into the verdicts table and the finding status transitions accordingly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
VerdictNo
EvidenceNo
as_agentNo
ClaimTokenYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the side effects — evidence is written to the verdicts table and the finding status transitions — but is silent on permissions, whether a verdict can be resubmitted or overridden, and what happens if the finding is not in a pending-verification state.

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?

Three tight sentences with the audit-plan scope front-loaded and no filler. It could be marginally tightened, but every clause carries information.

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?

For a mutation tool with no annotations and no output schema, the description covers the outcome side reasonably but omits the claim prerequisite, the meaning of ClaimToken, as_agent semantics, and error/retry behavior. An agent could invoke it but would likely guess at how to obtain a valid ClaimToken.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It supplies the allowed verdict values (confirmed, rejected, ambiguous) — which the schema itself lacks — and example Evidence keys, but leaves the required ClaimToken completely unexplained and adds nothing about as_agent. Half the parameters, including the only required one, remain undocumented anywhere.

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?

Specific verb (submit) plus resource (the verifier's verdict on a pending-verification finding), and the 'Audit-plan only' prefix scopes it well. It does not explicitly distinguish itself from close siblings like submit_attempt_verdict, submit_review_decision, or override_verdict, so an agent must infer the difference from the finding-state wording.

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 'Audit-plan only' constraint and 'pending-verification finding' precondition imply when the tool applies, but no alternatives are named and no explicit when-not guidance is given. Critically, it never says the finding must first be claimed via claim_next_finding_for_verification, which the sibling list suggests is a prerequisite.

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