Tool change notifications
See when a remote MCP connector adds, removes, or modifies tools, get alerted in Slack, and review the change before your users pick up the new tool surface.
Remote MCP connectors can change their tool surface at any time, and the next manifest refresh carries those changes into every Virtual MCP (VMCP) that includes the connector. Review new, removed, renamed, or rewritten tools before production callers pick them up, because tool descriptions feed directly into an agent's reasoning: a connector that behaves well at install time and changes later (a rug pull), or one whose descriptions carry hidden instructions (tool poisoning), can steer agents without any code changing on your side. For the threat model, see prompt security and tool governance.
What triggers a notification
MintMCP compares each refreshed manifest against the previously stored version for the same connector. A notification fires when any of the following change:
- Tool added: a tool name that wasn't in the previous manifest.
- Tool removed: a tool name that was present and is now gone.
- Tool modified: the tool's title or description changed, or its signature changed.
Connector-level metadata changes (name, title, version) are recorded and surfaced in the change history, but the Slack alert focuses on the tool list. If a refresh produces an identical manifest, nothing is stored and nothing is sent.
Where to review changes
Tool change review lives in the Tools tab of a VMCP's configuration, alongside tool customization. For VMCPs with a bound remote connector, admins see:
- Tool update policy: whether new tools are enabled by default or require manual approval.
- Slack alerts: an inline control, on the same row as the default-enable toggle, for configuring which Slack channels get notified.
- Tool change history: a paginated list of manifest versions, each with a short summary (
+2 added, 1 modified,Metadata-only change,Initial manifest). Expanding a version shows an inline diff of which tools were added, removed, or modified, with character-level description diffs.
Acknowledge changes
Each VMCP tracks the manifest version an admin has acknowledged. When the stored manifest moves ahead of the acknowledged one, the VMCP surfaces an "unacknowledged changes" state. Acknowledging a manifest means the admin has reviewed the diff and is opting into the current tool surface for this VMCP.
How acknowledgement interacts with the update policy:
- Enable new tools by default. When a new tool arrives, it is enabled for callers immediately and a Slack alert fires. Acknowledgement is a review step that records the admin looked at the change, not a gate on the tool becoming available.
- Require manual approval. A new tool arrives disabled. The Slack alert fires, but users cannot call the tool until an admin explicitly enables it in the tool customization UI.
Require manual approval for any VMCP whose callers run in production or whose connector is operated by a third party, because it closes the window where a new upstream tool could be called before a human has reviewed it. Enterprise organizations can enforce this everywhere with the org-wide Force-disable new tools policy, which makes new tools arrive disabled on every VMCP regardless of the per-VMCP setting (see Tool customization).
The first manifest for a newly added connector is implicitly acknowledged during setup: the admin sees the tool list at connector-add time and acknowledges it by choosing to use the VMCP.
Slack alerts
Notifications are delivered to Slack. Each alert includes the connector title, a breakdown by change type (added, removed, modified) with tool names, and a "View tools" deep link back to the VMCP's Tools tab.
A single connector can fan out to multiple Slack channels, and each channel subscription can be toggled on or off independently without removing it.
Organization default channels
Enterprise organizations can set a default set of Slack channels that receive tool-change alerts for every connector, instead of configuring each connector by hand. On the MCP store page, open the settings tab (the gear icon) and use Default Slack alerts for tool changes: pick a channel, click Add alert, and repeat for each channel you want. Each row has an Enabled switch to pause a channel without removing it, and a trash icon to remove it.
By default, every connector inherits these channels. A connector's own alert settings override the default.
Per-connector alerts
Open a connector's Slack alerts control in the VMCP's Tools tab to see how it resolves against the organization default. Each connector is in one of three states:
- Using default Slack alerts (inherited): the connector sends to the organization default channels, shown read-only. Choose Override to set connector-specific channels, or Disable for this connector to stop all alerts for it.
- Custom Slack alerts (override): the listed channels replace the organization default for this connector. Add or remove channels and toggle each on or off. Reset to org default returns the connector to inheriting.
- Slack alerts disabled (opt-out): tool changes for this connector are not sent to Slack, even when the organization default has channels. Reset to org default returns it to inheriting.
Connect Slack
Slack alerts require a Slack workspace connection. Connect Slack once at the organization level, from the integrations settings; this authorizes MintMCP to post into chosen channels. If Slack is not yet connected, the alerts panel shows a connect button that points to the organization integrations page.
Alerts are only sent for channels that are both present in the subscription list and flagged enabled. A connector with no channels, whether opted out or inheriting an empty default, still produces manifest history entries but no Slack traffic.
Alert deduplication
Repeated detections of the same change deduplicate automatically: concurrent refreshes and flapping connectors produce one alert per distinct change per channel, not a flood.
Next steps
- Tool customization: configure the update policy, per-tool enable/disable, and name/description overrides for each VMCP
- Tool governance: how MintMCP governs dynamic tool changes and capability creep
- Prompt security: why tool descriptions are an attack surface for injection