Skip to main content
Glama
Sign In
DanceNitra

inspeximus

by DanceNitra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

provenance

Trace a fact's origin, lineage, and value history to verify its source and detect relabeling. Read-only; reports limits and withholds quarantined records by default.

Instructions

WHERE DID THIS FACT COME FROM — one answer, assembled from the whole record: the declared source and the lineage it inherited through summarization, whether an origin attestation bound it to a verified key, its evidence grade, every value it has held and WHICH policy retired each one, and whether it still matches the write receipt committed at write time (so a later relabel is loud). Pass key (the fact, across all its values) or id (one record). Read-only; the returned limits state honestly what this does NOT prove. A quarantined record's text and value are withheld, unless include_quarantined is set.

Input Schema

NameRequiredDescriptionDefault
idNo
keyNo
include_quarantinedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.20.0
    • addedInput schema / properties / include_quarantined
      Added value: +{
+  "default": false,
+  "title": "Include Quarantined",
+  "type": "boolean"
+}
  2. Addedv2.20.1

TDQS

A4.1/5.0
Behavior4/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 well: it declares read-only, discloses that quarantined records have text/value withheld unless `include_quarantined` is set, and notes the returned `limits` state honestly what is NOT proven. The only gap is it doesn't describe pagination or the shape of the write-receipt comparison result.

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 question, then structured to sweep the record's facets. It is dense and slightly long, but nearly every clause adds distinct semantic content; only the enumerated facet list borders on over-loading.

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 read-only, no-annotation, no-output-schema query tool, the description is nearly complete: it conveys what is assembled, the key/id selection, the quarantine withholding behavior, and the honest-limits return. Naming the returned `limits` without an output schema is a reasonable stand-in for return-value documentation.

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 coverage is 0%, so the description must compensate, and it largely does: `key` is defined as the fact across all its values, `id` as one record, and `include_quarantined` as the switch that releases withheld quarantined text/value. All three parameters get meaning beyond the bare schema, though defaults are not restated.

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?

Opens with a specific question ('WHERE DID THIS FACT COME FROM') and then enumerates exactly what the answer assembles: declared source, inherited lineage, origin attestation, evidence grade, value history with retiring policy, and write-receipt match. This precisely distinguishes it from siblings like `history` (values only), `get` (raw record), and `check_sources`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives parameter-selection guidance ('Pass `key` ... or `id` ...') and states the tool is read-only, which orients usage. However, it never explicitly states when to prefer this over the many similar-sounding siblings (`history`, `why_recalled`, `check_sources`, `check_conflict`); the routing is left implicit.

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