Skip to main content
Glama
DanceNitra

inspeximus

by DanceNitra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

credit

Update memory track records with real verdicts on recalled work. Pass memory IDs and outcome (good/bad) to adjust future recall ranking by accuracy. Include a warrant for external verification to prevent self-graded outcomes.

Instructions

Close the accuracy loop: when the work some recalled memories fed gets a real verdict — a forecast resolves, a claim is ruled correct/wrong, a plan succeeds/fails — call credit(those ids, outcome) so each memory's track record updates. Future recall then ranks by WAS-IT-RIGHT (a Beta good/bad posterior), not merely by being-recalled. outcome: 'good'/'right'/'correct' vs 'bad'/'wrong'/'failed' (or pass a bool / a signed number, as JSON or as text such as "+1"); any other word is refused, never guessed. Counts only grow: a negative weight is refused. Raw text is never edited. Returns what updated, once it is in the store file.

warrant NAMES THE EXOGENOUS ARTIFACT that produced the verdict — a resolved ticket, a graded forecast, an external run: ground truth the credited memory did NOT author itself. Only a warranted good raises good_warranted, which credit_requires_warrant counts to block the MINJA self-graded-outcome loop (an agent crediting its own recalled poison as a success).

It exists on this surface because it did not, and that was the whole bug. The library has accepted warrant= all along; this tool dropped it, so every credit an agent could make over MCP was unwarranted BY CONSTRUCTION. Measured 2026-08-09 on a real deployment: good on 470 records, good_warranted on 0 of 220,213. Same shape as with_warrant missing from recall — the mechanism works given its input, and the surface never delivered the input.

PASS IT ONLY FOR A RE-CHECKABLE ARTIFACT. Empty is the correct value when you graded the outcome yourself; a token invented to make the field non-zero forges precisely the signal the guard tests.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsYes
weightNo
outcomeYes
warrantNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.12.0
    • addedInput schema / properties / outcome / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  }
+]
    • removedInput schema / properties / outcome / type
      Removed value: -"string"
  2. Changed1 schema field changedv2.20.1
    • addedInput schema / properties / warrant
      Added value: +{
+  "default": "",
+  "title": "Warrant",
+  "type": "string"
+}
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: unknown outcome words are refused and never guessed, negative weights are refused, counts only grow, raw text is never edited, and the function returns what updated after persistence. It also reveals the MINJA self-grading loop concern and how good_warranted is used by credit_requires_warrant.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The operational guidance is front-loaded and useful, but the description becomes digressive with a narrative paragraph about the historical bug, deployment measurements, and rhetorical flourishes like 'forges precisely the signal the guard tests'. While motivating, that context does not help an agent invoke the tool correctly and should be trimmed.

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?

For a 4-parameter tool with no annotations and no output schema, this description covers all critical invocation details: required ids and outcome, accepted outcome encodings, weight semantics, warrant semantics, error behavior, and return timing. The only mild gap is the exact shape of the return value, but 'Returns what updated, once it is in the store file' is sufficient for agents using this as a write-path feedback tool.

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 description coverage is 0%, so the description must compensate fully. It does: outcome synonyms are enumerated, bool/signed-number/text forms are given, weight constraints are stated, and warrant's meaning as an exogenous re-checkable artifact is explained. Even ids are tied to 'those ids' from recalled memories, giving operational context beyond the bare array schema.

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: call credit(ids, outcome) when recalled memories' work gets a real verdict, updating each memory's track record and influencing future recall. It distinguishes this from recall by explaining the feedback/accuracy-loop role, so an agent can tell it apart from siblings like recall, verify_claim, and remember.

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?

It gives explicit when-to-use guidance (only after a real verdict resolves), exact accepted outcome forms, and strong when-not-to-use guidance for warrant ('PASS IT ONLY FOR A RE-CHECKABLE ARTIFACT. Empty is the correct value when you graded the outcome yourself'). It also warns against fabricating warrants, which is precisely the kind of usage boundary agents need.

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