Skip to main content

​
Overview

MCP servers evolve — a tool’s input schema gets a new required field, an output shape changes, a tool is renamed or removed. When that happens underneath a policy you’ve written, the policy can silently stop matching the tool it was meant to govern. MCP Change Management gives you visibility into exactly what changed on a connected server, which of your policies it touches, and an alert when it happens.

​
How It Works

Barndoor captures a version of each connected server’s tool listing. A scheduled check runs once a day (02:00 UTC) against every connected server with a reachable upstream, and a new version is appended only when something actually changed — a check that finds nothing new records the check without creating a version. The same capture also happens outside the schedule. Each version records what triggered it:
Servers whose tools are declared in configuration rather than read from a running server — embedded and locally-deployed servers — have no upstream to probe, so the scheduled check skips them. Soft-deleted servers are skipped too.
When a version is captured, Barndoor runs a policy impact analysis to identify which of your access policies reference an affected tool, so you can see not just what changed but what it touches.

​
The Tool Data & History Page

Open a server from MCP Servers, then choose Tool data & history from its settings menu. The page shows:
  • Fetch status — the server’s Source (Barndoor, Official, or Custom) and the number of Tools in latest version
  • Clocks — Last checked (when a check last ran, whether or not anything changed), Last changed (when the current version was captured; never moves without a real content change), and Last verified (when upstream last confirmed the current content is still current — this moves on every successful check, including ones that found nothing new)
  • Latest change · vN — the newest version’s change breakdown, with View what changed for the full delta
  • Version history — every captured version, newest first
  • Current tools — the tool listing stored at the newest version
  • Impacts — the access policies a detected change affects
Use this page whenever you’re about to write a new policy against a server, or when you get an alert that one changed, to see the current state before you act.
There’s no manual refresh control here on purpose. Reloading the page re-reads the stored versions; forcing a fresh upstream probe is a separate, heavier operation. History is retained 50 versions deep.

​
What the status says

The status on the fetch card distinguishes outcomes that are easy to conflate: A failed check names what went wrong rather than just “error”: Credentials needed, Server unreachable, Timed out, Refused an empty listing, or Retries exhausted. Credentials needed is the common one, and it distinguishes a server that has never had a usable credential (connect it) from one whose stored credential was rejected (reconnecting may be required).

​
What “changed” means

A change breakdown reports these categories:

​
Reviewing Policy Impact

An impact links one detected change to one policy that references the affected tool. Each carries a severity — Breaking, Needs review, or Info — and a status of Open, Acknowledged, or Resolved. Impacts appear in two places: as a severity badge beside each policy on the Access Control Center list, and as an Impacts section on a policy’s detail view. Click Acknowledge on an impact once you’ve reviewed it.
Acknowledging an impact records that you’ve seen it. It does not change the policy — updating rules to match the server’s new tools is still yours to do.

​
Getting Notified

Subscribe to the MCP server tooling changed alert to hear about a change as it’s detected, instead of finding out when you next open the portal. See Notifications to set up delivery to your in-app inbox, email, Slack, Microsoft Teams, or a webhook.
Pair this with a routine review of the Tool data & history page — the alert tells you that something changed; the page shows you exactly what, and which policies to check.

​
FAQ

Connected servers with a reachable upstream — Barndoor-hosted, official, and custom remote servers. Servers whose tools are declared in configuration (embedded servers, and locally-deployed servers pushed via MDM) have nothing to probe and are skipped, as are servers with checks paused and servers that have been deleted.
Daily, at 02:00 UTC. Captures also happen when a server is connected, when a refresh is forced, and on a handful of other system events — so version history isn’t strictly one row per day. Each version records which trigger produced it.
No. Policy impact analysis identifies which policies reference an affected tool so you can review and update them yourself — it doesn’t change policy behavior automatically.
Because a version is captured only when the tool listing actually moved. A check that finds nothing new advances Last checked and Last verified without appending a version — which is why those two clocks and Last changed are shown separately.
Only if a channel is subscribed to the MCP server tooling changed alert under Notifications. Without a subscription, changes are visible on the Tool data & history page but won’t be pushed to you. That alert is released progressively, so it may not be in your picker yet.

​
In this section

Notifications

Subscribe to the MCP server tooling changed alert.

Managing Policies

Review and update the policies a tool change impacts.