# How to Keep MCP Servers Up to Date: A Five-Minute Review > Keep MCP servers up to date: where versions live (npm, PyPI, MCP Registry, serverInfo), how clients refresh tool lists, and a five-minute review per update. Published 2026-11-02 by mcp.tc. Canonical: https://mcp.tc/blog/keep-mcp-servers-up-to-date **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](https://modelcontextprotocol.io/specification/2026-07-28/server/discover) 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. | Source | What it tells you | How to read it | | - | - | - | | `server/discover` | The name and version the running server reports, its supported protocol versions, capabilities and `instructions` | One JSON-RPC request to the server, or `npx mcp-tc check ` | | npm or PyPI | Every published version of a local server's package | `npm view versions`; the uv docs for Python tools | | MCP Registry | The versions a publisher registered in `server.json` | `GET /v0.1/servers/{serverName}/versions` | | Repository releases | Release notes written by the maintainer | GitHub Watch, Custom, releases | The [npm view docs](https://docs.npmjs.com/cli/v11/commands/npm-view) 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](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/official-registry-api.md) 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](https://docs.npmjs.com/cli/v11/commands/npx) say that packages "not present in the local project dependencies" are "installed to a folder in the npm cache", and the synopsis is `npx -- [@] [args...]`. Writing the version into the config fixes it until you change it. A pinned entry in a generic client config looks like this: ```json { "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](https://code.claude.com/docs/en/mcp) say "Everything after `--` is passed to the server untouched": ```bash 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](https://docs.astral.sh/uv/guides/tools/) says "To run a tool at a specific version, use `command@`", 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 ` upgrades an installed tool while respecting the constraints you gave at install time. The [uv cache page](https://docs.astral.sh/uv/concepts/cache/) adds `--refresh` to "force uv to revalidate cached data for all dependencies" and `--refresh-package ` for one. Pinning turns "which version am I running?" into a line in a file. The [pin MCP server versions](https://mcp.tc/blog/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](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) 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](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching) 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: | Client | On `list_changed` | Manual refresh | | - | - | - | | Claude Code | An interactive session "fetches the updated list"; `-p` mode and the Agent SDK refresh "only the tool list"; if a refresh request fails it "keeps the server's previously discovered tools, prompts, and resources until a later refresh succeeds" | Select Reconnect from the server's menu in `/mcp`, or `/mcp reconnect all` (v2.1.284 or later) | | VS Code | The management page documents the manual actions in the next column | Run `MCP: List Servers` from the Command Palette, select the server, choose Restart Server; "If this action isn't offered, stop the server and then start it again" | Both rows come from the [Claude Code MCP docs](https://code.claude.com/docs/en/mcp) and the [VS Code page on managing MCP servers](https://code.visualstudio.com/docs/agents/run/manage-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](https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications) 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 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](https://modelcontextprotocol.io/specification/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](https://mcp.tc/blog/mcp-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](https://mcp.tc/cli) 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 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](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) 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](https://mcp.tc/blog/mcp-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](https://mcp.tc/docs/connect) 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](https://mcp.tc/blog/is-this-mcp-server-safe) 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](https://mcp.tc/docs/changes) 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](https://mcp.tc/i/mcp-tc#history), and the [Recent changes](https://mcp.tc/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](https://mcp.tc/directory), [suggest it](https://mcp.tc/submit) and its tool list joins the 3-hour comparison once it is listed, provided the server shows its tools without sign-in. ## FAQ ### Does `npx -y package` always run the newest version of an MCP server? No. The npx docs say a package that is not in the local project is installed to a folder in the npm cache, and the synopsis accepts `[@]`. If you want to know which version runs, write it into the command (`npx -y example-server@1.4.2`) and change it on purpose. `npm view example-server versions` lists what has been published, so you can compare your pin with the newest release before you move it. ### How do I see which version of a remote MCP server I am talking to? Send a `server/discover` request. The 2026-07-28 specification says servers must implement it and should include `_meta['io.modelcontextprotocol/serverInfo']` with the server's name and version, alongside its supported protocol versions, capabilities and optional `instructions`. The value is self-reported and not verified by the protocol. `npx mcp-tc check https://mcp.example.com/mcp` prints the same fields together with the tool count. ### Does Claude Code pick up new tools without a restart? According to the Claude Code MCP docs, when a server sends a `list_changed` notification an interactive session fetches the updated list, and `-p` mode and the Agent SDK refresh only the tool list. If the refresh request fails, Claude Code keeps the previously discovered tools until a later refresh succeeds. To force it, select Reconnect from the server's menu in `/mcp`, or run `/mcp reconnect all` on v2.1.284 or later. ### What does mcp.tc's History tab show, and what can it not show? The History tab shows the dated changes mcp.tc's own checks found in a listing's tools and version (added and removed tools, changed descriptions, schemas, annotations and instructions, and new version numbers), plus edits the server owner saved. It only covers tool lists mcp.tc can read without signing in, so servers that list tools after sign-in and local servers without a manifest have no watched tool list. A change undone between two 3-hour checks can be missed, and it is not a security review. ### How often should I review the MCP servers I use? Review a server whenever its version changes and whenever you learn its tool list changed. For pinned local servers that means every time you move the pin; for remote servers, every time `server/discover` reports a new version or a History entry or follow email arrives. The review itself is five steps: version, tool names, descriptions and parameters, annotations and instructions, then re-approval in the client. ### Can I get a feed instead of an email? Yes. Every mcp.tc listing has an Atom feed of its History at the listing link plus `/history.xml`, and `https://mcp.tc/changes.xml` carries the newest changes across the whole directory. Add them to the feed reader you already use for GitHub releases or package updates. Email follows need an mcp.tc account; the feeds do not. ## Sources - - - - - - - - - - - -