The Integrations & Tools settings page gives admins one place to control which integrations and custom MCP servers the AI assistant can use. This article covers where to find the page, how integration access works across your organization and tenants, and how the two custom MCP policies and the MCP Inventory work together.
Where to find it
MSP admins (global policy): log into Admin, go to Settings, then Integrations & Tools. Changes here apply to your whole organization and every tenant you manage.
MSP admins (one tenant): go to Tenants, open a tenant, then Integrations & Tools in the tenant sidebar. Changes here apply only to that tenant.
Workspace admins: go to Workspace settings, then Integrations & Tools. Changes here apply to your workspace.
Available integrations
Each integration row has a toggle. Turning an integration off means the AI assistant can no longer connect to it or use any of its tools in chat, workflows, or apps for everyone at that level.
How inheritance works: when an MSP disables an integration globally, tenant admins see that integration locked with a "Locked by MSP" badge and cannot turn it back on. Tenant-level changes only ever affect that tenant. There is no way for a tenant to override an MSP-level restriction; if access should be restored, the MSP admin re-enables it at the global level.
Each integration's available tools are listed on its page in the Workshop. When an integration is disabled by policy, its Workshop page shows a locked notice instead of the connect flow, so users with a saved link cannot start a connection that would be rejected.
Custom MCP policy
Custom MCPs are external MCP servers your users connect themselves. Each user registers their own servers and only that user can use them; custom MCPs are never shared between users. The policy card has two separate controls because they govern two different doors:
Allow MCP creation controls the front door: whether users can register new custom MCP servers.
Allow MCP use controls all contact with registered servers: running their tools, checking which tools they offer, and completing OAuth authorization. It covers every registered server, including ones users added before the setting was changed.
Both are needed because turning off creation only stops new registrations; everything registered earlier would keep running. Allow MCP use is the off switch for what already exists. Turning it back on restores everything instantly, because nothing is deleted by the policy.
The two settings work independently. While use is off, users can still register new servers as long as creation is allowed; servers that authorize with OAuth wait in a Pending auth state until use is turned back on, since completing authorization requires contacting the server.
The two most common setups:
Freeze growth: creation off, use on. No new custom MCPs can be added, but nobody's existing setup breaks.
Lockdown: both off. The AI assistant will not run any custom MCP tool, and tenant admins cannot override an MSP-level lockdown.
A small line under Allow MCP use shows how many custom MCP servers are currently registered at that level, so you can see what a change would affect before you make it. The confirmation dialogs also spell out the impact before anything is saved.
MCP Inventory
The MCP Inventory card lists every custom MCP server registered at your level: MSP admins see servers across all managed tenants grouped by tenant, and workspace admins see their workspace's servers. Each row shows the server name, who registered it and when, and its address with any sensitive parts removed.
Per-server controls:
Disable stops that one server from being used. The owner cannot re-enable it themselves.
Delete permanently removes the server. This cannot be undone, and the owner loses access to its tools.
Status badges: a row may show Auth failed, Unreachable, or Pending auth next to the server name. These reflect the most recent time Hatz checked the server, shown by the "checked … ago" label next to the badge; they are not a live health monitor. A server with no badge was healthy the last time it was checked. "Not yet checked" means the server has never completed a connection check, which is normal for servers still waiting on authorization. While Allow MCP use is off, servers are not re-checked, so badges keep showing the last check from before the policy took effect.
When custom MCP use is disabled by policy, the inventory stays visible so you can still audit what exists. The enable toggles lock while the policy is in effect, and deleting servers still works so you can clean up entries that should no longer be registered. Your users keep access to their own custom MCP page in the Workshop with a notice explaining the restriction: their per-server actions lock and their servers' tools show as unavailable. That page is hidden only when creation and use are both disabled.
Disable vs delete vs policy, at a glance
Policy (Allow MCP use off): blocks every custom MCP at once, keeps everything registered, fully reversible with one toggle.
Disable one server: blocks just that server, keeps it registered, reversible by an admin from the inventory.
Delete one server: removes it permanently. Not reversible.
Troubleshooting
A user says their tools are "blocked by policy" in chat: a policy at the workspace or MSP level is denying that integration or custom MCP use. Check the Integrations & Tools page at the level shown in the message. Users are told to contact their administrator when something is locked by policy, so expect these requests to come to you; admin views show the lock without that prompt.
A server shows Auth failed: its credentials were rejected, either during a check or while the assistant tried to use it. The owner should update the server's credentials, or re-authorize it if it uses OAuth. Note that re-authorizing requires Allow MCP use to be on, since it contacts the server.
A server shows Unreachable: Hatz could not connect to the server's address the last time it checked. This is a network or availability problem on the server side, not a credentials problem.
A disabled server "came back": the owner may have deleted it and registered the same server again, which creates a fresh entry. To prevent this, turn off Allow MCP creation, or use the policy toggle instead of per-server disables.
An integration toggle is locked: a higher level disabled it. Hover the lock badge to see where the restriction comes from; only an admin at that level can lift it.