Skip to main content
Glama

Record what checking a point showed

consult_record

Save your verdict for each checked point of a consultant answer, with evidence and effect, so the decision stays readable later. Re-recording an id replaces the old entry.

Instructions

Write your own verdict against one or more points of an answer, after you have checked them in the repository. Ids come from the result: findings are f1, f2 ..., unknowns u1 ..., next_checks c1 ... . verdict says what checking showed -- "confirmed" (it holds here), "not_applicable" (true in general, not for this codebase), "unverifiable" (cannot be settled with what you can reach), "unverified" (not checked yet, and say in effect why not). It does not say whether you adopted the point. effect is what it changed about your decision; note is the evidence you used. Recording the same id again replaces that entry. This server stores what you write and counts the verdicts; it never infers one, and never decides a consultation was worth it. The entry is saved beside the answer and the brief in ~/.severally/history, which is what makes the decision readable a month from now; the job is read back from that history, so a consultation from an earlier session can still be recorded against. Pass reflection to record what the answer added over what you already expected, when the consultation was started with a prediction. A prediction itself cannot be written here: it goes in consult_start, before the consultant runs, which is the only thing that makes it a prediction.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes
entriesNo
reflectionNowritten after you have read the answer. There is deliberately no hit/miss label: a point you predicted can still arrive with the evidence that settles it, and a surprise can still be wrong.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that the server stores entries, overwrites on duplicate ids, never infers verdicts, and persists to ~/.severally/history, enabling cross-session recording. This goes well beyond the schema.

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 long but information-dense. Each sentence contributes to understanding the tool's behavior, id conventions, verdict meanings, and storage details. It is front-loaded with the core purpose and avoids fluff, though it could be slightly tightened without losing value.

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 (nested entries, reflection object, multiple verdicts, no output schema), the description covers all necessary details: id format, verdict semantics, overwrite behavior, persistence location, cross-session support, and reflection conditions. Nothing an agent needs to call it correctly is missing.

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?

Schema coverage is only 33% (only reflection has a description). The description compensates fully by explaining what entries contain, the meaning of each verdict value, what effect and note represent, and when reflection should be used. It adds meaning that the schema omits.

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 clearly states the action (write a verdict), the resource (points of an answer), and the context (after checking them in the repository). It differentiates from siblings by explicitly noting that predictions belong in consult_start, not here.

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?

The description explains when to use the reflection parameter (when started with a prediction) and explicitly excludes writing predictions here, pointing to consult_start. It also indicates the id source from the result. It doesn't explicitly contrast with consult_get or consult_export, but the usage context is fairly clear.

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