severally

Overview Schema Source Related Servers Discussions Admin

Record what checking a point showed

consult_record

Idempotent

Record verdicts, decision impacts, and evidence notes for consulted point IDs to persist checked findings, unknowns, and next checks for follow-up.

Instructions

Save checks against point IDs from consult_get: f1 (finding), u1 (unknown), c1 (next check). verdict = confirmed/refuted/not_applicable/unverifiable/unverified; effect = decision impact; note = checked inputs, environment, evidence and limits. Confirmed is not adoption; refuted means the claim did not hold in the recorded check. Partial checks stay unverified with their scope in note. Record only checked points; same ID replaces its entry. Use records: [{ job_id, entries, reflection? }, ...] for one fan-out batch. Invalid jobs/IDs prevent every write; write failures appear per job in results. Saved history survives restart; verdict/effect and bounded new evidence notes go to follow-ups. Legacy notes remain local until recorded again. Optional reflection describes what the answer added over your prediction.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "consult_record"
  }
}

Input Schema

Name	Required	Description
`job_id`	No	the job_id consult_get returned
`entries`	No
`records`	No	one per fan-out member, instead of job_id/entries/reflection
`reflection`	No	written after reading the answer

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.11.0Oct 28, 2026

changedInput schema / properties / entries / items / properties / verdict / enum

Previous value: -[
-  "unverified",
-  "confirmed",
-  "not_applicable",
-  "unverifiable"
-]New value: +[
+  "unverified",
+  "confirmed",
+  "refuted",
+  "not_applicable",
+  "unverifiable"
+]

changedInput schema / properties / records / items / properties / entries / items / properties / verdict / enum

Previous value: -[
-  "unverified",
-  "confirmed",
-  "not_applicable",
-  "unverifiable"
-]New value: +[
+  "unverified",
+  "confirmed",
+  "refuted",
+  "not_applicable",
+  "unverifiable"
+]

Changed9 schema fields changedv2.6.1Oct 22, 2026

changedInput schema / properties / entries / items / properties / effect / description

Previous value: -"what it changed about your decision, or why it is still unverified"New value: +"what it changed, or why it is unverified"

changedInput schema / properties / entries / items / properties / id / description

Previous value: -"the point this verdict is about: f1, u1, c1 ... as returned in the result"New value: +"f1, u1, c1 ... from the result"

changedInput schema / properties / entries / items / properties / note / description

Previous value: -"what you checked and what you found"New value: +"what you checked and found"

changedInput schema / properties / job_id / description

Previous value: -"the consultation to record against -- the job_id consult_get returned for it"New value: +"the job_id consult_get returned"

addedInput schema / properties / records

Added value: +{
+  "description": "one per fan-out member, instead of job_id/entries/reflection",
+  "items": {
+    "properties": {
+      "entries": {
+        "items": {
+          "properties": {
+            "effect": {
+              "description": "what it changed, or why it is unverified",
+              "maxLength": 4000,
+              "type": "string"
+            },
+            "id": {
+              "description": "f1, u1, c1 ... from the result",
+              "minLength": 1,
+              "type": "string"
+            },
+            "note": {
+              "description": "what you checked and found",
+              "maxLength": 4000,
+              "type": "string"
+            },
+            "verdict": {
+              "enum": [
+                "unverified",
+                "confirmed",
+                "not_applicable",
+                "unverifiable"
+              ],
+              "type": "string"
+            }
+          },
+          "required": [
+            "id",
+            "verdict"
+          ],
+          "type": "object"
+        },
+        "maxItems": 100,
+        "minItems": 1,
+        "type": "array"
+      },
+      "job_id": {
+        "description": "the job_id consult_get returned",
+        "minLength": 1,
+        "type": "string"
+      },
+      "reflection": {
+        "description": "written after reading the answer",
+        "properties": {
+          "delta": {
+            "description": "what the answer added over what you expected (\"nothing new\" counts)",
+            "maxLength": 4000,
+            "minLength": 1,
+            "type": "string"
+          },
+          "related_item_ids": {
+            "description": "f1, u1, c1 ...",
+            "items": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "maxItems": 50,
+            "type": "array"
+          }
+        },
+        "required": [
+          "delta"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "job_id"
+    ],
+    "type": "object"
+  },
+  "maxItems": 9,
+  "minItems": 1,
+  "type": "array"
+}

changedInput schema / properties / reflection / description

Previous value: -"written 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."New value: +"written after reading the answer"

changedInput schema / properties / reflection / properties / delta / description

Previous value: -"what the answer added over what you already expected -- including \"nothing new\", which is a real outcome"New value: +"what the answer added over what you expected (\"nothing new\" counts)"

changedInput schema / properties / reflection / properties / related_item_ids / description

Previous value: -"the points this is about: f1, u1, c1 ..."New value: +"f1, u1, c1 ..."

removedInput schema / required
```
Removed value: -[
-  "job_id"
-]
```

Changed2 schema fields changedv1.4.1Oct 15, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / job_id / description

Added value: +"the consultation to record against -- the job_id consult_get returned for it"

First observedv1.1.0Sep 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: invalid jobs/IDs prevent every write (atomic validation), write failures surface per job in results (partial-failure semantics), history survives restart, verdict/effect feed follow-ups, and 'same ID replaces its entry' matches idempotentHint=true. This is exactly the context annotations cannot carry.

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?

Front-loaded with the core action and the ID provenance, and every sentence adds a constraint or semantic. It is a dense run-on block, though; breaking the verdict glossary and failure semantics into separate sentences or lines would improve scanability without padding.

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

Completeness4/5

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

For a nested, four-parameter mutation tool with no output schema, it covers atomicity, per-job failure reporting, persistence, and the batch alternative. Only the exact shape of the per-job results is left implicit.

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?

Adds real meaning beyond the 75%-covered schema: defines each verdict value ('confirmed is not adoption', 'refuted means the claim did not hold'), defines effect as decision impact and note as checked inputs/environment/evidence/limits. It also resolves the otherwise ambiguous mutually-exclusive top-level job_id/entries vs records shape.

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?

States a specific verb+resource: 'Save checks against point IDs from consult_get' with the f1/u1/c1 ID taxonomy spelled out. It is clearly the write counterpart to consult_get/consult_list among the siblings, and an agent can identify the operation without opening the schema.

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?

Explicitly says 'Record only checked points', explains when to use the 'records: [...]' form instead of job_id/entries/reflection (one per fan-out member), and clarifies that partial checks stay unverified. It doesn't explicitly contrast against consult_export/consult_cancel, but the usage conditions are clear.

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

Deploy Server