Noticer Receipt Maker for MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| noticer_commercial_accountA | After enrollment, read how many free checks remain. No charge. |
| 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. |
| 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. |
| noticer_receipt_statusA | Poll (at least 3 s apart). A verdict shown here is unverified; don't continue a workflow on status alone. |
| 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. |
| noticer_enroll_commerceA | Enroll once when the owner chooses commercial public-JSON checks and needs commerce-only access. |
| noticer_payment_challengeA | Get exact one-order payment terms only after the owner approves USD 1 for an eligible saved receipt. |
| noticer_pay_with_existing_linkA | Pay for one eligible saved receipt only after separate exact USD 1 consent using an existing authorized Link wallet. |
| noticer_initialize_localA | Set up local private custody after the owner chooses Noticer and explicitly consents to local setup. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
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.
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.
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.
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.