---
title: "MCP Server Change History and Alerts | mcp.tc"
description: "What mcp.tc records when an MCP server changes: tool lists we read every 3 hours, a History on each listing, Atom feeds and email alerts when you follow one."
url: "https://mcp.tc/docs/changes"
markdown: "https://mcp.tc/docs/changes.md"
lang: "en"
---

# Change history and alerts

Every 3 hours mcp.tc reads the tool lists it can see without signing in, and each listing keeps a public History of what changed. Follow a listing to get an email when it changes.

## What we read every 3 hours

A check runs every 3 hours. For each listed server, it reads what it can without signing in or running anything:

- Remote servers that list their tools without sign-in: we run the MCP handshake and `tools/list`, as a client would, and record the tools, the server’s `instructions` and the version it reports.
- Servers whose tools are described in an MCP bundle: we read the `manifest.json` in their GitHub repository again, at its latest commit.
- Local servers published on npm or PyPI: we look up the latest version. We never run local servers.
- mcp.tc’s own [MCP server](https://mcp.tc/docs/mcp).

Servers that ask for a sign-in or an API key before they list their tools, and local servers without a bundle manifest, have no tool list we can watch. Their History records the version when we can read it, and edits by the server’s owner. Right now we can read the tools of 159 listings.

The top of each listing’s History tab says which of these applies to it and when we last read its tools. Every remote server also gets a health check once a day.

## What counts as a change

For a server whose tools we read, the History records:

- tools added or removed (a renamed tool shows as one removed and one added);
- for a tool that stays: a new description or title, parameters added, removed or newly required, new parameter descriptions, a new input or output schema, and hints that flipped, such as `readOnlyHint` or `destructiveHint`;
- invisible characters in a tool’s description or parameters, such as zero-width or text-direction marks, which can hide text from people while a model still reads it;
- new server `instructions`, the text the server gives every client when it connects.

It also records new versions, as the server reports them or as its npm or PyPI package publishes them, and the edits the server’s owner saves to the listing, with the text before and after (for setup notes, only that they changed). Edits by us or from public sources such as the MCP Registry don’t appear in it, and neither does a listing being hidden or listed again. When a listing is deleted, its History and its follows go with it. The order of the tools, health and check times don’t count as changes.

## Two reads before a change

A change is recorded only when two reads agree. When a read differs from the last one we recorded, we read the server again at least a minute later, usually in the same run, and record the change only if the second read shows the same thing. A read that fails, stops early or returns only part of the list counts as no data, never as tools removed. A tool list that becomes empty needs two reads at least two hours apart.

The first read of a listing is its starting point. The History shows it as “Tracking started”, with the number of tools, and nothing before it counts as a change.

Once a change is confirmed, the listing shows the new tool list straight away. A new tool appears with the server’s own title or the first sentence of its description.

Versions work the same way: a version the server reports is recorded once two reads agree, and the latest version of an npm or PyPI package straight away. Only version numbers count, such as `1.3.0` or `v2.0.0-beta.1`. A listing gets at most one version change in 24 hours, and a version that goes back to one recorded in the past week isn’t recorded again. It also gets at most three tool changes in 24 hours: a fourth waits until the first of them is 24 hours old. Dates in a tool’s text, such as today’s date, are left out when we compare.

## Reading the History tab

Every listing has a **History** tab next to Overview, Integrate and FAQ; see [DeepWiki](https://mcp.tc/i/deepwiki#history) for one. Entries are newest first, each with the date and time in UTC, where the change came from and a one-line summary:

- **Automatic check**: our own reads of the server.
- **Server owner**: an edit by someone who proved they run the server. We never show who.

Open an entry for the details: the tools added and removed, each changed description before and after, the parameters that changed, the hints that flipped and the server instructions before and after. Badges point out changes worth a closer look, such as a tool that lost its read-only hint or gained a destructive one, a new tool marked destructive, a newly required parameter, invisible characters or new server instructions. Hints are labels a server gives its own tools: they tell you what the server says a tool does. Text quoted from a server comes from the server itself and is shown as plain text.

The tab shows every entry, newest first, 100 per page, with every detail for the newest 10; older ones show their summary and the names of the tools. Each entry has its own address, the link of its page plus `#ch-` and a number, so you can link to it. The History stays as long as the listing exists. We can hide an entry when a reading turns out to be wrong, or on request. Hidden entries aren’t shown or emailed.

## Feeds and the Recent changes page

You don’t need an account to keep an eye on changes:

- [Recent changes](https://mcp.tc/changes) lists the 50 latest changes across the directory.
- [`/changes.xml`](https://mcp.tc/changes.xml) has the same list as an Atom feed.
- Each listing’s History is an Atom feed too, with its 30 latest entries, at its link plus `/history.xml`, for example [`mcp.tc/i/deepwiki/history.xml`](https://mcp.tc/i/deepwiki/history.xml).

Programs can read the same data: the listing JSON has a `history` object, the listing Markdown includes its five most recent changes, and `get_server` on mcp.tc’s [MCP server](https://mcp.tc/docs/mcp) returns them too. [API and data](https://mcp.tc/docs/api#feeds) has the details.

## Follow a listing

[Sign in](https://mcp.tc/account) with GitHub or a code sent by email, then press **Follow** at the top of a listing. It’s free, and you can follow up to 200 listings. Your [Following](https://mcp.tc/account/following) page lists them with their recent changes and an Unfollow button, and sets how you get emails:

- as changes happen, at most one email an hour (the default);
- a daily summary;
- no emails.

One email covers every listing you follow that changed since the last one. It names each listing and sums up what changed (for example “2 tools added, 1 removed”). An email about one listing links to that change in its History (or to your Following page when the listing has left the directory); an email about several links to your Following page, which lists their recent changes. It never quotes a tool’s description, which is the server’s own text. Only changes recorded after you started following are emailed, and none older than 7 days. A new version on its own is emailed only when its number goes up, as from 1.2.0 to 1.3.0: not for a new build label on the same number, and not for a step back to an earlier version. Changes that cancel out before we email you, such as a version that changes and then changes back, aren’t emailed.

Every email has a stop link that works without signing in. In an email about one listing, its page lets you unfollow that listing or turn change emails off; in an email about several, it turns change emails off. The link opens a page with buttons, so a mail scanner that opens links can’t change anything, and the page lets you undo what you just did. Your email app’s unsubscribe button opens one of these pages too: one press there turns change emails off and keeps your follows. Deleting your account deletes your follows. The [privacy policy](https://mcp.tc/privacy#accounts) says what we keep and what the email service receives.

## What the History can’t tell you

The History shows what mcp.tc’s own anonymous reads saw at each check. It isn’t a security review, and it doesn’t block, approve or vouch for anything.

- It can’t see tools a server shows only after sign-in, or only to some clients. A server can answer our check with one list and your client with another.
- A change made and undone between two checks can be missed.
- Local servers never run here, so what a package does once it starts isn’t checked.
- When a server is down or cuts a read short, that check records nothing.

Before you approve a server’s tools in your client, and again after an update, read the tool list your client shows: that list is what your model gets. The History tells you when it’s worth looking again.

## For server owners

Edits you save to your listing appear in its History as changes by the server owner, without your name or account, and are emailed to people who follow the listing. So are the tool changes our check finds: ship a new tool list and the listing usually shows it within 3 hours, once two reads agree.

We can watch your tools only if `tools/list` answers without a sign-in, or if your repository has an MCP bundle manifest that lists them. Annotate your tools with `readOnlyHint` and `destructiveHint`, so the History can show when those hints change. [For server owners](https://mcp.tc/docs/server-owners) covers the rest.

---
Source: https://mcp.tc/docs/changes. Markdown version for AI agents (ask for `text/markdown` or add `.md` to the address). Site overview: https://mcp.tc/llms.txt