Resolve vs Sequesign
A side-by-side look at the Resolve and Sequesign MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Resolve for cryptography work as a local process; choose Sequesign for cryptography as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Resolve when
- You need dedicated capabilities in the Cryptography domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You have the keys it needs:
FORESTRIE_BASE_URL, FORESTRIE_RPC_URL. - You want tools like
fetch_scitt_configuration, query_registration, fetch_receipt.
Choose Sequesign when
- You need dedicated capabilities in the Cryptography domain.
- You prefer a local stdio subprocess transport.
- You want tools like
sequesign_start_session, sequesign_record_action, sequesign_record_approval.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Cryptography | Cryptography |
| Quality signal | 63/100 · Good | 53/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | No auth required | Not declared |
| Pricing | Free | Not declared |
| Required env vars | FORESTRIE_BASE_URLFORESTRIE_RPC_URL | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 0 |
| Directory activity | 1 views 0 installs 0 upvotes | 0 views 0 installs 0 upvotes |
| Tools | 8 | 8 |
| Full listing | View Resolve | View Sequesign |
Tools & capabilities
Resolve tools 8
fetch_scitt_configurationGET {baseUrl}/.well-known/scitt-configuration: the transparency service's self-description (service id, base URL, supported algorithms), returned as JSON. Provenance: fetched. Supports: none of the four questions; this is what the operator says about itself.query_registrationOne GET of {baseUrl}/logs/{bootstrapLogId}/{logId}/entries/{contentHash}, where contentHash is the hex sha256 of the signed statement bytes. Returns pending (with retryAfterMs when the server said so) or the receipt's URL, which includes the massif height, and the entry id. pending is the operator's answer for any content hash its sequencing index does not hold yet, including one that was never registered: the operator does not distinguish the two, so a retry only helps for a statement you know was submitted. receipt-available is the index's answer, not proof the receipt is written: fetch_receipt is the check, and a 404 there is not_found, never pending. Never polls: call again yourself if you want to. Provenance: fetched. Supports: none of the four questions; this is registration status.fetch_receiptGET a receipt: either by receiptUrl (as returned by query_registration) or by {baseUrl, bootstrapLogId, logId, massifHeight, entryId}. Returns the receipt bytes base64-encoded, the verifier's decoding of them, and receiptLogId: the log the receipt's delegation certificate names, which is the operator's statement like the rest of the receipt. A 404 is the structured problem not_found carrying the operator's own title (for example 'Entry receipt not found (checkpoint missing)' for a wrong massif height); it is never reported as pending, because a receipt URL the operator holds nothing at does not fill in by waiting. Provenance: fetched. Supports: none on its own; a receipt is the operator's claim, so verify it under a trust root you hold (or use verify_fetched_receipt).fetch_genesisGET {baseUrl}/api/forest/{logId}/genesis: the forest's genesis document as CBOR, base64-encoded, with what it carries decoded: the chain binding (univocity contract address, chain id, forest log id) and, for an ES256 forest, the bootstrap public key as bootstrapKeyXy (x‖y hex). Both are read from these bytes, so they stand exactly where the copy stands. For capture: obtain it once, keep it, and pass it as bytes from then on. A copy obtained at check time is not the genesis trust root as intended, and its chain binding and bootstrap key are likewise the operator's claim today; keep the copy from registration, or cross-check them against a source you trust independently. Provenance: fetched. Supports: sealing, as known-log-key with the key this copy carries.fetch_accumulatorRead the log's published accumulator from the univocity contract at your rpcUrl: eth_chainId, then eth_getBlockByNumber latest, then one eth_call logState(logId) at that block. The contract address and chain id come from a genesis you hold ({genesis, rpcUrl, logId}) or are given explicitly ({rpcUrl, univocity, logId, chainId?}); a chain id mismatch is reported as a problem before any call. Optionally pass forReceipt (the receipt bytes with the registered payload and its entryId, or the committed grant bytes with grant true; bytes base64): if later growth has buried that receipt's peak, so the latest state no longer holds it, the tool walks the contract's CheckpointPublished history backwards within the bounds you set in chain.history and returns the newest checkpoint that holds the peak, saying so in provenance.history; running out of range is a structured problem, history_scan_exhausted. Returns the snapshot CBOR the verifier's known-accumulator root consumes, base64-encoded, with size, block number and block hash. Provenance: chain-read. Supports: split-view under known-accumulator, against the chain rather than the operator; sealing and append-authority by inheritance from the contract's publish-time checks, not by a local signature check.fetch_checkpoint_historyRead the log's published checkpoints from the univocity contract's CheckpointPublished events at your rpcUrl, newest first, in windows of history.chunkBlocks (default 10000) walking back from the latest block to history.fromBlock, or for at most history.maxBlocks (default 200000): one eth_getLogs per window, never an unbounded scan. The contract address and chain id come from a genesis you hold or are given explicitly, as for fetch_accumulator. Returns each checkpoint's size, accumulator, block number, block hash and transaction hash, plus the same checkpoint as a known-accumulator snapshot (base64) you can keep and later pass to verify_fetched_receipt as supplied bytes; and scannedFrom, scannedTo and the number of requests made. For capture: the contract keeps only its latest state, and a receipt whose peak later growth has buried verifies only against a checkpoint that still holds that peak, so keep the ones you need. Provenance: chain-read. Supports: as fetch_accumulator, split-view under known-accumulator against the chain rather than the operator; sealing and append-authority by inheritance from the contract's publish-time checks, not by a local signature check.fetch_ks256_attestationFor a receipt whose delegation certificate is signed by a contract KS256 root (a Safe, say): ask the contract whether it accepts that certificate, and return the answer as an attestation @forestrie/mcp-verify can consume offline. Reads the chain at your rpcUrl (this tool does; mcp-verify never does): eth_chainId, eth_getBlockByNumber for your block (default latest), then eth_getCode at the root and one eth_call isValidSignature(digest, signature), where digest and signature come from the receipt's certificate. Both state reads are pinned by the block's hash (EIP-1898, requireCanonical), so the hash in the attestation is the state that was read. Give the receipt, and the root as root (0x 20-byte address) or as a genesis you hold (genesis; it supplies the root when root is absent, which must then be a KS256 bootstrap root, and always supplies the chain the RPC must be on; a chain id mismatch is a problem before any further call). Returns the attestation as canonical CBOR, base64-encoded, with its fields (chain id, root address, digest, signature hash, block number, block hash, magic). Pass it to verify_receipt in mcp-verify as ks256Attestation: it then attests the certificate valid under the contract's signers at block N, which is narrower than an EOA root's offline ecrecover check; anyone with RPC can re-run the call at that block to confirm or disprove it. Refuses, with a structured problem and never an attestation, when there is no contract code at the root (an EOA root verifies by ecrecover and needs none), when the call reverts, or when the return is anything but exactly one 32-byte word, 0x1626ba7e followed by 28 zero bytes (a short return, dirty padding, extra words or an echo of the call's own data are all refused); a malformed chain id, block or hash from the RPC is an rpc_error problem. With root given beside a genesis, root is the contract asked and the genesis supplies only the expected chain (provenance.binding is explicit, chainFrom held-genesis); binding is held-genesis only when the root came from the genesis. Provenance: chain-read. Supports: none of the four questions on its own; the attestation is evidence only once mcp-verify consumes it under a root you hold.verify_fetched_receiptFetch a receipt (as fetch_receipt) and verify it with @forestrie/mcp-verify's core under a trust root you supply as bytes (genesis, keyXy, accumulator, or checkpoints; each {b64} or {path}) or under an accumulator read from the chain in this call ({root: 'known-accumulator', chain: {genesis, rpcUrl, logId?} or {rpcUrl, univocity, logId?, chainId?}}). A genesis fetched in the same call is never the root. The result is the verifier's own: stages, the four questions (sealing, split-view, append-authority, attribution; not_answered_by_this_root is a real answer) and diagnostics, passed through unaltered, plus receipt_fetched_from_operator always and root_read_from_chain when the chain path was taken. If the latest chain state no longer holds the receipt's peak, the chain path walks CheckpointPublished history backwards within the bounds in chain.history (default 200000 blocks in windows of 10000, one eth_getLogs each) and verifies under the newest checkpoint that holds it, adding root_read_from_chain_history; running out of range is the structured problem history_scan_exhausted. The log read is the one you name, in chain.logId or in the receipt coordinates; if the receipt's delegation certificate names a different log, the result adds receipt_log_id_mismatch and the call still uses yours. If you name none, the call uses the certificate's log id and says so in provenance.logId, with source receipt-delegation-certificate. Supply payload bytes and the entry id to have attribution answered. The genesis root's offline walk resolves one delegation hop from the forest root: a receipt from a log further down the grant chain (the verifier's own publications log is a grandchild) fails under a supplied genesis with delegation_invalid, and the result adds genesis_root_reaches_direct_delegates_only to say that this is the walk's limit, not a finding about the receipt; verify such a receipt under known-log-key or known-accumulator.
Sequesign tools 8
sequesign_start_sessionOpen a recording session (one signed action chain). Returns a `sessionId` (the receipt id) used by every other tool. Pass a `policyContext` object to bind the receipt to a policy (reaches `L3_POLICY_BOUND`). Optional `mode` (`direct`/`managed`) overrides the server default per session.sequesign_record_actionAppend a signed action to the chain. `evidence` is hashed and signed. Returns the `actionId`.sequesign_record_approvalAttach a locally signed approval for a recorded action (e.g. a human or agent reviewer signing off).sequesign_record_counterparty_attestationAttach a counterparty's signed confirmation of a recorded action (e.g. a vendor confirming an amount). The SDK derives the content binding from the attested action.sequesign_approve_receiptAttach an independently-witnessed **approval** to an *already-sealed* receipt (a deferred satellite). For a reviewer — human or another agent — signing off after the fact. The approver must be distinct from the recording agent.sequesign_countersign_receiptAttach an independently-witnessed **counterparty confirmation** to an *already-sealed* receipt (a deferred satellite), bound to a specific action.sequesign_finalizeSeal + witness the receipt and run the SDK's own verification. Closes the session.sequesign_verifyVerify a sealed receipt offline. Three modes: integrity self-check of the local package (default); third-party `external` check when you pass the witness's published keys; or pass `receiptUrl` to verify the broker-**stored** receipt (the authoritative copy carrying the registered identity), auto-fe…
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Resolve
{
"mcpServers": {
"resolve": {
"command": "npx",
"args": [
"-y",
"@forestrie/mcp-resolve"
],
"env": {
"FORESTRIE_BASE_URL": "YOUR_FORESTRIE_BASE_URL_HERE",
"FORESTRIE_RPC_URL": "YOUR_FORESTRIE_RPC_URL_HERE"
}
}
}
}
Sequesign
{
"mcpServers": {
"sequesign": {
"command": "npx",
"args": [
"-y",
"@sequesign/mcp"
]
}
}
}
Frequently asked questions
Resolve is categorized under Cryptography and uses a local stdio subprocess. Sequesign belongs to Cryptography and uses a local stdio subprocess. Pick Resolve for cryptography work and Sequesign for cryptography.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Resolve is listed as free. Auth: no auth required. Sequesign has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add resolve and sequesign as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Resolve has a quality signal of 63/100 (Good) with 1 views, 0 installs and 0 GitHub stars. Sequesign has 53/100 (Good) with 0 views, 0 installs and 0 GitHub stars.