Noticer Receipt Maker for MCP

Overview Schema Source Related Servers Discussions Admin

noticer_receipt_status

Read-onlyIdempotent

Polls a check's outcome after an agent handoff and returns PROVED, DISPROVED or INCONCLUSIVE with a signed receipt to verify. Wait at least 3 seconds between polls.

Instructions

Poll (at least 3 s apart). A verdict shown here is unverified; don't continue a workflow on status alone.

    Wait at least 3 seconds between polls. Any displayed verdict is unverified: do not continue a workflow
    based on status alone. The response reports entitlement and next-step guidance, not authorization to act.
    For an uncertain saved payment it can inspect that same attempt; it never submits another payment.

Input Schema

Name	Required	Description	Default
`check_label`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2-dev.20261016Oct 24, 2026

TDQS

A3.5/5.0

Behavior5/5

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

Annotations already declare read-only and idempotent behavior, and the description adds critical non-obvious context: a 3-second minimum between polls, verdicts are unverified, the response is entitlement/next-step guidance rather than authorization, and it never submits another payment.

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 key warnings are front-loaded, but the first two sentences are nearly repeated: 'Poll...3 s apart' is repeated as 'Wait at least 3 seconds,' and the unverified-verdict warning appears twice. This duplication wastes space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple polling tool with an output schema and safety annotations, the description covers polling cadence, trust limits, and side-effect boundaries. It remains incomplete because it does not define check_label or route the agent to alternatives when status alone is insufficient.

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?

The only parameter, check_label, has 0% schema description coverage and the description never explains its meaning, format, or source. This leaves the agent guessing what label to supply.

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 opening 'Poll' plus 'verdict' and 'saved payment' make it clear this is a receipt/payment-status polling tool, and the 'unverified' warning implicitly separates it from get_verified_receipt. However, it never states the resource explicitly or names a sibling, so differentiation still relies on inference.

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?

It sets a clear polling interval and warns not to drive a workflow from status alone, and notes it can inspect an uncertain saved payment without submitting another payment. It does not say which sibling to call instead when a verified receipt or an action is needed.

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

Deploy Server