> ## Documentation Index
> Fetch the complete documentation index at: https://docs.barndoor.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# MCP Change Management
> See every connected MCP server's tool inventory and version history, know which policies a change touches, and get alerted the moment a server's tools move.
## 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:
| Trigger | Meaning |
| ----------------------------------------------------------------------------------- | -------------------------------------------- |
| **Scheduled check** | The daily sweep |
| **Server connected** | A server was connected or reconnected |
| **Manual refresh** | A refresh was forced |
| **Config import** | Seeded from configuration rather than probed |
| **Cache warm**, **Tool call miss**, **Lifecycle event**, **Backfill**, **Rollback** | Other system-initiated captures |
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:
| Status | Meaning |
| ----------------------- | ------------------------------------------------------------------------- |
| **Changes detected** | The last check succeeded and captured a new version |
| **No changes detected** | The last check succeeded and found nothing new |
| **Checked** | The last check succeeded; whether it captured a version wasn't recorded |
| **Checking…** | A check is in progress |
| **Awaiting approval** | A new version was captured and is waiting for approval before it's served |
| **Checks paused** | Checks are paused for this server, so nothing was fetched |
| **Never fetched** | No check has ever been attempted |
| **Error** | The last check failed — see the error below |
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:
| Category | What moved |
| ------------------------------------------- | ----------------------------------------------- |
| **Added** / **Removed** | Tools appearing or disappearing |
| **Operation changed** | A tool's read/write classification |
| **Input schema changed** | A tool's accepted arguments — your call sites |
| **Output schema changed** | The shape of what a tool returns — your parsers |
| **Annotations changed** | Safety hints such as read-only or destructive |
| **Description changed** | A tool's documented purpose |
| **Resources added** / **Resources removed** | Non-tool resources the server exposes |
## 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](/how-tos/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
Subscribe to the MCP server tooling changed alert.
Review and update the policies a tool change impacts.