Skip to main content
Glama
zensteagarden

Noticer Receipt Maker for MCP

by zensteagarden
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

noticer_get_verified_receipt

Idempotent

Verify a signed receipt locally against pinned key, order, scope, freshness, and package binding. Fresh valid PROVED permits continue; DISPROVED blocks; INCONCLUSIVE holds.

Instructions

Verify the signed receipt locally. Only fresh, valid PROVED (control matched) supports continuing. DISPROVED or INCONCLUSIVE means the result isn't confirmed. The signature authenticates the issuer, not source honesty.

    Use a stable caller-local decision_ref for that intended next action. Verifies two byte-identical
    retrievals against the independently pinned key, order, saved scope, freshness and package binding.
    Returns a verified receipt verdict and locally derived decision: fresh valid PROVED/ALLOW may yield
    continue/0; DISPROVED yields block/20; INCONCLUSIVE yields hold/21 and a blocking server gate.
    Invalid, stale, mismatched or untrusted evidence is rejected, never converted to continue.
    
    Raw evidence and capabilities remain encrypted locally. The local decision is unsigned and does not
    grant permission or execute a downstream action. A signature authenticates the issuer, not source honesty.

Input Schema

NameRequiredDescriptionDefault
check_labelYes
decision_refYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2-dev.20261016

TDQS

A3.6/5.0
Behavior5/5

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

It discloses substantial behavior beyond the annotations: two byte-identical retrievals are verified against a pinned key, invalid/stale/mismatched/untrusted evidence is rejected rather than converted to continue, INCONCLUSIVE yields a blocking server gate, raw evidence remains encrypted locally, and the local decision is unsigned and does not execute downstream actions.

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 description front-loads the verification purpose and decision outcomes, but it is long and repetitive, especially the repeated statement that a signature authenticates the issuer rather than source honesty. Some sentences could be tightened without losing substance.

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 complex cryptographic verification tool with an output schema, the description covers the decision states, rejection behavior, trust boundaries, and non-execution limits well. The main gap is the unexplained check_label parameter and the absence of explicit sibling routing guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 carry parameter meaning. It explains decision_ref as a stable caller-local reference for the intended next action, but it never explains what check_label means or how it affects verification.

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 states the action: locally verify a signed receipt and return a verified receipt verdict plus local decision. It is specific about the resource and outcome states, but it does not explicitly differentiate itself from siblings such as noticer_receipt_status or noticer_run_receipt.

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?

The description implies usage through the PROVED/DISPROVED/INCONCLUSIVE decision flow and says to use a stable caller-local decision_ref for the intended next action. However, it does not explicitly say when to call this tool versus preparing, running, or checking receipt status, and it gives no 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