Building automations with Barndoor MCP servers

Setting up tools covers pointing a connection straight at a vendor's MCP server. This guide covers the other pattern: routing those connections through Barndoor, a governed MCP gateway, so credentials and per-agent access policy live outside your blueprints.

The end state is a tools profile whose MCP servers all resolve through Barndoor's gateway — Salesforce, Snowflake, Calendar — with no raw vendor credentials stored in Diaphora at all.

Who owns what

The two systems govern different halves of a run, and it's worth being precise about the split before you wire anything up:

Diaphora's tools profile stops holding vendor credentials and starts holding gateway URLs. Access decisions move to Barndoor's Access Control Center, where they're enforced identically for every agent that shares the connector.

Prerequisites

• A Diaphora account with access to a tools profile you can edit.
• A Barndoor tenant with admin access to MCP Servers and the Access Control Center.
• The downstream tools (Salesforce, Snowflake, Google Calendar, and so on) already connected in Barndoor. Barndoor's own AI Agent → Connections tab lists which are live.

Register Diaphora as an MCP server in Barndoor

In Barndoor, open MCP Servers from the left nav — the org-wide inventory of every server Barndoor proxies, with monitored actions, connected agents, and user counts per server.

Click Add MCP Server and search the catalog for Diaphora. It appears as an Official connector: search, inspect, and run Diaphora plans and workflow agents via AI tools. Click Add New on the Diaphora card.

This is the direction most people don't expect on the first read: it lets agents governed by Barndoor call your blueprints as tools. The tools profile work further down is the opposite direction — your blueprints calling governed servers.

Connect the OAuth client

Barndoor authenticates to Diaphora with an OAuth client that lives in Diaphora.

In Diaphora, open the user menu in the bottom-left corner and select OAuth clients. You'll see the client Barndoor will use, along with its Client ID. Click the edit (pencil) icon to open Edit client, and under Redirect URIs confirm Barndoor's callback is present:

Without that exact URI the OAuth handshake fails at the last step, after the consent screen — which reads like a Barndoor problem but isn't. Save any changes.

Scope an access policy

Adding the connector makes it reachable; a policy decides who may reach it.

In Barndoor, go to Access Control Center and filter policies by the new MCP server. The Diaphora connector is labeled Blueprint internally, so filter on that. Confirm a policy exists scoping the connector to the agents that should have it — for example, Claude and Claude Code.

Point your tools profile at the gateway

Now the other direction: the servers your blueprints call.

In Diaphora, open your tools profile (for example, Default) and go to Details. The MCP Servers section lists every external server this profile can reach. Point each one at its Barndoor gateway URL rather than the vendor's:

To add another, click + Add MCP server in the sidebar and fill in:

• Name — how blueprints will refer to this server. Match it exactly when you write require mcp.
• URL — the Barndoor gateway endpoint for that tool.
• Headers — any custom key/value headers the endpoint requires.
• Authentication method — one of None, Bearer, OAuth challenge, Client credentials, or Passthrough.

Barndoor-routed connectors use OAuth challenge, which appears as challenge in the servers table. That's the setting that hands the credential exchange to Barndoor instead of storing a token in Diaphora.

Verify the authorizations

Open Authorizations in the tools profile sidebar. Diaphora runs a requirements checklist against every configured MCP server.

Every row should resolve to auth method cached, status ready — meaning Barndoor has already granted and cached the credentials and no manual login is needed at run time. A row that doesn't reach ready will fail the blueprint at its first tool call, so resolve it here rather than debugging it from a run log.

Use the governed servers in a blueprint

Nothing about writing the blueprint changes — that's the point. Declare the server by the name it carries in the tools profile:

require mcp RaynaWorks_Snowflake

session("pipeline_risk") {
    use mcp RaynaWorks_Snowflake

    # Barndoor authorizes this call and records it against the policy
    call("query") -> deals {
        sql = "select id, stage, amount, close_date from deals where is_closed = false"
    }

    + Review the open pipeline: {{ .vars.deals | json }}

    - Identify the deals most at risk of slipping, and why.

    schema {
        atRisk: string[] # One line per deal, with the reason
    }
}

The blueprint declares what it needs. Barndoor decides whether this caller may have it, and holds the credential that makes it possible. Neither concern leaks into the FML.

Next steps

• Write the blueprint that consumes these tools: Connect Frags to your data.
• Configure a non-gateway connection for comparison: Setting up tools.
• Run the finished automation on a cadence: Schedule recurring blueprints.