Provides exactly-once execution for Stripe payments, verifying via Stripe's API that a charge was recorded exactly once and detecting duplicate or rogue charges.
Public register: the Retry-Safety Index lists which agent-payment implementations pay once when the answer is lost — verified safe, found & fixed (with time-to-fix), and how to get verified. Every row links to its proof.
Your agents earn the right to spend without you.
Seal and EffectFence stop an irreversible action from firing twice while it happens — runtime enforcement on money movement. Coherence never touches your runtime; it reads the record afterwards and grades what an agent claimed against what it proved. Prevention versus proof. Different problems, different code, no overlap.
Free: submit any client, facilitator, SDK or toolkit that moves money — yours or someone else's — and we read it and publish a verdict on the Retry-Safety Index at no cost. Findings come back with the mechanism, the file and line, and a failing test. You are counted, never named, until you ship a fix. Submit for grading →
Seal is an MCP server (seal-mcp, stdio, JSON-RPC 2.0) — and a Python
library. It gives an MCP host 12 tools for exactly-once execution of
irreversible actions: seal_propose, seal_execute, seal_paths (gateway
mode — the agent holds a single-use ticket, never the provider key), plus
seal_admit, seal_commit, seal_abort, seal_heartbeat, seal_get,
seal_verify, seal_incident_receipt, seal_expect, seal_obligations.
docker run -i ghcr.io/aurumflux20/seal # or: python -m seal.mcp_serverIt starts in introspection-only mode with no environment — initialize and
tools/list answer with no database, so a host or registry probe can connect
immediately. Set SEAL_DSN to a Postgres DSN to actually admit actions, and
SEAL_EXECUTORS=your.module for gateway mode.
// claude_desktop_config.json
{ "mcpServers": { "seal": { "command": "python", "args": ["-m", "seal.mcp_server"],
"env": { "SEAL_DSN": "postgres://..." } } } }Not an engineer? Read docs/PLAIN-ENGLISH.md instead — the same thing with no jargon, including what we can't do.
Everyone else ships a lock: a spend cap you set once and forget. The cap never learns, so an agent that has settled ten thousand clean payments is trusted exactly as little as the one you installed this morning — and you keep clicking Approve.
Seal ships the unlock. It reads what a payment path has actually proven — settlements the provider confirmed, sweeps showing nothing moved behind its back — and computes the autonomy that path has earned. L0 OBSERVED → L5 AUTONOMOUS. Nobody types the level.
████████············ L2 ASSISTED 50 proven · 100% confirmed [human required]
fifty settlements — but volume alone is not trust.
████████████········ L3 DELEGATED 50 proven · 100% confirmed [unattended]
one clean sweep later: the human stops clicking Approve.
···················· L0 OBSERVED 50 proven · 100% confirmed [SUSPENDED]
one charge the gateway never admitted. fifty clean ones don't outweigh it.SEAL_DSN="..." python3 license_demo.py # watch a path earn L3 and lose itSince 0.4.0 the licence drives the wheel, not just the dashboard. Turn on
earned autonomy — Gateway(seal, earned_autonomy=True), or
SEAL_EARNED_AUTONOMY=1 for the MCP server — and the gateway lets a path move
money unattended only to the extent its own record has earned (L3+), inside
the operator's ceilings, never above them. Three things hand the wheel back to
a human instantly: a path that hasn't earned it yet, a suspension (money moved
behind the gateway's back), and a hold — an execution reached the provider
and its outcome is unknown, so the path pulls over until settle() has asked
the provider what happened. The hold lifts by itself once the world answers.
A human can still approve any single action through the same maker-checker
door (tier=LICENCE). Off by default: nothing changes until you switch it on.
Can you prove your agents won't double-charge a customer? Three rungs, one ladder, written-only: a $300 founding conformance run — your implementation through the battery, result published on the Index (first three only; book) · a $1,200 attestation run — your live endpoint against every ambiguous outcome, signed result, findings within five business days, a clean run signed within 24 h (book) · a $12,000 fixed-scope money-path review — one production money path read, tested and attested in 7–10 days, no invoice if no real double-fire is shown on a path you run. For a free self-check first, hostile-facilitator tells you in 60 seconds.
Slow to earn, instant to lose — the only shape that makes a track record mean anything. The full level definitions: docs/AUTONOMY-LEVELS.md.
Seal's ambiguous-outcome doctrine — "could not determine" is terminal, never absent — is now §4.3 of the draft MCP retry-safety proposal, co-authored by us, with our conformance battery as its test suite.
Two different agents, on two different machines, both decide to charge order 123 at the same instant. In-process idempotency can't help — the guard has to live in a store both agents talk to, and the winner has to be decided atomically there.
Seal is that layer. One Postgres, one row per intent, one winner:
INSERT ... ON CONFLICT DO NOTHING -- one row, one winner, no check-then-act windowEvery admitted action ends in a certificate: a content-addressed hash over intent + args digest + result digest + the previous cert's hash. Editing, deleting or reordering any cert breaks every hash after it — and anyone with the DSN can check, with no network and no trust in us:
SEAL_DSN="..." python3 -m seal verify
# chain VERIFIED — 41 cert(s), every link intact (exit 0; broken chain → exit 1)Related MCP server: Belay
The claim is tested the hostile way: 1,000 real threads released by one barrier against one shared Postgres, where the "charge" increments a measured counter — if two callers run, the counter says 2 and the test fails loudly.
Result, four consecutive runs: ACTUAL_EXECUTIONS = 1. Every loser either replayed the sealed cert, stood down mid-flight, or failed safe when the store was unreachable. A 50-caller post-seal wave: all replayed, none re-ran. Full numbers, including the honest limits: STORM-PROOF.md.
Run it yourself:
pip install seal-kernel
export SEAL_DSN="host=... dbname=seal"
python3 -m seal verify # chain check, no network, no trust in usTo run the 1,000-thread storm proof yourself, clone the repo (the harness ships with the source, not the wheel):
# Needs Python 3.10+. macOS ships 3.9 with pip 21, which fails an editable
# install with a misleading "setup.py not found" error — use a venv rather
# than debugging that.
git clone https://github.com/aurumflux20/seal && cd seal
python3 -m venv .venv && source .venv/bin/activate
python3 -m pip install -U pip && python3 -m pip install -e .
export SEAL_DSN="host=... dbname=seal"
python3 storm.py --n 1000The exact harness above, generalized into a standalone file with zero dependency on this repo — copy it, point it at your own write-bearing tool, and find out for yourself:
python3 range_safety_test.py --n 1000It demonstrates itself against a known-unsafe target and a known-safe one before you ever run it for real, so a pass means something. Full writeup, including the three ways an early version of this test lied to us before it was fixed: docs/RANGE-SAFETY-TEST.md.
from seal import Seal
seal = Seal(dsn); seal.setup()
adm = seal.admit("charge", {"order_id": "123", "amount": 4900})
if adm.fresh: # you won — run the effect, then seal it
result = stripe_charge(...)
cert = seal.seal(adm.intent, adm.fence, result)
elif adm.cert is not None: # already done — here is the receipt
return adm.cert
else: # someone else is mid-flight — stand down
raise InFlight()If the effect fails before anything irreversible happened, release the claim
so a retry is legitimate: seal.fail(adm.intent, adm.fence, reason).
A cert saying "admitted once" is a claim about us. The next question is what Stripe (or Resend, or your bank's webhook) actually recorded — and the answer is allowed to disagree with us.
export SEAL_DSN="host=... dbname=..."
export STRIPE_TEST_KEY="sk_test_..." # your own test-mode key, Dashboard -> API keys
python3 stripe_demo.pyWhat it does, against your real Stripe test account, no mocks:
Two agents fire the same charge at the same instant. Seal admits one.
Exactly one real PaymentIntent is created.
The witness asks Stripe: "how many charges carry this intent?" Stripe
says one → the cert upgrades to WORLD_FINAL.
A rogue charge is created outside the gateway — the thing no local fence
can stop on its own. The witness asks again; Stripe now says two → the cert
becomes WORLD_DIVERGED, the domain freezes, and further spend on it is
refused automatically.
Two honest things the live run taught us, both fixed and both tested: Stripe's
search index is eventually consistent (a fresh charge can take real seconds to
appear — the witness polls to a definitive answer rather than ever recording a
"not indexed yet" empty read as authoritative absence), and once the world has
contradicted the ledger, a later flaky re-count must never quietly downgrade
the cert back to WORLD_FINAL — divergence is sticky by design.
admit() has always taken a read_set — the world facts a decision depends
on (a cart total, an inventory count) — and stored it on the cert. Until now
nothing ever checked it: a caller who believed they had staleness protection
had none. Same defect shape as a bug fixed earlier the same day, one layer up
— a guard present in the schema, never enforced.
from seal.freshness import CallableChecker
fresh = CallableChecker(lambda rs: current_cart_total(rs["order_id"]) == rs["total"])
adm = seal.admit("charge", {"amount": 5000}, key="order-777",
read_set={"order_id": "777", "total": 5000}, checker=fresh)
# StaleWorldRead is raised BEFORE a fence is granted if the checker says no —
# nothing runs on facts that already changed. Gateway.propose() takes the
# same read_set/checker kwargs and passes them straight through.Enforcement point is deliberate: before the fence, not after the effect ran.
Checking afterward could only refuse to claim success — it can't stop money
moving on stale information, which is the actual failure this exists to
prevent. Opt-in and backward-compatible, same rule as everywhere else in this
library: only engages when the caller supplies both read_set and checker.
Honest limit, printed where it applies rather than left to be discovered: the
checker call itself can't be made atomic with the admission INSERT, so a
change landing in that narrow gap is a residual window — the same caveat
class as a witness's eventually-consistent provider index.
The fence proves an action ran once. Clearance is the layer above it that a company actually buys: which tool paths may an agent fire unattended, and on what evidence.
from seal.clearance import Clearance, CLEARED
cl = Clearance(seal)
cl.set_policy("charge", CLEARED) # an operator's intent
cl.record_proof("charge", green=True, storm_n=1000, executions=1) # from CI
cl.status("charge")["effective"] # CLEARED — but only because both are trueThe rule that makes this more than a toggle: CLEARED is earned, not
declared. A path only reports effectively CLEARED if an operator set it
and a green storm proof was recorded recently enough. Let the last proof go
red, or let it go stale, and status() reports HOLD on its own — nobody has
to remember to downgrade it. REVOKED always wins, never auto-recovers, and
revoke_all() is one switch that stops every known path at the choke. A
range_report() exports counted events and provider-cited certs — the artifact
a security questionnaire or a CFO actually reads.
Clearance is policy. Policy an agent can walk around if it still holds
sk_live itself isn't a rail, it's a suggestion. Exclusive Authority removes
the credential from the agent entirely.
from seal.authority import Gateway
gw = Gateway(seal)
gw.register_executor("charge", lambda args: stripe_charge(args)) # secret lives HERE only
prop = gw.propose("charge", {"amount": 4900}, key="order-777")
if prop["status"] == "cleared":
result = gw.execute(prop["ticket"], {"amount": 4900}) # gateway calls Stripe, not the agentAn agent calls propose() and gets back a ticket — proof an intent was
admitted, cleared, and budgeted — never a secret. execute() is the only place
the provider is ever called, and the ticket is bound to the exact args that
were cleared: it's rejected if what you hand execute() doesn't match what was
proposed, single-use, and expires. (The first cut of this didn't bind args to
the signature and would have let a ticket cleared for $1 be spent on any
amount — found by attacking our own build before it shipped, not after.)
Custody model, stated plainly: the gateway runs inside your own infrastructure. AurumFlux never holds, sees, or transports your provider secret — we ship the software that takes the key out of the agent's hands; we do not become a vault ourselves. Honest limit: a process on the same host that can read the gateway's own environment can still steal the secret. This raises the bar to "steal from the vault," not to physical impossibility.
Binary CLEARED is enough for a $5 API call. It is not what a finance org signs off on for a $50,000 payout — they sign off on segregation of duties: the person who proposes a spend is never the person who approves it, on the record. Graduated Clearance adds thresholds on top of Clearance:
from seal.graduated import GraduatedClearance, APPROVE
gc = GraduatedClearance(seal)
gc.set_thresholds("payout", auto_ceiling=100, dual_ceiling=10_000, required_approvers=2)
# amount 50 -> AUTO, ordinary Clearance applies
# amount 5000 -> DUAL, needs 2 distinct human approvals before it can execute
r = gc.request("payout", 5000, maker="alice", intent=intent)
gc.add_vote(r["id"], "bob", APPROVE)
gc.add_vote(r["id"], "carol", APPROVE) # now APPROVED — a THIRD person, not aliceWired into the gateway: Gateway.propose(..., amount=X) on a path with
thresholds configured returns {"status": "needs_approval", "tier": "DUAL"}
instead of a ticket until a satisfied approval_id is supplied. The maker
cannot approve their own request — enforced in code, not policy — and one
approver cannot be counted twice even under a genuine concurrent race, because
it's a Postgres UNIQUE constraint on (approval, approver), not an
app-level check. A single reject is terminal. An approval authorises exactly
one execution and is bound to the exact intent it was requested for. Every
decided approval — approved or rejected, with every vote — is appended into
the same hash chain the execution certs live in, so seal verify covers
governance decisions the same way it covers what actually ran.
Backward-compatible by design: a path nobody ran set_thresholds() on never
triggers graduated clearance, even if propose() is called with an amount —
existing budget-only integrations are unaffected.
Run the whole story end to end — no payment provider needed, nothing charged:
python3 approval_demo.pyA $200 purchase clears on its own; $12,000 is refused until two distinct
humans approve; the requester is refused when they try to approve their own;
a duplicate vote from the same approver is refused; one reject is terminal;
$250,000 is never automatic; and one revoke stops even the $200 path. It
ends on the Range Report, which states approvals in money — approved and
rejected totals — rather than a count of event kinds.
The dispute that matters spans three parties — the user who authorised an
agent, the operator who ran it, and the merchant who got paid — and each holds
a database the other two cannot read. seal verify answers "did this run
exactly once, and did the world confirm it?", but only to someone holding the
DSN, which is to say only to the party being asked to prove its own innocence.
A portable receipt is that answer as a file. Certs are hashed over
RFC 8785 canonical JSON and (with a key configured) Ed25519-signed at
write time, so a counterparty verifies them with no database, no network, and
none of our code — docs/verify-receipt.mjs does
it in ~30 lines of Node:
pip install 'seal-kernel[signing]'
python -m seal keygen # SEAL_SIGNING_KEY= secret · public key= publish it
python -m seal export --intent <id> > receipt.json
python -m seal verify-receipt receipt.json --pubkey <hex> # needs NO DSN
node docs/verify-receipt.mjs receipt.json <hex> # or no Python at allHonest limits, on the verdict itself: a pinned-key pass proves these certs were produced by the key holder and are unaltered — it cannot prove completeness (whether other certs exist takes the chain check against the store), and an unpinned pass proves internal consistency only, never authorship. Signing is opt-in; an unsigned store keeps working exactly as before, and v1 certs keep verifying next to v2 forever.
Idempotency keys make retrying the same request safe. They do not answer
what happened after a timeout where the provider may already have acted. That
intent sits open, and before settle() the only resolution was implicit — a
future admit(heal_with=…) some caller might never make. Now it is one verb:
gateway.settle(intent) # uses the path's registered witness
# CONFIRMED_ONE → healed to WORLD_FINAL, budget reservation settled
# ABSENT → claim released for a clean retry, budget returned
# MULTIPLE → WORLD_DIVERGED on the chain, domain frozen
# UNKNOWN → unresolved, loudly — the claim stands, nothing is guessedEvery guard above — and every agent-safety tool we know of — watches commission: the double-charge, the overspend, the contradiction. Nothing watches omission. An agent that crashed, lost its key, or silently stopped looks exactly like an agent with nothing to do — until payroll doesn't go out, or the refund that was legally due in 14 days quietly doesn't happen.
This repo already refuses that failure mode for its tests (conftest.py: a
run where everything skipped is not a pass). Obligations apply the same
sentence to production money. It is the dual of the reconcile sweep:
reconcile: provider effects − admitted intents = out-of-band (did too much)
obligations: declared duties − sealed intents = BREACH (did too little)from seal.obligation import Obligations
obs = Obligations(seal); obs.setup()
# at decision time, the agent binds its future self:
obs.expect(action="refund", key="return-123", due_in_sec=14*86400,
description="statutory refund window for return #123")
# the business heartbeat:
obs.expect_recurring(action="renewal", every_sec=86400, min_count=1)
obs.sweep() # or: python -m seal obligations (exit 1 on any open breach)What makes a miss more than a dashboard row: the breach itself is appended
to the tamper-evident chain (deleting it breaks every hash after it), and
obligation_breached is a licence-suspending event — a path that goes
silent on declared work loses its earned autonomy exactly like a path that
double-charged. Declaring duties is open to agents (seal_expect over MCP);
cancelling one is an operator act with no agent-facing tool, because an
obligation an agent could cancel is not an obligation. A breach deliberately
does not freeze the path — a frozen refund path cannot cure a missed
refund; the levers are evidence, alarm, and the licence.
A cert proves the action was admitted exactly once at this gateway and that
the recorded result hasn't been altered since. It does not prove the outside
world settled it — every v1 cert carries world: "unconfirmed", permanently and
on purpose. "We admitted this once" and "Stripe took the money" are different
claims; conflating them is exactly the bug class this tool exists to stop.
World confirmation (provider adapters that flip that field against Stripe's or
your provider's own records) is the next layer, and the cert schema already
carries the field so the format won't break.
once-kernel proves one
process didn't run an effect twice. effectfence
guards one MCP server. Seal is the cross-process layer above both, for the
moment your agents outgrow a single machine. The free primitives stay free
(Apache-2.0 / MIT), forever.
For claim vs proven on agent PRs and CI (said it ≠ showed it), see the
separate project coherence —
not part of this repo; different package, different git history.
Business Source License 1.1: read it, run it, use it in production internally (commercial included) — just don't resell it as a hosted service. Converts to Apache-2.0 on 2030-08-12.
mcp-name: io.github.aurumflux20/seal
Release a claim after a failure where NOTHING irreversible happened, so a later retry is legitimate. Returns {released: true}. Only the fence holder may abort; the reason is recorded on the chain. If the effect may have fired (e.g. a timeout after the provider was called), do NOT abort — leave the claim and let a witness (settle) decide, otherwise the retry becomes a second charge.
| Name | Required | Description | Default |
|---|---|---|---|
| fence | Yes | The fence token returned with fresh=true from seal_admit. Proves you are the one caller admitted for this intent; refused if it is not yours or the claim was reclaimed. | |
| intent | Yes | The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action. | |
| reason | Yes | Why the effect did not happen (e.g. 'provider returned 400 before charging'). Recorded on the chain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations convey read/write and idempotency, and the description adds non-obvious behavior: it returns {released: true}, only the fence holder may abort, the reason is recorded on the chain, and aborting in uncertain cases risks a second charge. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, return value, authorization, and exclusion are front-loaded in compact sentences. The warning about second charges is meaningful, not filler, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations and full schema coverage, the description covers authorization, return value, the condition for a legitimate abort, and the failure mode to avoid. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds only minor context (e.g., reason is recorded on chain) but does not need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: release a claim after a failure where nothing irreversible happened. It provides precise scope, but it does not explicitly differentiate from sibling tools by name (it refers to a witness 'settle' rather than a listed sibling), so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit when-to-use condition ('after a failure where NOTHING irreversible happened') and an explicit when-not-to-use with alternative ('If the effect may have fired... do NOT abort — leave the claim and let a witness (settle) decide'). This is exactly the guidance an agent needs to avoid a double charge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ADMISSION ONLY — prefer seal_propose when it is available, because this tool requires YOU to hold the provider credential and call the provider yourself. Use it only when your own code owns the effect.
Claim the right to run an irreversible action exactly once. Returns fresh=true with a fence (you won — run the effect, then call seal_commit), or fresh=false with the sealed cert (already done — use that result, do NOT re-run), or fresh=false with no cert (someone else is mid-flight — stand down and retry later). Always pass a stable key (e.g. 'order-777') for money-class actions: retrying with the same key but different args is refused as a conflict instead of becoming a second charge.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Stable id for this logical action. Strongly recommended. | |
| args | Yes | The effect's arguments. | |
| action | Yes | What kind of effect, e.g. 'charge'. | |
| domain | No | Blast-radius scope, e.g. 'customer:42'. Frozen domains refuse admission. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: it explains the fresh=true/fresh=false contract, the meaning of a missing cert, the rule not to re-run already-completed effects, and the conflict behavior for retries with the same key but different args. These details are not present in annotations or schema and meaningfully disclose the tool's operational semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: the leading 'ADMISSION ONLY' warning, the alternative tool preference, the outcome contract, and the key guidance are each purposeful. No sentence is filler, and the critical caution is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and a non-obvious once-only admission protocol, the description covers the essential scenarios: winning, already complete, and mid-flight. It also covers the key parameter's reuse semantics and the need to call seal_commit. The description is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the stable-key requirement for money-class actions and the conflict refusal behavior, which clarifies the `key` parameter beyond its schema description. It also gives a concrete example, 'order-777', making the semantics more actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Claim the right to run an irreversible action exactly once.' It also distinguishes itself from seal_propose by explaining that seal_admit requires the caller to hold the provider credential and own the effect. The purpose is immediately clear and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to prefer seal_propose when available and to use seal_admit only when your own code owns the effect. It also gives actionable guidance on what to do after each return outcome, including calling seal_commit and standing down on mid-flight results. This is strong when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Seal a successful effect: writes the tamper-evident certificate and closes the intent. Call it once, right after YOUR code ran the effect admitted by seal_admit (fresh=true). Only the fence holder may commit, and only once — a second commit, a wrong fence, or an expired lease is refused (isError). Returns the cert: hash, prev hash, state=sealed. If the effect failed before anything irreversible happened, call seal_abort instead; if you do not know whether it fired, call neither and leave the claim for a witness.
| Name | Required | Description | Default |
|---|---|---|---|
| fence | Yes | The fence token returned with fresh=true from seal_admit. Proves you are the one caller admitted for this intent; refused if it is not yours or the claim was reclaimed. | |
| intent | Yes | The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action. | |
| result | Yes | The effect's result as returned by the provider (e.g. the charge object). Digested into the cert; keep it small. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly, non-idempotent, but the description goes beyond this: it explains the single-call constraint, the fence-holder-only restriction, refusal conditions (second commit, wrong fence, expired lease returns isError), and what the cert contains. It does not contradict annotations. A small gap is that it doesn't explicitly say whether the operation is atomic or how failures beyond refusal surface, but the behavioral context is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, all earning their place: state the action, state the exact timing, state the failure modes and alternatives, and list the return contents. Front-loaded with the definitive action and then precise conditions. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter protocol tool with full schema coverage and no output schema, the description answers the key practical questions: when to call it, when not to, constraints, refusal conditions, and return contents. Given the safety-critical nature, this is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds context for 'fence' (proves the caller), 'intent' (identifies one logical action), and 'result' (digested into cert, keep it small). That adds meaning beyond the schema, especially for 'result', but since the schema already carries full descriptions, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is explicit about the verb ('Seal'), the resource ('a successful effect'), and its core actions: writes the tamper-evident certificate and closes the intent. It clearly stands apart from sibling tools like seal_abort and seal_admit by stating its exact role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use instructions: 'Call it once, right after YOUR code ran the effect admitted by seal_admit (fresh=true).' It names the alternative (seal_abort), gives the condition for using it, and explicitly warns against calling either when unsure, routing that case to a witness. No ambiguity about the tool's position in the protocol.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bind yourself (or the system) to future work: declare that an effect (action, key) MUST be sealed by a deadline. If it has not happened by then, the miss is recorded on the tamper-evident chain and the path's autonomy licence is suspended. Use this at decision time — e.g. the moment you accept a return, declare the refund duty. Declaring duties is always safe; only an operator can cancel one.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | Who is declaring, e.g. your agent id. | |
| key | Yes | Stable key of the expected intent, e.g. 'return-123'. | |
| action | Yes | The action that must happen, e.g. 'refund'. | |
| grace_sec | No | Grace period after the deadline before a miss is a breach. | |
| due_in_sec | Yes | Deadline, seconds from now. | |
| description | No | Human-readable statement of the duty. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining the real-world consequences: a miss is recorded on a tamper-evident chain and the path's autonomy license is suspended. It also discloses that declarations are safe and can only be cancelled by an operator. This gives an agent accurate expectations about side effects and reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose and immediately followed by usage timing and safety caveats. Every sentence contributes meaningful information without padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and modest annotations, the description covers purpose, usage timing, side effects, and safety constraints. It does not explicitly explain return behavior or list sibling alternatives, but the essential context for invoking the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds conceptual framing around action, key, and deadline, but does not add significant per-parameter details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: bind yourself or the system to future work by declaring that a specific effect must be sealed by a deadline. It identifies the core resource (an expected intent keyed by action/key) and the consequence of missing the deadline. It does not explicitly differentiate from sibling tools like seal_commit or seal_admit by name, so it falls just short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when to use this tool: 'Use this at decision time' with a worked example of accepting a return and declaring the refund duty. It also notes that declaring duties is always safe and that only an operator can cancel one. It does not explicitly state when not to use it or point to a sibling alternative, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only status of one intent: {intent, action, state, tier, cert, domain, graph_id, created_at}. state is open (claimed, not yet sealed), sealed (done — cert present), or failed (released); tier is the clearance tier it ran under. Unknown intent returns {error: 'unknown intent'} rather than an error. Changes nothing. Use seal_verify for the whole chain and seal_incident_receipt for an auditor-grade export of one intent.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description reveals meaningful behavior: state value semantics, the unknown-intent behavior returning {error: 'unknown intent'} rather than a hard error, and the explicit statement 'Changes nothing'. This is rich, non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the primary purpose appears first, followed by essential return-field and state semantics, then routing guidance. Every sentence contributes information, and there is no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates well by listing the returned fields, explaining state values, describing the unknown-intent response, and clarifying the tool is read-only. It also disambiguates against closely related sibling tools. An agent has enough to call this tool correctly and interpret its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter with 100% coverage, including where the intent id comes from. The tool description only echoes the idea of 'one intent' and does not add meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb and resource: 'Read-only status of one intent', and enumerates the exact fields returned. It also differentiates itself from sibling tools by naming seal_verify and seal_incident_receipt as alternatives for different needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes that this tool is for checking the status of a single intent and explicitly points to seal_verify for the whole chain and seal_incident_receipt for auditor-grade exports. It does not enumerate every exclusion scenario, but the contextual guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend the lease while a slow effect is still running, so the claim is not reclaimed mid-flight and a second caller cannot run it. Call it periodically (well inside the lease) between seal_admit and seal_commit. Returns {lease_until: }. Only the fence holder may extend, and only while the intent is still open; after the lease expired or the intent closed it is refused (isError). Safe to repeat.
| Name | Required | Description | Default |
|---|---|---|---|
| fence | Yes | The fence token returned with fresh=true from seal_admit. Proves you are the one caller admitted for this intent; refused if it is not yours or the claim was reclaimed. | |
| intent | Yes | The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotentHint=true), the description explains why it is safe to repeat, what the return value is, and the conditions under which it fails ('Only the fence holder may extend... refused'). It also reveals the underlying purpose of preventing reclamation mid-flight, which adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loads the core behavior, then adds lifecycle guidance, return shape, failure conditions, and idempotency. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description correctly documents the return value ({lease_until}), the ownership requirement, the failure cases, and repeatability. For a lease-extension tool with clear annotations, nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description reinforces their role in the lease-extending flow but does not add substantial new parameter-level meaning beyond what is already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Extend the lease') and a clear resource (a lease for an intent), and explicitly situates it between seal_admit and seal_commit. This distinguishes it from the sibling tools by lifecycle phase and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly says when to call it ('periodically well inside the lease between seal_admit and seal_commit') and when it is refused (after lease expiry or intent close). It does not explicitly name alternative tools for when the effect is finished, but the lifecycle placement gives strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only, self-checking export for one intent: its full cert chain, tier, domain freeze state, and a chain verification result — the document you hand an auditor or a counterparty. Changes nothing. For a quick status use seal_get instead.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds context beyond those hints: it is 'self-checking,' exports a verification result, and returns the specific data set (cert chain, tier, domain freeze state). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what the tool returns, that it changes nothing, and the sibling alternative. The purpose is front-loaded and there is zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter export tool with no output schema, the description adequately covers what the agent needs: the input, the output contents, side effects (none), and the alternative for a different need. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents the 'intent' parameter. The tool description adds no extra parameter-level meaning beyond indicating 'one intent,' which is already implied by the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: a 'read-only, self-checking export for one intent' that returns 'full cert chain, tier, domain freeze state, and a chain verification result.' It also names the sibling alternative (seal_get) and distinguishes itself as the auditor/counterparty document, making its role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: use this for audit/counterparty documentation and use seal_get for a quick status. This clearly separates the tool from its siblings and provides a concrete when-to-use / when-not-to-use rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sweep every declared duty for silence: work that should have been sealed by now and wasn't. verdict=met only when nothing is owed, missed, or unconfirmed. Breaches are already on the chain — this reports them, it cannot hide them. Returns {verdict, owed, missed, unconfirmed} — verdict=met means all three are empty. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations that already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds meaningful context: it reports breaches that are already on the chain and cannot hide them. It also clarifies the exact conditions for verdict=met, which is genuinely useful behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded with the core scanning purpose, then explains verdict logic and the return shape. The final 'Read-only.' is redundant with the annotations but harmless; otherwise every sentence contributes necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only audit tool with no output schema, the description fully covers what the agent needs: the return object fields, the meaning of verdict=met, and the non-mutating nature of the operation. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline for no-parameter tools is 4, and the description appropriately focuses on result semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('sweep every declared duty for silence') and the resource (obligations), and explains the verdict semantics. It does not explicitly contrast with sibling tools like seal_verify or seal_get, but the role of a global audit/report operation is clear enough to distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool should be used: to check whether any declared duties are unsealed, owed, missed, or unconfirmed. However, it never explicitly states when to choose this over alternatives, so the usage guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the entire certificate chain from the store alone — no network, no trust in this server. Returns {ok: true, count} when every link recomputes, or ok=false with the position of the first cert that was edited, deleted or reordered. Read-only; run it any time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds substantial context: it recomputes every link, returns ok:true with a count, or reports the exact position of the first problematic cert. It also confirms it runs entirely from the local store with no server trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no fluff. The main purpose is front-loaded, the return behavior is specific, and the read-only reassurance is placed last as a practical usage note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only verification tool with no output schema, the description is complete: it covers operation, constraints, success and failure return shapes, and safety. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to explain. The baseline of 4 applies because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Verify the entire certificate chain from the store alone.' The qualifiers 'no network, no trust in this server' clearly distinguish it from server-dependent or network-dependent operations among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: this is the local, offline, server-independent verification path and is safe to run any time. It does not explicitly name sibling tools or state when not to use it, so it falls just short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
seal_abort3 fields changedInput schema / properties / fence / descriptionAdded value: +"The fence token returned with fresh=true from seal_admit. Proves you are the one caller admitted for this intent; refused if it is not yours or the claim was reclaimed."Input schema / properties / intent / descriptionAdded value: +"The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action."Input schema / properties / reason / descriptionAdded value: +"Why the effect did not happen (e.g. 'provider returned 400 before charging'). Recorded on the chain."seal_commit3 fields changedInput schema / properties / fence / descriptionAdded value: +"The fence token returned with fresh=true from seal_admit. Proves you are the one caller admitted for this intent; refused if it is not yours or the claim was reclaimed."Input schema / properties / intent / descriptionAdded value: +"The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action."Input schema / properties / result / descriptionPrevious value: -"The effect's result, digested into the cert."New value: +"The effect's result as returned by the provider (e.g. the charge object). Digested into the cert; keep it small."seal_get1 field changedInput schema / properties / intent / descriptionAdded value: +"The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action."seal_heartbeat2 fields changedInput schema / properties / fence / descriptionAdded value: +"The fence token returned with fresh=true from seal_admit. Proves you are the one caller admitted for this intent; refused if it is not yours or the claim was reclaimed."Input schema / properties / intent / descriptionAdded value: +"The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action."seal_incident_receipt1 field changedInput schema / properties / intent / descriptionAdded value: +"The intent id returned by seal_admit / seal_propose (also `intent` on any cert). Identifies one logical action."v0.4.0seal_abortseal_admitseal_commitseal_expectseal_getseal_heartbeatseal_incident_receiptseal_obligationsseal_verifyEvery tool targets a distinct phase of the sealing lifecycle: admit, commit, abort, heartbeat, status, verification, audit export, duty declaration, and duty sweep. Cross-references explicitly steer agents among the read tools (get vs verify vs incident_receipt), so misselection is unlikely.
All tools share the seal_ prefix and snake_case style, and the verb forms (admit/commit/abort/get/verify) read cleanly. However seal_heartbeat, seal_incident_receipt, and seal_obligations are noun-like names rather than strict verb_noun, so the pattern is consistent but not perfectly uniform.
Nine tools is well-scoped for a specialized idempotency/sealing protocol; each covers a distinct operation and none feels redundant. The count is neither too thin nor bloated.
The core lifecycle is covered end-to-end: claim, extend, commit, abort, read, verify, audit, and duty tracking. Minor gaps remain because seal_propose and a witness/settle mechanism are referenced in descriptions but not exposed as tools, so unusual or uncertain paths must rely on external behavior.
An effect gate for AI agents: at-most-once side effects, spend limits, and signed receipts.
Payment-rail-independent intent-to-effect integrity for consequential agent actions.
Prevent duplicate AI-agent side effects with idempotency, verification, and durable receipts.
Reliable async execution for agent tool calls: schema gating, retries, idempotency, audit trail.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aurumflux20/seal'
If you have feedback or need assistance with the MCP directory API, please join our Discord server