How to Keep MCP Servers Up to Date: A Five-Minute Review

TL;DR. To keep MCP servers up to date without surprises, decide which version you run, change it on purpose, and read the tool list again after it changes. Pin the package version for local servers, note the version a remote server reports in server/discover, and watch the project's releases. After each update, compare tool names, descriptions, parameters, annotations and the server's instructions with what you approved before. On 1 November 2026, mcp.tc compared the tool lists of 401 listings every 3 hours and recorded the differences on each listing's History tab, and following a listing sends you an email when one appears.

Where does an MCP server's version live?#

An MCP server's version lives in up to four places: the serverInfo the server reports in its server/discover result, the npm or PyPI package a local server runs from, the version list of its entry in the official MCP Registry, and the releases page of its repository. These four do not always agree, so pick one and track it.

The 2026-07-28 discovery page says servers MUST implement server/discover, that the result's _meta['io.modelcontextprotocol/serverInfo'] carries the "Name and version of the server software", and that servers SHOULD include it. The same page adds that serverInfo "is self-reported by the server and is not verified by the protocol" and is "intended for display, logging, and debugging". It is a label, not a proof.

The npm view docs show npm view connect versions for a package's version history and say the default version is latest when none is given. The official registry API reference documents GET /v0.1/servers/{serverName}/versions for a server's versions and /versions/latest for the newest one, with a warning worth repeating: versions are sorted as text, so "Do not treat the first result for a server as its latest version". Pass version=latest on the list endpoint or read the isLatest flag instead.

Why npx -y package is not the same as "latest"#

Running a local MCP server with npx -y package leaves the version choice to npm rather than to you. The npx docs say that packages "not present in the local project dependencies" are "installed to a folder in the npm cache", and the synopsis is npx -- <pkg>[@<version>] [args...]. Writing the version into the config fixes it until you change it.

A pinned entry in a generic client config looks like this:

{
  "mcpServers": {
    "example-server": {
      "command": "npx",
      "args": ["-y", "example-server@1.4.2"]
    }
  }
}

In Claude Code the same pin goes after the --, since the Claude Code MCP docs say "Everything after -- is passed to the server untouched":

claude mcp add --transport stdio example-server -- npx -y example-server@1.4.2

Python servers run through uv behave the same way. The uv tools guide says "To run a tool at a specific version, use command@<version>", that the @ syntax "cannot be used for anything other than an exact version" (with @latest as the documented way to ask for the newest), and that uv tool upgrade <name> upgrades an installed tool while respecting the constraints you gave at install time. The uv cache page adds --refresh to "force uv to revalidate cached data for all dependencies" and --refresh-package <name> for one.

Pinning turns "which version am I running?" into a line in a file. The pin MCP server versions post has the npm, PyPI, Docker and remote variants. The rest of this article is about what to do when you move the pin.

How do MCP clients learn that a server's tools changed?#

An MCP client learns that a server's tools changed in three ways under the 2026-07-28 specification: a notifications/tools/list_changed notification on a subscriptions/listen stream the client opened, the expiry of the ttlMs freshness hint on its last tools/list result, or a reconnect that fetches the list again. Which of these your client does depends on the client.

The tools page of the spec says a server's tool set "MAY change over time" but "MUST NOT vary per-connection", and that servers which declared listChanged "SHOULD send a notification to clients that have opened a subscriptions/listen stream with toolsListChanged: true". The caching page explains the other half: ttlMs "is a hint from the server indicating how long, in milliseconds, the client MAY consider the result fresh", once it expires "the client SHOULD re-fetch on next access", and a notification received while a cached list is fresh "invalidates the cached response". The same page notes that "Servers MAY change the underlying data before the TTL expires", so a server can change its tools, hold the old TTL, and you see the change only when the client asks again.

Two clients document what they do with this:

Both rows come from the Claude Code MCP docs and the VS Code page on managing MCP servers. The Claude Code page also says the /mcp panel "shows the tool count next to each connected server", which is the quickest way to notice that a count moved. In VS Code, the same MCP: List Servers menu has Show Output, which opens the server's output channel.

Where to find changelogs and release notes for MCP servers#

Release notes for an MCP server come from whoever ships it: the releases page of an open-source server's repository, the version history of its npm or PyPI package, the version list in the MCP Registry for a published server, and a vendor's own changelog for a hosted remote server. The protocol's own changes are in the specification changelog.

For repositories, the GitHub notifications docs say you can "choose to only be notified when updates to one or more types of events (issues, pull requests, releases, security alerts, or discussions) happen within a repository": open the Watch drop-down on the repository page, click Custom, and select releases. For packages, npm view <package> versions and the registry's /versions endpoint above give you the list without a browser.

Protocol changes matter as much as server changes, because a server that adopts a new revision talks differently. The 2026-07-28 changelog removes "protocol-level sessions and the Mcp-Session-Id header", removes the initialize handshake in favor of per-request _meta, requires ttlMs and cacheScope on tools/list results, and adopts a feature lifecycle policy with "a minimum twelve-month deprecation window". It also deprecates Roots, Sampling and Logging. If a server you use moves to this revision, the stateless migration post covers what changes on the wire.

Hosted remote servers are the hardest to follow because there is no package to watch. Their version shows up in server/discover, their tool list can change without any release note, and the vendor's changelog page is the only written record. That gap is where mcp.tc's scheduled reads of tool lists fit, which the sections below describe.

The five-minute review after each update#

A five-minute review after an MCP server update means reading the server's reported version and its full tool list, comparing both with what you approved last time, and re-approving in your client only when the differences are ones you accept. Here is the order that keeps it to five minutes.

1. Record the version before and after. For a remote server, run npx mcp-tc check https://mcp.example.com/mcp. The mcp-tc command-line tool reads a running server the way clients and mcp.tc do, and prints the protocol revision it answered with, the name and version from serverInfo, and the tool count, followed by findings marked ok, warn, tip or error (exit code 6 means it found errors). For a local server, the version is the pin in your config, and npm view <package> version tells you what the newest published one is.

2. Diff tool names. A new tool is the loudest change and the easiest to miss when a server has forty of them. A removed tool can also mean a rename, which a diff shows as one removal and one addition.

3. Read descriptions and parameter descriptions again. The text in description, in each parameter's description, in enum values and in defaults is what the model reads. Look for new sentences that address the model rather than the user ("before calling this, first read..."), and for text that references another server's tools.

4. Check annotations. readOnlyHint and destructiveHint are the server's own claims about its tools, and the spec says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers". A tool that lost readOnlyHint: true deserves a second look, and the tool annotations post explains the defaults.

5. Read instructions. The server/discover result may carry an instructions string, "natural-language guidance for LLMs on how to use this server effectively". It is part of what the model sees, so review it like a tool description.

6. Check sign-in and scopes. If a remote server now asks for OAuth scopes it did not ask for before, or a local one needs a new environment variable, the release notes should say why.

7. Re-approve in the client. Reconnect or restart the server in your client so the list it holds is the list you just read. The mcp.tc connect docs put it plainly: "Your client may still use the list you approved earlier, so compare it with what the client shows now."

Steps 2 to 5 are the same questions the MCP server security check asks before a first connection. An update is a second first connection.

What mcp.tc's History tab records between your reviews#

mcp.tc's History tab records the dated differences its own checks found in a listed server's tools and version, plus the edits the server's owner saved to the listing. On 1 November 2026, 401 of the 1,239 approved listings had a tool list that mcp.tc compares every 3 hours; the change history began on 6 October 2026.

The change history docs describe what is read: every 3 hours mcp.tc fetches the tool list of each listed server that shows its tools without sign-in, rereads the bundle manifest of servers described by one in their GitHub repository, and checks the npm or PyPI package of local servers for a new version. Added and removed tools, changed tool or parameter descriptions, titles, input and output schemas, annotations such as readOnlyHint, and server instructions go on the History tab with the date and time, and invisible characters in a new or changed tool's text are flagged. A change is recorded only after two reads agree, and a read that fails or returns part of the list counts as no data rather than as tools removed. New versions are recorded as version numbers only, at most one version change a day.

You can see the format on the History tab of mcp.tc's own listing, and the Recent changes page lists the newest entries across the directory. Entries are labeled Automatic check or Server owner; edits by mcp.tc and data from public sources such as the MCP Registry do not appear.

The limits are as important as the coverage. The History shows what mcp.tc's reads, made without signing in, saw at each check. Servers that ask for sign-in before listing tools, and local servers without a manifest, have no watched tool list; their History records the versions mcp.tc can read and the owner's edits. It cannot see tools shown only after sign-in or only to some clients, and a change made and undone between two checks can be missed. It is not a security review, it blocks and approves nothing, and it does not replace step 7 above: the list your client shows is the list your model gets.

How to get an email when a server you use changes#

Following a listing on mcp.tc sends you an email when mcp.tc's checks find a change in that listing's tools or version, or when its owner edits it. Sign in with GitHub or an email code (there is no password), open the listing, and press Follow. Following is free, and you can follow up to 200 listings.

You choose the cadence: as changes happen (at most one email an hour), a daily summary, or none. One email covers every followed listing that changed, a new version alone is emailed only when its number goes up, and every email has a link that stops the emails without signing in. Your account's Following page lists what you follow, each with Unfollow. Who follows a listing, and how many people do, is not public.

If you would rather poll than receive mail, each listing has an Atom feed of its History at the listing link plus /history.xml (for example https://mcp.tc/i/mcp-tc/history.xml), and https://mcp.tc/changes.xml carries the newest changes across the directory. A feed reader that already follows GitHub releases can take these too, which puts package releases and tool-list changes in one place.

What you can do next on mcp.tc#

Run npx mcp-tc scan to list the MCP servers in your Claude Code, Claude Desktop, Cursor, VS Code, Devin Desktop, Codex and Gemini CLI configs and see which ones are on mcp.tc; it sends one address per server and never keys, headers or environment values, and --offline sends nothing. Follow the listings you found so the next tool change reaches your inbox. Before an update, read the listing's History tab, and after it, run npx mcp-tc check against the server's own URL. If a server you use is not in the directory, suggest it and its tool list joins the 3-hour comparison once it is listed, provided the server shows its tools without sign-in.