Transparency log · MCP tool definitions
Your AI client trusts the tool descriptions an MCP server sends it — and a server can change them after you approved it. HISTOR keeps a public, signed record of what every remote MCP server in the official registry advertised, and tells you the day it changed.
Remote endpoints: it lists tools and never calls one. Registry packages: bounded canary calls run inside the isolated sandbox. It never says a server is safe — it tells you what was said, and when.
WebGL is unavailable here. The picture is the log itself: each label is a leaf, leaf hashes climb a Merkle tree, and a signed tree head seals the root.
What HISTOR is for
When you connect an MCP server, its tool descriptions go straight to the model as instructions. A server can pass your review with harmless descriptions and change them next week — one added sentence is all a prompt injection needs, and most clients never ask you again.
Every day HISTOR reads what each remote (streamable-HTTP) endpoint in the official MCP registry advertises, fingerprints it, signs what it saw and appends it to a log that can only grow. When a server's definitions change, the change gets a date and a diff.
Look up any server before you trust it. Paste what your client received and learn whether everyone else sees the same thing. Follow changes in a feed, or put a badge in your README. Every answer is signed, so you can verify it instead of believing it.
dev.cotlet/substack · https://cotlet.dev/mcp/v1/substack
Posts, Notes, messages, subscribers and stats for your publication.
add_subscriber — Add one email to your list as a free subscriber. Waits for the owner's approval.cancel_scheduled_post — Stop a scheduled post from going out; it stays as a draft.cotlet_apps — The apps of the user's workspace and whether each works now: access granted or requested, the app account in the user's Cloud Browser (connected, signed out, not enabled for agents), and the one step the user has to take, with the console link. Free. Needs the user's Cotlet API key or sign-in.cotlet_balance — The user's current credit balance. Free. Needs the user's Cotlet API key or sign-in.cotlet_browser_click — Clicks a link, button or other element of the current page in the user's browser on Cotlet, by its number in the page's element list, and returns the URL and title after the click. It acts as the user on that site. Buttons that pay or buy and buttons on account or sign-in pages are refused. Every started minute of the session costs credits; it ends when closed or 3 minutes after the last call in t …cotlet_browser_close — Ends the session in the user's browser on Cotlet (with `app`, that app's browser): the browser keeps its cookies, goes to sleep and the per-minute charge stops. Returns the session's minutes and credits.cotlet_browser_connect — Wakes the user's Cloud Browser of one app (a real Chrome on Cotlet, signed in to that app as the user) and returns cdp_url, a Chrome DevTools Protocol WebSocket that gives a CDP client full control of the browser. It works in one open tab, the app's: the user watches it live, and new tabs are refused. Every started minute of an open connection costs credits. Needs the user's Cotlet API key or sign …cotlet_browser_navigate — Opens a public http or https address in the user's browser on Cotlet and returns the URL and title it ended on. An app's browser opens only that app's pages. Every started minute of the session costs credits; it ends when closed or 3 minutes after the last call in that browser.cotlet_browser_open — Wakes the user's own browser on Cotlet, a real Chrome hosted for them: their web browser with the sites they signed in to there, or with `app` that app's browser, signed in to the app. Opens `url` when given and returns the page's URL and title. The user watches every step live. Every started minute of the session costs credits; it ends when closed or 3 minutes after the last call in that browser.cotlet_browser_press — Presses one key on the current page in the user's browser on Cotlet, on the element that has focus: Tab to the next field, Enter to send, Escape to close a dialog or pop-up, arrows to move through a suggestion list. Returns the URL and title after it. Enter on account pages is refused. Every started minute of the session costs credits; it ends when closed or 3 minutes after the last call in that b …cotlet_browser_read — Returns the current page of the user's browser on Cotlet: its readable text, up to 20,000 characters, and a numbered list of its links, buttons and fields. Field values, cookies and storage are never returned. On a page longer than that, both start near where it is scrolled to. Every started minute of the session costs credits; it ends when closed or 3 minutes after the last call in that browser.cotlet_browser_screenshot — Returns a JPEG image of the visible part of the current page in the user's browser on Cotlet, with its URL and title: boards, canvases and layouts that the page text does not show. Every started minute of the session costs credits; it ends when closed or 3 minutes after the last call in that browser.cotlet_browser_scroll — Scrolls the current page in the user's browser on Cotlet with the mouse wheel, as a person does: down or up by `screens` viewport heights (default 0.8), to the top or the bottom, or until element `element` is in view. Content that loads on scroll appears, and the next read lists it. Returns the URL, title and scroll position (at_top, at_bottom). Every started minute of the session costs credits; i …cotlet_browser_select — Chooses an option of a drop-down list on the current page in the user's browser on Cotlet, by the list's number in the element list and the option's label as read lists it (or its value). Returns the URL and title after it. Card fields and account pages are refused. Every started minute of the session costs credits; it ends when closed or 3 minutes after the last call in that browser.cotlet_browser_sessions — Open Chrome DevTools connections to the user's Cloud Browsers with the minutes and credits each has cost so far, and the cdp_url links still valid. With close: true it ends the open connections and takes back the unused links, of one app or of all. Needs the user's Cotlet API key or sign-in.cotlet_browser_type — Types text into a field of the current page in the user's browser on Cotlet, by the field's number in the page's element list, and with `submit` presses Enter. Returns the URL and title after it. Password, card and one-time code fields and sign-in pages are refused: the user fills those in themselves. Every started minute of the session costs credits; it ends when closed or 3 minutes after the las …cotlet_browser_upload — Puts files into a file field of the current page in the user's browser on Cotlet, or into the file picker that an upload button opens, by its number in the element list. A file is given as {"url": "https://..."} for a file online or {"file_id": "..."} for one uploaded to Cotlet first; up to 10 files, 20 MB each. Returns the URL and title after it. Every started minute of the session costs credits; …cotlet_get_call — Status of an earlier Cotlet call, by its call_id: pending (waits for the owner's approval in the Cotlet console), approved, running, success, rejected, expired, blocked or failed. For a call that answered with status pending or running.cotlet_report_issue — Sends a report straight to the Cotlet team: a tool that failed or returned wrong data, an error you could not get past, or a tool, field or app the task needed and Cotlet lacks. The report carries the error text and call_id when there is one, never passwords or tokens. Needs the user's Cotlet API key or sign-in.cotlet_request_apps — Requests access to apps for the user's workspace, as Request access in the console: a live app is granted at once, any other goes to the Cotlet team, who answer within 72 hours. Takes app slugs as listed at https://cotlet.dev/api/v1/apps. Free. Needs the user's Cotlet API key or sign-in.cotlet_upload_file — Returns a one-time upload_url and a file_id for a local file (an image for a post, an attachment). The file is sent to upload_url with an HTTP PUT; an argument that takes a file accepts {"file_id": "..."}. Up to 25 MB, the URL works once. Free. Needs the user's Cotlet API key or sign-in.cotlet_whoami — The Cotlet account this connection acts as: email, workspace, access status, the API key or OAuth client in use with its scope, the apps the workspace may call and its credit balance. Free. Needs the user's Cotlet API key or sign-in.create_draft — New draft from Markdown. Nothing is sent until you publish or schedule it.create_post_tag — New tag for grouping your posts.create_subscriber_tag — New private tag for grouping subscribers.delete_comment — Delete one of your own comments, Notes or Note replies. Waits for the owner's approval.delete_post — Delete a draft, scheduled or published post, with its comments. Waits for the owner's approval.duplicate_post — Copy any post into a new draft.export_subscribers — The full subscriber list as a CSV download link, with the row count.follow_user — Follow or unfollow a Substack user, so their Notes reach your feed.get_audience_insights — Where your subscribers live, and which publications share your readers.get_conversation — The latest messages of one direct-message conversation, oldest first.get_daily_stats — Day by day: total and paid subscribers, followers and views.get_feed — Your Substack home feed: posts and Notes, For you or Following.get_post — Full post: title, subtitle, body as Markdown, audience, URL and dates.get_post_engagement — Who liked and commented on a post, and the subscribers it won and lost.get_post_stats — Recipients, opens, open rate, views, likes, restacks and subscribers gained.get_post_traffic — Where a post's readers came from: sources, categories and devices.get_publication_stats — Total and paid subscribers, new subscribers, paid cancellations and estimated revenue for a period.get_unread_counts — How many unread direct messages, message requests and activity notifications you have.like_comment — Like or unlike a comment or a Note as you.like_post — Like or unlike any Substack post as you.list_activity — Your Substack notifications: replies, likes, new followers, restacks, newest first.list_comments — Comments on a post, with author, text and whether you replied.list_conversations — Your direct-message conversations, latest first, with the last message.list_note_replies — Replies under a Note, with author, text and likes.list_notes — Notes posted by you or any other Substack user, newest first, with likes and replies.list_post_tags — Tags your publication uses to group posts.list_posts — Posts of your publication, newest first, with status and audience.list_recommendations — Publications you recommend, or that recommend you, with the subscribers each sent.list_sections — Sections of your publication, the separate newsletters inside it.list_subscriber_tags — Tags you use to group subscribers.list_subscribers — Subscribers with plan, start date and activity rating.list_subscriptions — Publications you subscribe to, with your plan and whether their emails reach you.list_traffic_sources — Where your publication's visitors came from in a period, most views first.pin_comment — Pin a comment to the top of your post's comments, or unpin it.publish_note — Short post in Substack Notes, now or at a set time, optionally with a link card to one of your posts. Waits for the owner's approval.publish_post — Publish a draft now. Waits for the owner's approval.recommend_publication — Recommend another publication to your readers, or stop recommending it. Waits for the owner's approval.remove_comment — Remove someone's comment from your post as the publication's moderator. Waits for the owner's approval.remove_subscriber — Remove one email from your subscriber list. Waits for the owner's approval.reply_to_comment — Reply as you under a comment on your post. Waits for the owner's approval.reply_to_note — Reply as you under any Note or Note reply. Waits for the owner's approval.schedule_post — Publish a draft at a set time, on the web and by email. Waits for the owner's approval.search_substack — Search all of Substack for people, posts and Notes.send_message — Send a direct message on Substack, in a conversation or to a person. Waits for the owner's approval.tag_post — Add a tag to a post, or take it off.tag_subscribers — Put a tag on subscribers by email, or take it off.unpublish_post — Take a published post off the web and back to drafts. Waits for the owner's approval.update_draft — Change the title, subtitle, body or audience of a draft.The signed observations, every earlier tool set and a diff of each change: this page with scripts on, or /api/v1/servers/521c8963fb5c37d2.
Read → digest → label → append → sign → compare
Six steps, every one of them checkable by someone who does not trust HISTOR. The only thing you have to take on faith is that the observation happened when the label says it did — and the log makes it impossible to change that story afterwards.
Remote endpoints in the official MCP registry: initialize, then tools/list, drained across every page; no tool is called, and private addresses are refused before the connection opens. npm and PyPI packages: installed and started in the sandbox described below, with no route out.
The tool set is reduced to name, description, input and output schema, sorted by UTF-16 code units and hashed over its RFC 8785 canonical form. Anyone holding the same tools gets the same digest — which is what makes a comparison possible.
Four MTL/1 methods, one signed AWR/2 document each: what was observed, what the WARDEN pattern set matched, whether the definitions changed since the last label, and whether the name is on a threat list. No score, ever.
Every label becomes a leaf of an RFC 9162 Merkle tree: leaf hash = SHA-256(0x00 ‖ JCS(label)). The label you download is the leaf input, so you can recompute its hash yourself.
After each crawl HISTOR signs a tree head: the size and the root. Keep yesterday's head; ask for a consistency proof to today's; if anything was removed or rewritten, the proof fails.
Each day a continuity label compares the new digest with the last one. Equal: "unchanged since". Different: a change, with the date and a per-tool diff. A client that checks what it received adds the view no crawler has.
Where an npm or PyPI package is run
A package observation is true for these conditions, and no others. Every package page names the exact image it ran in and any configuration it was given.
Linux x86_64, inside gVisor (runsc): the package talks to a kernel written for sandboxing, not to the host's. An unprivileged user, no capabilities, a read-only root.
npm packages in histor-node:22, PyPI packages in histor-python:3.12: the official node:22-bookworm-slim and python:3.12-slim images plus bash, git, Python 3 or Node 22 and a Java 21 runtime — never Docker — built when a sandbox host is installed. A package whose Requires-Python excludes 3.12 runs on histor-python:3.13 or 3.14; one that requires a newer Node runs again on histor-node:24. The exact image a package ran in is on its page.
npm with --ignore-scripts, then the install scripts in a traced stage of their own. PyPI: wheels only — a package that ships only source is reported, never built.
No route out. Every name the package looks up resolves to HISTOR's own traps, which record what was sent and forward nothing. A server that needs the internet to start shows that here.
None are real. Decoy credentials sit in HOME and a decoy .env in the working directory. A variable the package says it needs gets a placeholder; where the placeholder was sent is recorded.
512 MB of memory, one CPU, 64 MB of /tmp. 360 s to install, 150 s to start and answer; up to 15 tools called once each with canary arguments, 8 s per call.
Only names: required variables its registry entry declares or that it printed when it exited, and a start argument such as serve when its usage text offers one. Never a value from anyone else.
The profile HISTOR implements forbids the words safe, secure, audited, certified, approved and trusted. Here is why, in the terms of what the log can and cannot show.
A pattern match is a reason to read a definition, not a finding. Three of the four methods can never return fail. There is no score to rank by, because no score HISTOR could compute would mean what a reader takes it to mean.
Labels are about advertised text. A remote endpoint's source is never read and its tools are never invoked; a package runs only in the sandbox, against nothing real. A server can keep identical definitions and behave differently for real users; the log cannot see that, and says so inside every label.
A version bump changes definitions too. A change is shown as a date and a diff, in amber, never red. What you do with it is yours: re-read, re-approve, or pin the old digest.
An npm or PyPI server is observed under the test conditions above: Linux, no internet, placeholder keys. One that needs Windows, a real account or the network may show fewer tools or none; its page says why it exited.
Today one party runs the log. A second observer on another network is the next step, and any AIMarket hub can run one. Until then, what the key proves is who said it — not that it is true.
Endpoints that require authentication answer 401 to everyone without a key, including HISTOR. They are counted and listed as not observed, never dropped from the numbers.
For clients, registries and server authors
Before your agent trusts a server, send the tools it received. The answer is signed by the log's did:key and names the tree head it was given under.
curl -sS https://histor.modelmarket.dev/api/v1/check \
-H 'Content-Type: application/json' \
-d '{"endpoint":"https://example.com/mcp","tools":[ …tools/list result… ],"contribute":true}'
# -> {"type":"histor.check/v1","match":"same"|"different"|"previously-observed"|…,
# "observed":{"unchangedSince":"…","changes":0}, "patternScan":{…}, "signature":{…}}
# README badge for your server
[](https://histor.modelmarket.dev/s/<id>)
# Atom feed of every observed change
https://histor.modelmarket.dev/feed.xml
No. The server list is the log's index: every remote endpoint in the official MCP registry, with what HISTOR could observe about it. Nothing here is for sale and nothing is ranked by quality.
No, and it never will. It tells you what a server advertised, whether that changed, and which published patterns matched the text. Whether to trust the server is your decision — HISTOR makes sure you decide on the same facts as everyone else.
Most remote MCP endpoints require a login (they answer 401 to anyone without a key), some use the legacy SSE transport or need per-user values in the URL, and some are simply down. They stay on the list with the reason, so the numbers never hide them.
Open the Check tab, paste the server's endpoint and the tools/list result your client received, and press Check. You get back, signed, whether HISTOR observed the same definitions — or different ones, or an older set.
Find your endpoint on the Servers tab, open it, and copy the Markdown snippet under the facts. The badge shows the date your definitions were pinned or last changed, and links to the full history.
You do not have to. Every label and every tree head is signed with one published key; the Log tab proves in your browser that the log only grew; and the command-line auditor does the same from any machine. What remains is that one operator runs it today — a second, independent observer is the next step.
Looking things up, the badges, the feed and /check are free. HISTOR also offers histor.check@v1 to the AIMarket Hub, so agents can reach it through the market.
Once a day: initialize, notifications/initialized and tools/list — never a tool call, never a redirect followed, at most two connections per host, from a User-Agent that starts with histor/. To be left out, open an issue on the histor repository with your endpoint or host; it is then listed as not observed (operator-opt-out), with the reason, rather than silently dropped. Labels already in the log stay: the log only grows.