Skip to main content
Glama
DanceNitra

inspeximus

by DanceNitra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

credit

Record real-world verdicts (good/bad) to update memory track records, so future recall ranks by accuracy. Attach an external warrant to verify the outcome.

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). Counts only grow; raw text is never edited. Returns what updated.

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. Changed1 schema field changedv2.20.1
    • addedInput schema / properties / warrant
      Added value: +{
+  "default": "",
+  "title": "Warrant",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.3/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 does so thoroughly: it states that counts only grow, raw text is never edited, returns what updated, and explains the warrant mechanism and why it blocks self-grading loops. It even discloses historical failure context. No contradiction with annotations exists.

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 first paragraph is front-loaded and efficient, but the description becomes verbose with bug-history narrative and deployment metrics that do not directly help an agent invoke the tool. The warrant warning is valuable; the historical measurements are not. It is comprehensive but not tightly edited.

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?

Given no annotations and no output schema, the description covers the core invocation contract, outcome value choices, warrant handling, side effects, and return behavior. It is nearly complete, but the missing semantics of the `weight` parameter and the exact shape of the returned update leave a small but real gap.

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 explains ids, outcome (including accepted synonyms, booleans, signed numbers), and warrant semantics in detail. However, the `weight` parameter is completely unmentioned, leaving a gap in an otherwise strong compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies a specific action: call credit with ids and an outcome to update each memory's accuracy track record, which future recall ranks by. It also names concrete trigger cases (forecast resolves, claim judged, plan succeeds/fails). It is not explicitly framed against sibling tools, but the operation is distinctive enough that an agent can tell it apart.

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 gives explicit when-to-use conditions: only when a real external verdict exists for work fed by recalled memories. It also gives a strong when-not-to-use rule: pass empty warrant when grading the outcome yourself, and warns against inventing tokens. This is exactly the kind of guidance an agent needs to avoid misuse.

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