Skip to main content
If you are a Claude Team or Enterprise admin, utilizing the Barndoor ToolIQ MCP simplifies your user’s experience in accessing your organization’s business systems while providing IT the access control governance tools to ensure AI is adopted safely. Instead of needing to configure, expose and manage the numerous connector MCP’s of the systems your organization uses and training your users how to enable/disable each when using Claude, you configure our single Barndoor ToolIQ URL and then let the Barndoor platform handle all the downstream access control and interactions. Your users then connect through that single entry point, while Barndoor decides which MCP servers, tools, and policies apply to them at runtime.
Best For: Enterprise teams that want one controlled Claude connector, centralized policy enforcement, and a simpler rollout and experience for users.

​
What This Achieves

With this setup:
  • Claude Enterprise admins add one Barndoor connector to the Claude organization
  • Claude users connect to the single connector instead of needing to select individual app connectors per prompt, command, or skill
  • Barndoor controls which MCP servers and tool calls are available by user, group or role
  • Fine grained access policies are enforced in Barndoor
  • New MCP servers and policy changes can be rolled out via Barndoor without requiring any change in Claude

​
Before You Begin

Before setting this up, make sure you have:
  • Claude Enterprise owner or admin access with permission to manage organization connectors
  • Your Barndoor ToolIQ MCP URL from the Barndoor AI Client Setup at https://app.barndoor.ai/settings/ai-client-setup
  • At least one registered Barndoor agent
  • At least one connected MCP server in Barndoor
  • Production policies prepared or in draft for the users and agents you plan to roll out
This guide assumes you want Claude users to enter through one Barndoor-controlled MCP endpoint. The governance model lives in Barndoor, so Claude stays simple while Barndoor handles server access, policy enforcement, and auditability.

​
Step 1: Prepare Barndoor First

Before touching Claude, confirm the Barndoor side is ready. If these pieces are not in place first, Claude users may connect successfully but see the wrong tools or fail policy checks later. References:

​
Step 2: Copy the Barndoor ToolIQ URL

Go to your Barndoor AI Client Setup page and copy the ToolIQ MCP endpoint for your organization. This will be the single connector URL you want Claude Enterprise to expose to users.
Do not create one Claude connector per downstream system unless you have a special exception. The point of this pattern is to centralize Claude access behind one Barndoor-controlled MCP.

​
Step 3: Add the Connector in Claude Enterprise

In Claude Enterprise, the organization owner adds the connector once for the whole organization.
1

Open Claude Organization Settings

In Claude, go to Organization Settings > Connectors.
2

Add Custom Connector

Click Add custom connector.
3

Add Custom Connector Name

Suggestion: Barndoor
4

Enter the Barndoor ToolIQ URL

Paste your Barndoor MCP URL, for example:
https://your-org.platform.barndoor.ai/mcp
You won’t need to configure any Claude side OAuth Credentials, only the Barndoor URL is required.
5

Save the Connector

Save the connector so it becomes available to your Claude organization.
At this point, Claude has one approved enterprise connector, and that connector points to Barndoor rather than directly to a single downstream MCP server.

​
Step 4: Expose the Connector to Claude Org Users

After the owner adds the connector, Claude users can connect to it individually.
1

Have Users Open Claude Settings

Users go to Settings > Connectors in Claude.
2

Locate the Organization Connector

Users find the Barndoor connector that was added by the Claude Enterprise admin. It will appear under the organization connectors section, distinct from any personal or directory connectors.
3

Connect and Authenticate

Users click Connect and complete the authentication flow to Barndoor.
4

Begin Using Claude with Barndoor

Users start a new Claude conversation with the approved Barndoor connector enabled.
Users are connecting to one Claude-approved Barndoor entry point. They are not managing separate Salesforce, Slack, Notion, Snowflake, etc. connectors inside Claude.

​
Step 5: Control Access in Barndoor, Not in Claude

This is the key operational model. Claude should expose one enterprise-approved connector. Barndoor should decide:
  • which MCP servers the user can reach
  • which tool calls are available
  • which policies allow or deny actions
  • how identity, groups, and roles affect runtime access
That means your rollout team should use Barndoor for governance changes and it removes Claude connector sprawl. Examples:
  • Allow Claude users to access Slack and Notion, but not Salesforce
  • Allow read-only Snowflake queries while blocking destructive SQL
  • Restrict outbound Gmail actions to corporate domains only
  • Deny sensitive Slack or CRM actions for certain user groups

​
Step 6: Validate the Runtime Experience

Before broad rollout, test the connector with pilot users. The pilot users should have the “User” role in Claude. References:

​
Step 7: Roll Out Safely Across the Claude Org

Once pilot validation is complete:
  • Roll the connector out to the rest of the Claude organization
  • Keep the connector URL stable
  • Add or remove MCP server access in Barndoor as needed
  • Update policies in Barndoor without retraining users on connector setup
  • Use Barndoor logs and policy summary views to monitor adoption and enforcement
This gives you a clean enterprise model: one Claude connector, one Barndoor ToolIQ URL, many governed downstream systems.

​
Preventing Employees from Bypassing Barndoor

Adding the Barndoor connector at the org level is the right foundation, but it does not automatically prevent users from adding their own custom MCP connectors that bypass Barndoor entirely. By default, Claude Enterprise users can navigate to Customize > Connectors in their personal settings and add any custom MCP server URL directly — including raw endpoints for Salesforce, Slack, Snowflake, or other systems — which would skip Barndoor’s policy enforcement and audit logging. Use the following controls to close this gap before rolling out to your organization. The most reliable way to ensure all MCP traffic routes through Barndoor is to enforce it at the network layer.
  • Allowlist only your Barndoor production URL at the corporate firewall or proxy
  • Block outbound connections to known MCP endpoints for systems like Salesforce, Slack, Snowflake, and others that are governed by Barndoor
  • This ensures that even if a user adds a direct connector in Claude, the connection will fail at the network boundary
This approach does not require changes inside Claude and applies uniformly across Claude.ai, Claude Desktop, and Claude Code.

​
Option 2: Claude Desktop Managed Configuration

If your organization uses Claude Desktop, you can deploy a managed MCP configuration that takes exclusive control of all MCP server connections on the machine. Create and deploy a managed-mcp.json file that defines only the Barndoor URL: 
{
  "mcpServers": {
    "barndoor": {
      "type": "http",
      "url": "https://your-org.platform.barndoor.ai/mcp",
      "description": "All MCP access through Barndoor"
    }
  }
}
When this file is deployed, users cannot add, modify, or remove MCP servers through Claude Desktop. Only the servers defined in the managed config are available.
The managed MCP configuration applies to Claude Desktop only. It does not control connectors added through the Claude.ai web interface or mobile apps. Pair this with network controls for full coverage.

​
Option 3: Acceptable Use Policy

For organizations that cannot enforce controls at the network or desktop level, pair your rollout with a clear acceptable use policy that:
  • Requires all Claude MCP connections to route through the approved Barndoor URL
  • Prohibits adding custom MCP connectors that connect directly to governed systems
  • Uses Barndoor enforcement logs to detect unexpected tool usage patterns
Current Limitation: Claude Enterprise does not currently provide a native admin toggle to block users from adding their own custom connector URLs entirely. Network-level enforcement or Claude Desktop managed configuration are the recommended controls until a Claude-native restriction is available.

​
Summary: Layered Defense

For a complete lockdown, combine all three approaches:
LayerControlCoverage
NetworkFirewall allowlist for Barndoor URL onlyClaude.ai, Desktop, Code, Mobile
Desktopmanaged-mcp.json deploymentClaude Desktop only
PolicyAcceptable use policy + Barndoor audit logsAll surfaces

​
Operational Best Practices

  • Use one Claude Enterprise connector per Barndoor environment, not per downstream app
  • Keep production users on the production Barndoor URL only
  • Test policy changes in DRAFT before activating them
  • Use Barndoor policies to control access instead of relying on user behavior inside Claude
  • Keep the Claude connector rollout narrow at first, then expand by user group or team
  • Use Barndoor enforcement logs to investigate denied or unexpected actions

​
Troubleshooting

Check Barndoor first. The most common causes are:
  • the wrong MCP servers are connected
  • policies are still in DRAFT
  • the user or agent is out of scope for the active policy
  • the allowed tools were not enabled in the policy model
Review the active Barndoor policies and enforcement logs. Confirm whether the denial is expected and which policy caused it.
Keep the single connector model and separate access in Barndoor through server selection, user identity, group mapping, and policies. Do not solve this by creating many duplicate Claude connectors unless you have a strict org-level reason.
You can keep the same Claude connector and expand the governed systems behind it in Barndoor, as long as you update server connectivity and policies before rollout.

​
Next Steps