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.
ai.appgoat/mcp · https://api.appgoat.ai/mcp
App Store and Google Play data: apps, reviews, keywords, charts, competitors, ASO playbooks.
apply_action — Go ahead with an action from propose_action, after the user has seen its diff and agreed. Outcomes: applied (written to the store / Apple Ads account, 1 credit; when the org has an auto-apply rule the guardrail score clears, or allows agents to approve); pending_approval (a person must approve it in the AppGoat dashboard: give the user the approve link, nothing is written until then); needs a pers …audit_app — Run an App Audit of one app in one country: a 0–100 score, prioritised ASO actions with evidence, title / subtitle / keyword rewrites within the store character limits, and findings from listing, ratings, reviews, keywords and competitors, plus a shareable report page. Takes 1–3 minutes: waits about 25 s, then returns the audit id to pass to get_audit. An audit of the same app, country and mode fr …get_action — One action from propose_action: its status (draft, pending_approval, approved, applied, failed, rejected), diff, guardrail scores, the provider result or error, the approve link and the audit trail. Use it to check whether a pending action was approved and applied. Cost: 0 credits.get_app — Look up one App Store or Google Play app: title, subtitle, developer, category, price, rating and histogram, installs (Play), version and dates, description, languages, and the same app in the other store. Accepts any id, bundle id, package, store URL or a name. Reads stored data (refreshed from the store only when older than max_age, default 7 days) for one country (default us); add include secti …get_app_changes — What changed in an app's store listing, newest first, with old and new values: version, release notes, title, subtitle, description, screenshots, icon, price, IAP, privacy, in-app events, badges, featuring, installs, content rating. Use it to monitor competitors ("what did X change this month?"). Cost: 1 + 1 if the US listing is refreshed credits.get_app_history — An app's daily metric history per country: rating, ratings count, reviews count, installs (Play), star histogram and price, one row per day a value changed (default the last 90 days), with the change over the period. Use it to chart growth or spot rating drops after a release. Cost: 1 + 1 per country refreshed (max 10) credits.get_app_keywords — The search terms an app ranks for in a country, best rank first, with popularity (5–100) and difficulty (0–100): from the weekly keyword universe plus your tracked keywords. Call it for the app and a competitor to find keyword gaps. Cost: 1 credits.get_audit — Check on an App Audit that audit_app started (by its id, e.g. aud_3fK9aQ2mXc81LpRt): waits up to about 25 s for it to finish, then returns the report (score, actions, metadata rewrites, findings, report page) or its status. Cost: 0 credits.get_charts — A top free, paid or grossing chart for a store, country and category, today or on a past date: rank, app, developer, rating and the move since the previous capture (new entries marked), plus apps that dropped out. Charts are captured daily for every country and category. Cost: 1 credits.get_competitors — An app's competitors, best first, scored from search terms both apps rank for (shared keywords) plus the store's similar-apps list. Feed the app ids into get_app or get_app_changes for a competitor digest. Cost: 1 credits.get_developer — A developer's profile: name, website, country, app count, total ratings and installs, all their apps (most-rated first) and the same company in the other store. get_app shows the developer id as dev <store>:<id>. Cost: 1 credits.get_events — Significant changes on your watched apps and keywords, newest first: type, one-line title, AI summary, significance (0–1), app, country and the key payload fields (version, changes old → new, rating drop, rank move, chart rank…). Filter by type, app, watch, since and min_significance. To check for news, pass since = the created_at of the newest event already handled. Cost: 0 credits.get_insights — What an app's users praise and complain about, from the AI tags on its reviews: top issues (topics behind negative, bug, crash, UX and pricing reviews) with last-30-days vs previous-30-days counts and sample reviews, topics, what each recent version changed in rating, sentiment and topics, and weekly sentiment. Use it for "what do users complain about since v2.3?" before reading individual reviews …get_job — Poll a background store fetch that another call started (its output said refreshing or still being fetched, with a job id): status, per-country progress. When it is done, repeat the original call. Cost: 0 credits.get_keyword_ranks — Ranking history of a watched keyword: per capture the top 10 app ids, or with app, that app's rank over time (best, worst, latest). Default the last 90 days. The id is a keyword slot of a keyword watch (list_watches and watch show the slot ids) or a list_tracked_keywords id. Cost: 1 credits.get_reviews — Read an app's user reviews, newest first, up to 100 per page: rating, title, text, version, date, developer reply and AI tags (sentiment, intent, severity, topic) where tagged. Filter by stars (rating='1-2' for complaints), version, date range, text (q) or AI tags (intent='bug,crash'; tag filters skip untagged reviews). Page with cursor. Cost: 1 per page + 1 if the US reviews are refreshed credits …keyword_research — Keyword metrics and research for App Store / Google Play search terms: popularity (5–100), difficulty (0–100), result count and the #1 result's estimated daily downloads. include adds related terms with metrics, the store's autocomplete and the current top 10 apps; app adds that app's rank and metadata relevance per term (the core of an ASO keyword audit). Unmeasured terms are measured live (a few …list_connections — The user's connected App Store Connect, Play Console and Apple Ads accounts: connection id, provider, mode (actions or read_only), status and the linked apps. Start here before read_connection or propose_action; secrets are never returned. No connections yet: the user adds them at https://dash.appgoat.ai/connections. Cost: 0 credits.list_playbooks — AppGoat playbooks: step-by-step recipes (which tools to call, credit budget, decision rules, output format) for app audits, app idea research, ASO metadata rewrites, weekly competitor digests, turning reviews into GitHub issues, and, on connected accounts, replying to every review, optimizing Apple Ads and pushing localized listings. Without name, lists them; with name, returns the full playbook t …list_tracked_keywords — Deprecated: use list_watches (keyword watches list their slots). Your tracked keywords with id, store, country, popularity, depth, cadence, last ranking and current top 3. Filter by store, country or a term substring. Cost: 0 credits.list_watches — Your watches (apps, competitor sets, keyword sets), newest first, with id, apps, terms, countries, event types and whether they are paused, plus watched apps and keyword slots used vs the plan's limits. Filter by kind or by an app they include. Cost: 0 credits.propose_action — Prepare a change to the user's connected account as a DRY RUN: nothing is written. AppGoat reads the live account and returns the before → after diff, guardrail results (AI probabilities for store policy, tone and risky claims, plus checks such as character limits and bid jumps) and an action id. ALWAYS show the diff and any guardrail flags to the user and get their go-ahead before calling apply_a …read_connection — Read live data from one of the user's connected accounts. what='reviews' (asc, play_console): the app's own reviews with reply status, unanswered=true for those without a developer reply; their review_id feeds propose_action review.reply (Play only returns reviews from the last 7 days). what='listing' (asc, play_console): the current listing text for one locale with lengths and which fields are ed …reject_action — Discard a draft or pending action the user does not want; nothing is written to the account. Cost: 0 credits.search_apps — Find apps by name or id in AppGoat's catalog of both stores (~5M apps): exact title matches first, then prefix, then substring, most-rated first. Returns store, app_id, title, developer, category, rating, ratings and price; pass the app_id to the other tools. Cost: 1 credits.track_keywords — Deprecated: use watch with kind keyword (also reports rank moves as events). Starts tracking the search ranking of terms in one or both stores and the given countries: ranked apps are captured daily from now on (idempotent; already tracked terms are reported as such). Each term × store × country uses one keyword slot of the plan; a request over the limit tracks nothing (plan_limit). Read history w …untrack_keywords — Deprecated: use unwatch for keyword watches. Stops tracking keywords by id (from list_tracked_keywords or track_keywords): no new rankings are recorded and their plan slots are freed. Cost: 0 credits.unwatch — Stop watches by id (from list_watches or watch): no new events, and their watched apps and keyword slots are freed. Past events are kept. To pause instead, call watch with id and active=false. Cost: 0 credits.watch — Watch an app, a set of competitors or a set of keywords; significant changes become events (get_events, webhooks, daily email). kind app {app}: new versions, metadata and price changes, featuring, rating drops, review and ratings spikes, chart entries. kind competitor_set {competitors, app?}: the same for every competitor. kind keyword {terms, store or app}: the app's rank moves per term and new a …The signed observations, every earlier tool set and a diff of each change: this page with scripts on, or /api/v1/servers/606cce50b7566bd1.
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.