Skip to main content
Glama
zensteagarden

Noticer Receipt Maker for MCP

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
noticer_commercial_setupA

Start here when an action you sent or delegated needs its result confirmed, your own tools can't confirm it, and the result is one field in public HTTPS JSON. Shows setup state and the published USD 1 price. Creates nothing.

    Returns local setup state, canonical terms location and published USD 1 receipt price without creating
    an account, order or payment. A missing local configuration does not prevent tool discovery.
    This is setup guidance, not a verified outcome or a guarantee of free eligibility.
noticer_commercial_accountA

After enrollment, read how many free checks remain. No charge.

    Use this to understand eligibility before preparing a public JSON check. Preparation reserves no
    allowance, and the finalized order entitlement remains authoritative. No payment is made and no
    credential is returned.
noticer_prepare_receiptA

Describe the destination state to check: the exact public JSON record (claim_id_path) that should show the result of the handed-off action, the expected value, and a known-good control on the same site. Only after owner authorization for public reads. Doesn't observe, charge or reserve an allowance.

    Only after owner authorization for these public reads. Inputs: a stable check_label and scope with
    claim_ref; questioned {url, extract, claim_id_path}; control {url, extract}; deadline_seconds;
    authorized_public_read=true. Both URLs must be public HTTPS JSON on the same host, with distinct
    paths and no credentials, query or fragment. The claim_ref must occur as a questioned path segment
    and not in the control path. Use a genuinely known-good control. Dotted paths support equality to a
    JSON scalar, for example extract '$.status == "shipped"' and claim_id_path '$.id'; this is not general
    JSONPath or code. deadline_seconds must be an integer from 20 through 120. Server validation is final.
    
    Returns the frozen scope, obligation hash, price and confirmation notice. No observation or payment
    occurs here; free allowance is not reserved. Show those terms and obtain separate explicit run approval.
    Reuse check_label with the identical scope after interruption; never create a new label to recover
    ambiguous preparation. No receipt is guaranteed for every failed request.
noticer_run_receiptB

Observe the saved public JSON condition only after approval of the exact frozen scope and confirmation notice. Reads only; it never pays or performs or repeats the original action.

    Supply its saved obligation_hash. Both booleans must reflect explicit owner approval, including
    possible free-check consumption; they are caller assertions, not independent proof of consent.
    Starts observation and returns a check identifier. It never pays or performs the downstream action.
    Evidence access may later require separate USD 1 approval. Poll status no more frequently than 3 seconds.
noticer_receipt_statusA

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.
noticer_get_verified_receiptA

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.
noticer_enroll_commerceA

Enroll once when the owner chooses commercial public-JSON checks and needs commerce-only access.

    First show https://noticer-mpp-ee54698-production.up.railway.app/start. Obtain host action-time approval
    for persistent commerce access and acceptance of terms before setting the consent booleans true.
    New self-service buyers receive five eligible free checks; later eligible receipts cost USD 1 with
    separate wallet approval. Enrollment itself never charges. Returns account-setup metadata while the
    credential and recovery secret remain in encrypted local custody. Booleans assert consent, not proof.
noticer_payment_challengeA

Get exact one-order payment terms only after the owner approves USD 1 for an eligible saved receipt.

    This prepares a public challenge, never a charge, and needs no wallet. Merchant and network must come from independently
    verified provider configuration. Returns bound challenge/endpoint metadata; order capability stays private.
    The separate optional existing-Link payment tool requires wallet approval. Never put SPTs, payment
    credentials or keys into tool arguments, chat, model output or logs.
noticer_pay_with_existing_linkA

Pay for one eligible saved receipt only after separate exact USD 1 consent using an existing authorized Link wallet.

    Show the merchant, network, one-time amount and saved challenge first. Present any returned Link approval_url;
    resume only the SAME check_label/request. Both local consent and the wallet's approval are required.
    This tool can submit a real payment; approval alone is not settlement and settlement is not verified evidence.
    
    Never install software, log in, switch payment methods, or create a replacement request after denial,
    expiry or an uncertain payment. Credentials remain private subprocess memory; only sanitized status and
    approval URL are returned. After settlement, use noticer_get_verified_receipt. No downstream action runs.
noticer_initialize_localA

Set up local private custody after the owner chooses Noticer and explicitly consents to local setup.

        Creates owner-only POSIX state/config and a random custody key with the canonical origin and independently
        pinned public signing key; no trust-on-first-use. Returns setup status, never secrets. Does not enroll,
        contact a server, pay, install software or sign in. Optionally discover an already installed trusted Link
        CLI only after consent. The key and encrypted records share one OS-user boundary; this does not protect
        against compromise of that same user.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 10 tools

Disambiguation3/5

The receipt lifecycle tools (prepare, run, status, get_verified) are reasonably distinct once you follow the workflow. However, three separate onboarding tools (commercial_setup, enroll_commerce, initialize_local) plus commercial_account all have subtly overlapping 'get started' purposes that an agent could easily confuse. The dense descriptions help, but boundaries between setup/account/enroll remain fuzzy.

Naming Consistency3/5

All tools share the 'noticer_' prefix and snake_case, which is good. But verb conventions are mixed: some are verb_noun (prepare_receipt, get_verified_receipt, run_receipt), while others are noun phrases (commercial_setup, receipt_status, payment_challenge) with no action implied. The pattern isn't predictable enough to infer behavior from the name.

Tool Count4/5

Ten tools is well within the appropriate range for a commerce-plus-receipt verification lifecycle. Each stage (setup, enrollment, prepare, run, status, verify, payment) roughly earns its place, though a couple of onboarding tools could arguably be consolidated.

Completeness4/5

The surface covers the full lifecycle end to end: local setup, enrollment, account eligibility, receipt preparation, observation, polling, verification, payment challenge, and payment. No obvious dead ends for the core flow, though error-recovery and cancellation paths are only implied through descriptions rather than dedicated tools.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive