Evidence vs Substack MCP Server
A side-by-side look at the Evidence and Substack MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Evidence for developer tools work as a local process; choose Substack MCP Server for developer tools as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Evidence when
- You need dedicated capabilities in the Developer Tools domain.
- You prefer a local stdio subprocess transport.
- You want tools like
issue_receipt, verify_receipt, record_disclosure.
Choose Substack MCP Server when
- You need dedicated capabilities in the Developer Tools domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
SUBSTACK_PUBLICATION_URL, SUBSTACK_SESSION_TOKEN, SUBSTACK_USER_ID. - You want tools like
create_draft_post, set_post_body, upload_image.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Developer Tools | Developer Tools |
| Quality signal | 63/100 · Good | 67/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | SUBSTACK_PUBLICATION_URLSUBSTACK_SESSION_TOKENSUBSTACK_USER_ID |
| Verified owner | Community listing | Community listing |
| GitHub stars | 1 | 87 |
| Directory activity | 3 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 9 | 27 |
| Full listing | View Evidence | View Substack MCP Server |
Tools & capabilities
Evidence tools 9
issue_receiptIssue an x402 offer-receipt (EIP-712) plus a Tersign compliance record (returned as `compliance`; verify_compliance_record checks it) for a payment that has ALREADY settled; when a ledger is configured, the ledger counter-signs the receipt into your hash chain, while the compliance-fields record is not counter-signed and is bound to its receipt only by your own signature, which covers the receipt's digest. Use this for money that moved; use record_disclosure for a non-payment agent action. Side effects: signs with your signing key (the one set in the Tersign plugin's settings in Claude Code, or the TERSIGN_* environment variables, else the one generated and kept locally on first run), and performs ONE network write to the ledger when a ledger URL, API key and seller id are set there too (without them it signs locally and returns an unchained artifact). Returns the signed receipt artifact, its keccak256 canonical digest, and — when chained — the ledger counter-signature and sequence number.verify_receiptVerify an x402 offer-receipt artifact, fully OFFLINE (no network, no API key, no account; checks no ledger or chain): recover the address whose key produced its EIP-712 signature over the six signed payload fields (version, network, resourceUrl, payer, issuedAt, transaction), and compute its canonical digest (the content address a ledger records it under). Recovery yields SOME address for any payload, so without expectedSigner the signer is UNAUTHENTICATED: valid:true then proves neither who signed nor that the receipt is unmodified — an edited receipt recovers a different address and still returns valid:true. Pass expectedSigner, the issuer's address obtained out-of-band, to bind it: valid:true then means the signed fields were signed by that key; a mismatch returns valid:false with the recovered signer so you can see who actually signed. Use this for a receipt (money); use verify_compliance_record for the compliance record issue_receipt returns beside a receipt. Returns { verdict, valid, signer, signerStatus: BOUND | UNAUTHENTICATED | MISMATCH, signerBound, testKey? (the signer is a PUBLISHED test key — anyone can sign as it), digest, unsignedFields? (present in the artifact but not covered by the signature), reason? }. Read verdict first.record_disclosureOne-call disclosure evidence (EU AI Act Art 50 dialect): digests the disclosure text LOCALLY, signs an action record with your key, and the public ledger counter-signs it into your per-signer hash chain. No API key needed — the first call self-provisions a free signer-keyed account, except when your key is already registered to an API-key account (409) or the daily provisioning caps are reached (429; https://tersign.ai/pricing).verify_compliance_recordVerify ONE record type: the compliance record that issue_receipt returns beside a receipt (`compliance`: a ComplianceRecordV1 `record` plus its ComplianceAttestation `attestation`, EIP-712 domain "compliance-fields"), fully OFFLINE (no network, no API key, no account): recompute the record's canonical digest, check that the attestation's signed payload names that exact digest and the same receiptDigest as the record, and recover the address that signed the attestation. It does NOT verify the disclosure record record_disclosure returns: that is a different record type (an action record, EIP-712 domain "tersign action-record"), and passed here it fails with a digest mismatch that says nothing about tampering. Use verify_receipt for the payment receipt itself. Without expectedSigner the signer is UNAUTHENTICATED and valid:true proves internal consistency only — anyone can edit a record, recompute its digest and re-sign the attestation with their own key, and still get valid:true with a different signer. Pass expectedSigner, obtained out-of-band, to bind authorship. Returns { verdict, valid, signer, signerStatus: BOUND | UNAUTHENTICATED | MISMATCH, signerBound, testKey? (a PUBLISHED test key — anyone can sign as it), digest (the recomputed record digest), reason? }. Read verdict first.record_refundLog a refund against a receipt already on your chain, as the SELLER. The ledger stores it as a PENDING refund entry that references the original receipt digest; the entry is NOT counter-signed or appended to the hash chain, and it has no digest or sequence number of its own. Nothing is edited or deleted: the original receipt and its chain position stay exactly as they were. Requires a ledger URL, API key and seller id (the Tersign plugin's settings in Claude Code, or the TERSIGN_* environment variables) and performs one network write; errors if the original digest is not on your chain. This RECORDS a refund you have already made — it moves no money. For a signed refund RECORD, build a compliance record with refundOf set to the original record digest (buildMinimalRecord in the SDK). Returns { id, status: "pending" }.open_disputeOpen an objective dispute against a counter-signed receipt as the PAYER (the configured key must be the receipt payer). Reasons: not_delivered, wrong_content, duplicate_charge. Contested non-mechanical claims escalate to the arbiter; duplicate_charge is decided instantly from ledger arithmetic.submit_dispute_evidenceSubmit signed evidence to an open dispute. Claimant evidence must be signed by the payer key; respondent evidence additionally requires the seller API key (the Tersign plugin's settings in Claude Code, or the TERSIGN_* environment variables).adjudicate_disputeTrigger deterministic adjudication of an open dispute: the same inputs always produce the same verdict and rationale — no discretion, no model in the loop — and the verdict object embeds the inputs it was computed from. Side effects: writes the verdict to the dispute record; a refund verdict also logs a PENDING refund entry against the receipt (not counter-signed into the chain; no money moves). Adjudicating twice is not meaningful; the first verdict stands (a second call returns 409). Returns the verdict, the rationale naming the rule applied, the adjudication inputs, the verdict digest, and the ledger signature over that digest.get_disputeFetch a dispute in full: its state, both sides' evidence references, the verdict and rationale once adjudicated, and the ledger signature over the record. Read-only — one network read, no key required, and safe to poll while a dispute is open.
Substack MCP Server tools 27
create_draft_postcreate a draft post on your Substack account.set_post_bodyreplace the body of a draft with a Substack document. This is the only way to write structured content — headings, lists, links, code blocks, images, buttons and a paywall. Create the draft first with create_draft_post, then call this with its id. The result reports how many nodes of each type were stored, so a caller can confirm that what it asked for is there. An image must already be hosted by Substack: this cannot upload one.upload_imageHost an image on your Substack publication and get back a Substack URL — the one thing image2.src in set_post_body and cover_image in update_draft will actually render. The source is either an http(s) URL, which the server downloads and re-hosts, or `path`, an absolute path to a local file on the machine running this server, which is read straight from disk: use that for an image you generated or edited locally, with no need to publish it anywhere first. Private and loopback hosts are refused, HEIC is not accepted, max 10 MB.list_subscribersList and filter the subscribers of your Substack publication. Supports the same 48 columns and operators as the Subscribers dashboard, combined with AND, plus free-text search, sorting and pagination. Returns `count`, the total matching the filters regardless of `limit`, so a call with limit 1 is a cheap way to size a segment. Engagement columns (email opens, post views, comments, shares, activity rating) can be filtered on here but are not part of the records this tool returns — use export_subscribers to read their values.export_subscribersExport subscribers with their full column values, including the engagement metrics list_subscribers can filter on but not return: email opens over 7d/30d/6mo, unique emails seen, post views, unique posts seen, comments, shares, links clicked, days active and activity rating. Takes the same filters as list_subscribers and covers the whole matching set — there is no paging. Substack generates the file asynchronously, so this waits for it and returns the parsed records. One column cannot be exported and is reported in `missing_columns` rather than failing: tag_ids.list_postsList the posts of your Substack publication: drafts, published posts or scheduled posts. Supports free-text search, pagination and sort direction. Each post is returned as a summary; use get_draft for the full content of an unpublished one.get_draftRead one draft post of your Substack publication in full, including its body and its audience and email settings. Take the id from list_posts or create_draft_post.update_draftChange an existing draft's title, subtitle or any of its Post settings: audience, who may comment, comment order, cover image, social preview title and description, SEO title and description, and URL slug. The update is partial: only the fields you pass change, everything else — including the body — is left alone. A cover_image not already hosted by Substack is downloaded and re-hosted first. Take the id from list_posts or create_draft_post.publish_draftPublish a draft. The post goes live on the web; `send` additionally emails it to subscribers and defaults to false, because an email cannot be recalled. Publishing cannot be undone from this server — there is no unpublish tool.delete_draftDelete an unpublished draft. Refuses if the id belongs to a published post: Substack deletes both through the same endpoint, and removing a live post is irreversible, so that is left to the dashboard.get_publicationRead the settings and identity of your Substack publication: name, subdomain, custom domain, hero text, copyright, sender name, logo, plans and payment state. Returns a projection by default; pass full: true for all 111 fields.get_user_profileRead the account behind the session: id, handle, name, bio, and every publication you have a role on. This is how to discover which publications the session can reach, beyond the one SUBSTACK_PUBLICATION_URL points at.- +15 more on the listing page
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.
Evidence
{
"mcpServers": {
"evidence": {
"command": "npx",
"args": [
"-y",
"tersign"
]
}
}
}
Substack MCP Server
{
"mcpServers": {
"substack-mcp-server": {
"command": "npx",
"args": [
"-y",
"substack-mcp@latest"
],
"env": {
"SUBSTACK_PUBLICATION_URL": "YOUR_SUBSTACK_PUBLICATION_URL_HERE",
"SUBSTACK_SESSION_TOKEN": "YOUR_SUBSTACK_SESSION_TOKEN_HERE",
"SUBSTACK_USER_ID": "YOUR_SUBSTACK_USER_ID_HERE"
}
}
}
}
Frequently asked questions
Evidence is categorized under Developer Tools and uses a local stdio subprocess. Substack MCP Server belongs to Developer Tools and uses a local stdio subprocess. Pick Evidence for developer tools work and Substack MCP Server for developer tools.
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.
Evidence has no declared pricing — check the project's own site. Substack MCP Server 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 evidence and substack-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Evidence has a quality signal of 63/100 (Good) with 3 views, 0 installs and 1 GitHub stars. Substack MCP Server has 67/100 (Great) with 2 views, 0 installs and 87 GitHub stars.