Skip to main content
Glama
coz-a

severally

by coz-a
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Record what checking a point showed

consult_record
Idempotent

Record verdicts and evidence for consult_get point IDs to preserve checked findings and decision impact across follow-ups. Reusing an ID replaces its prior entry.

Instructions

Save checks against point IDs from consult_get: f1 (finding), u1 (unknown), c1 (next check). verdict = confirmed/not_applicable/unverifiable/unverified; effect = decision impact; note = checked evidence. Confirmed is not adoption. 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; only verdict/effect go to follow-ups. Optional reflection describes what the answer added over your prediction.

Input Schema

NameRequiredDescriptionDefault
job_idNothe job_id consult_get returned
entriesNo
recordsNoone per fan-out member, instead of job_id/entries/reflection
reflectionNowritten after reading the answer

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv2.6.1
    • 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"
-]
  2. Changed2 schema fields changedv1.4.1
    • 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"
  3. First observedv1.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing failure semantics ('invalid jobs/IDs prevent every write; write failures appear per job in results'), persistence ('saved history survives restart'), and downstream propagation ('only verdict/effect go to follow-ups'). It also disambiguates the verdict semantics ('Confirmed is not adoption'), which the annotations cannot convey.

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 primary action and token vocabulary, then layered with semantics, batching, and failure behavior in a tight ~110 words. The telegraphic clauses ('Confirmed is not adoption', 'Invalid jobs/IDs prevent every write') are dense but each carries distinct information rather than waste.

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 4-parameter tool with nested objects, no output schema, and a write annotation set, the description supplies the missing behavioral and failure context an agent needs. Return-value shape is only loosely gestured at ('write failures appear per job in results'), which keeps it from a 5.

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?

At 75% schema coverage the schema already documents job_id, id, note, effect, and reflection fields; the description still adds real meaning by defining effect as 'decision impact' and note as 'checked evidence', and by explaining verdict values inline. It does not cover limits like maxItems 100 entries or 9 records, so it falls short of full compensation.

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 and resource ('Save checks against point IDs') and immediately grounds it in the sibling that produces those IDs (consult_get), with concrete token formats f1/u1/c1. An agent can distinguish this from consult_get, consult_list, or consult_export without opening any 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?

Gives clear operating rules: 'Record only checked points' and 'same ID replaces its entry', plus a routing rule that fan-out batches go through 'records' rather than job_id/entries. It names consult_get as the upstream source but does not explicitly state when NOT to record or how this relates to consult_cancel/consult_list, so no true exclusions.

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

Deploy Server

Other Tools