Skip to main content
Glama

submit_scaffold_verdicts

Validate verdicts for scaffold compliance, attach a provenance stamp, and return the rendered checklist report as the only authoritative assessment output.

Instructions

Scaffold-mode completion: validate verdicts produced by the calling agent (leaf coverage, verdict vocabulary, mandatory verbatim evidence quotes resolved to spans) and return the stamped assessment TOGETHER WITH the finished, rendered deliverable. items is the verdict array from the forced tool call — one object per leaf with id, verdict, confidence, rationale, and (for reported/partial) evidence_quotes.

THE ARTIFACT OF RECORD is in the returned report (by default the HTML form), carrying a provenance stamp bound to the ingested text and prompt. That stamped render is the ONLY canonical output — present it as the completed checklist. Need another format? Do NOT hand-assemble one: call render_checklist (markdown) or render_checklist_docx (.docx bytes) to re-render the same stamped artifact, or pass report_formats (any of 'html', 'markdown', 'docx') to include them here. The default is HTML only because every extra format flows through your context window. The items verdicts are an intermediate object; do NOT hand-assemble your own checklist document and present it as the assessment, because it will lack the stamp and cannot be verified. You MAY additionally write an analytic memo (prioritized gaps, an estimand-first reading), but label it as commentary and cite the stamp — never let it stand in for, or inherit the authority of, the stamped form.

Set render=false to skip rendering (verdicts only). The parse cache does not survive a server restart; if text_sha256 is no longer cached, pass document (the same path or text) to re-parse transparently.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
modelNounspecified
renderNo
documentNo
text_sha256Yes
spec_versionNotarget-0.1.0
report_formatsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
itemsNo
modelNo
usageNo
reportNo
citationNo
documentsNo
assessed_atNo
prompt_hashNo
temperatureNo
text_sha256No
spec_versionNo
manuscript_idNo
excluded_leavesNo
section_rollupsNo
extractor_versionNo
supplement_statusNo
full_text_availableNo
prompt_template_versionNo
unresolved_evidence_leavesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the behavioral burden and fully discloses consequences: the only canonical output is the stamped report, extra formats increase context usage, parse cache is not persistent, and re-parsing can be triggered transparently via document. It also clarifies intended authority of analytic memos so agents do not substitute commentary for the stamped form.

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?

Long but tightly organized: the opening defines the operation, the middle establishes canonical output and exclusions, and the final paragraph covers rendering and caching edge cases. The emphasis markers and repeated no-hand-assembly warnings are intentional guardrails, not filler.

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?

Given the tool's complexity with 7 parameters, no annotations, and an output schema, the description supplies all essential operational context: return value identity, verification semantics, alternative format paths, and failure/recovery scenario for cache misses. Nothing needed to invoke it correctly is omitted.

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 0%, so the description must compensate. It does for the important parameters: items structure, text_sha256/document cache behavior, render false, and report_formats allowed values. It leaves model and spec_version semantically unexplained, though their defaults and titles reduce the risk.

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 opening states a specific action — validate verdicts and return the stamped assessment plus rendered deliverable — with clear scope (scaffold-mode completion). It also distinguishes itself from render_checklist/render_checklist_docx by naming them as the re-rendering route rather than hand-assembly.

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?

The description makes the when explicit: it is the forced completion call after verdicts are produced, and it gives explicit alternatives for format conversion (render_checklist, render_checklist_docx, report_formats) and for skipping rendering (render=false). It warns against hand-assembling the deliverable, which prevents a common misuse.

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