Update an MCP Server: Check Versions and Verify the Connection

Updating an MCP server means installing a new version of the server package, confirming the client can still connect, and verifying that the tools it exposes are what you expect. A server update can change tool names, remove tools, change parameter requirements, or introduce new authentication steps. Any of those changes can silently break AI workflows that depended on the previous behavior. Tools like fenbs record what changed, any problems that came up, and the lessons that apply to future updates.

The update steps differ slightly depending on whether your server is a locally installed package, a server you built yourself, or a remotely hosted service. Each case is covered below.

How to update a local MCP server

1. Check the current version before updating. For an npm package, run npm list <package-name> or check the installed version in node_modules. For a Python package, use pip show <package-name>.
2. Review the changelog or release notes before updating. Look for tool renames, removed tools, changed parameter names, or new required configuration.
3. Update the package: npm install <package-name>@latest for npm, or pip install --upgrade <package-name> for Python. Verify the new version is installed.
4. Restart your AI client to force it to reconnect. The client fetches the tool list fresh on each connection.
5. Ask the AI to list the tools from the updated server. Compare the list to what you had before, and test any tool that changed.

How to update a self-built MCP server

If you maintain the server yourself, update your dependencies and rebuild. Before deploying, check whether any tool names, argument names, or return shapes changed in the dependencies. The AI client caches tool metadata; a tool that changed its argument schema without changing its name can cause confusing errors until the client reconnects and gets the new schema.

Run the MCP Inspector after rebuilding to confirm the updated tools match your expectations. Add or update any changed tools to your integration tests so the next update is faster to verify. See MCP server configuration if the update requires config file changes.

How to update a remotely hosted MCP server

For a server hosted by a third party, check the provider's release notes or changelog. A remote server may update automatically; the AI client reconnects on the next session and fetches the new tool list. If a tool you relied on is renamed or removed, your AI workflows will fail silently until you investigate.

Subscribe to release notifications for any remote server you depend on regularly. Check the MCP server spec when a provider announces a spec version change, since the client and server must agree on the transport and protocol version. The MCP server hosting guide covers the tradeoffs between self-hosted and third-party servers.

Check for changed tools or permissions

After any update, verify the tool list and test a call that you know should work. Pay attention to tools that deal with authentication: an update may change how credentials are passed, require a new scope, or expire an existing token. Test authentication flows before returning to normal use.

If a tool was removed or renamed, find all the places in your workflow where it is used. An AI assistant that calls a tool by name will receive a "tool not found" error if the name changed; it will use a replacement tool only if the new tool is clearly described and the assistant knows the old one is gone. Update your project context to document the change.

Record the change and what you learned

Updates that cause problems teach you something: what to check before updating, what to back up, what to test first. Those lessons have value for the next update, but only if they are written down somewhere the next person — or the next AI session — can find them.

fenbs lets you record both the change (which server was updated, what version, what changed in the tool list) and the lessons from any problems encountered. Lessons in fenbs are read by connected AI assistants before they do similar work, so a lesson about a tricky MCP update can prevent the same problem in the next session.

If you maintain your own MCP server, treat updates to its dependencies the same way: review changelogs for the MCP SDK and any service library you wrap, update incrementally rather than jumping multiple versions at once, and test with the MCP Inspector before reconnecting an AI client. Dependencies that change their tool-call API shape can break your handlers in ways that are not obvious from a version number alone. Keep a short note of which dependency version each server release uses, so a regression can be traced to a specific package change rather than requiring a full audit of the update history.

How to do this with fenbs

1. Create a free account and add a project for your MCP server setup.
2. After each update, add a note to the project: which server, which version, what changed in the tool list, and what was required to restore normal operation.
3. If the update caused a problem, add a Lesson learned: what broke, how you fixed it, and what to check before the next update.
4. Connect your AI app to fenbs at Integrations. The assistant reads the lessons before working with the server.
5. Record the update history so a future session can see what has changed over time without checking package manager logs.

fenbs does not manage your MCP server packages directly. It holds the change history and lessons that help your team update servers safely without repeating past mistakes.