What Is the OpenAI Connector Registry, and Should You Use It?

Updated June 2026. Rewritten to reflect the December 2025 rename of connectors to apps, the MCP-based connector model, and the admin governance controls teams actually ask us about.

The OpenAI Connector Registry is the admin control plane that decides which data sources ChatGPT and the API are allowed to reach inside your organisation. It is not a feature most people click on every day. It is the thing that quietly determines whether a marketing hire can pull from your SharePoint inside ChatGPT, or whether your support team can wire a custom internal tool into an assistant without a security review every single time.

We are Osher Digital, a Brisbane AI consultancy that builds production assistants and agents on both OpenAI and Anthropic models. We have set up connector governance for clients in healthcare, recruitment and finance, and we have also untangled the mess that happens when nobody owns it. This guide covers what the connector registry is, how it sits on top of the Model Context Protocol, how to enable a connector safely, and the cases where you should not bother with it at all.

One naming note before anything else. In December 2025 OpenAI renamed connectors to apps in the ChatGPT interface. The underlying plumbing, the registry concept, and the API behaviour did not change, so you will still see “connector” everywhere in docs, settings and the API. We use both terms here because your screen probably does too.

What the OpenAI Connector Registry Actually Is

Strip away the branding and the OpenAI Connector Registry is a catalogue of approved data-source connections plus the rules for who can use them. A connector is OpenAI’s maintained wrapper around a third-party service: Google Workspace, Microsoft SharePoint, Dropbox, GitHub, and a growing list of others. The registry is where a workspace owner sees every available connector, turns specific ones on, and assigns who gets access.

The important design choice: every connector is off by default. Nothing reaches your Google Drive until an admin in a Business, Enterprise or Edu workspace deliberately enables it. That default-deny posture is the whole point. Without a registry, connector access tends to sprawl, with individual users each authorising their own data sources and no central record of what is connected to what.

So when people search for “connector registry” or “openai connector registry”, they are usually after one of two things: how to switch a data source on, or how to stop one from being switched on. Both live in the same place.

Connectors, Apps and MCP: the Same Thing Wearing Three Hats

This is where people get confused, so here is the plain version. A connector (now shown as an app in ChatGPT) is built on the Model Context Protocol, the open standard for letting a model call external tools and fetch data. Anthropic introduced MCP and OpenAI adopted it, which is why the same protocol shows up across both ecosystems. A connector is really just an MCP server that OpenAI hosts and maintains for you, so you do not have to run it yourself.

If you have read our walkthrough of OpenAI AgentKit or our guide to building agents with Claude, the tool-calling idea is identical. The registry just adds an organisation-wide governance layer on top: which MCP-backed connectors exist, who approved them, and who can call them.

How the OpenAI Connector Registry Uses MCP in the API

The registry is mostly an admin surface, but it has a direct counterpart in the API, and that is where it matters for anyone building on the platform. When you call a model through the API and want it to reach a registered connector, you do not pass a raw MCP server URL. You pass a connector_id that refers to the connector OpenAI already hosts and your org already approved.

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-4.1",
    input="Summarise the three most recent contracts in our Drive folder.",
    tools=[
        {
            "type": "mcp",
            # A registry connector OpenAI hosts, rather than a raw server_url
            "connector_id": "connector_googledrive",
            "authorization": "{OAUTH_ACCESS_TOKEN}",
            "require_approval": "always",
        }
    ],
)

print(response.output_text)

Two details earn their keep here. The connector_id means you inherit the connector OpenAI maintains, including auth handling and updates, instead of standing up and patching your own MCP server. And require_approval set to always forces a human confirmation step before the tool runs, which you want on anything that reads or writes real business data while you are still building trust in the system.

If you need something the hosted connectors do not cover, you point a tool at your own remote MCP server with a server_url instead. The registry handles the common services; custom MCP covers the rest. That split is the single most useful thing to understand about the whole model.

How to Enable a Connector in the Registry

For a Business, Enterprise or Edu workspace, the enable path is short. The reviewing takes longer than the clicking, which is the correct ratio.

1. Open Workspace Settings as an owner, then go to the Apps (formerly Connectors) section.
2. Find the connector you want, for example Google Drive or SharePoint, and review the scopes it requests before enabling.
3. Enable it for the whole workspace or scope it to specific roles using RBAC, so finance does not inherit the engineering GitHub connector by accident.
4. For custom internal tools, turn on developer mode under Permissions & Roles, then build and register a custom MCP connector.
5. Document who approved it and why. The registry records the state; it does not record the reasoning, and the reasoning is what an auditor asks for.

That last step is the one teams skip and later regret. We keep a short approvals log next to the registry for every client, because “who said the CRM connector could be on, and when” is a question that always arrives eventually.

Admin Controls, RBAC and Why Default-Deny Matters

The governance features are the reason the registry exists rather than a free-for-all of personal authorisations. Workspace owners decide which connectors are enabled at all. Role-based access control then narrows that down to who can actually use each one. Custom MCP apps need developer mode switched on first, and that switch sits behind the owner role specifically so a curious individual contributor cannot wire an unreviewed server into the workspace.

For a regulated client, this is where most of the real work happens. A connector that can read a shared drive can read everything a user in that role can read, which is frequently more than anyone intended. We scope connectors to the narrowest role that still does the job, and we review the list quarterly. Access that made sense in March is often dead weight by September.

If you want a mid-build sanity check on connector scopes before you roll something out to a whole department, book a call and we will walk through it with you.

Building a Custom Connector with MCP

The hosted connectors cover the obvious services. The interesting work, and most of what we get hired for, is the internal system that has no off-the-shelf connector: a bespoke booking platform, a legacy claims database, an in-house pricing engine. For those you build an MCP server that exposes a handful of well-described tools, then register it through developer mode.

The single biggest factor in whether a custom connector works well is tool description quality. A vague description like “get data” produces a model that calls the wrong tool at the wrong time. A precise one, naming exactly what the tool returns and when to use it, lifts tool-selection accuracy sharply. We have measured the difference at well above ten percentage points on real internal tools, which is the gap between a connector people trust and one they quietly stop using.

Keep the tool surface small. Five sharp tools beat fifteen fuzzy ones. If you are starting from scratch, our notes on building an agent on OpenAI cover the tool-design patterns that carry straight over to custom connectors.

What the Connector Registry Costs

The registry itself is part of the workspace plans rather than a separate line item. The cost that actually moves is downstream: enabling connectors increases how much data the model reads, and tokens are billed per use. A connector pulling whole documents into context on every request is the quiet way an API bill triples.

As a rough planning figure for an Australian team, ChatGPT Business sits around $42 AUD per user per month, and a moderate internal assistant calling registry connectors a few thousand times a month typically lands in the $150 to $600 AUD range in API usage on top. The variable that dominates is how much each connector returns per call, not how many connectors you have enabled. Trim tool results to the fields you need and the bill behaves.

When the OpenAI Connector Registry Is Not the Right Tool

Honest answer: plenty of the time. The registry shines when non-technical staff need governed access to common data sources inside ChatGPT. It is the wrong reach in a few clear cases.

• You are shipping a product feature. If you are building an assistant into your own software, you want direct MCP servers and your own auth, not ChatGPT workspace connectors. The registry is an internal-workspace tool.
• Strict data residency. Connector traffic flows through OpenAI’s infrastructure. If your data cannot leave Australia, a hosted connector is the wrong door. We build hybrid setups where sensitive data is handled locally and only de-identified context reaches the API.
• One person, one workflow. If a single analyst wants to query one system, a small script or a direct MCP connection is less overhead than standing up workspace governance.
• Heavy write operations. Connectors are strongest for reading and retrieval. For agents that take consequential write actions across systems, we tend to build a dedicated agent with explicit guardrails rather than lean on workspace connectors.

If you are mostly reading data into ChatGPT for a team, the registry is the right tool. If you are building software, look at custom agent development instead.

Frequently Asked Questions

What is the OpenAI connector registry?

It is the admin catalogue where a workspace owner sees, enables and governs the data-source connectors that ChatGPT and the API can use. Each connector is an OpenAI-hosted MCP wrapper around a service like Google Drive or SharePoint, and every one is off until an admin turns it on.

How does the AI app connect to my data? Do I need pipelines?

No data pipeline is required for the hosted connectors. The connector handles authentication and retrieval through MCP, so when you enable, say, the Google Drive connector and authorise it, the model can fetch from your Drive directly at request time. You only build pipelines if you are wiring up a custom internal system through your own MCP server.

Where are the connector registry settings in OpenAI?

In a Business, Enterprise or Edu workspace, open Workspace Settings and go to the Apps section, which was previously labelled Connectors. Custom MCP connectors live behind developer mode under Permissions and Roles, and only workspace owners can enable that.

Can I connect my Gmail or Google Drive to ChatGPT?

Yes, through the Google connectors, provided your workspace admin has enabled them. On personal plans you authorise the connection yourself; on workspace plans an owner enables the connector first and may scope it to certain roles. Access is always tied to what your own account can already see.

What is the difference between a registry connector and a raw MCP server?

A registry connector is an MCP server OpenAI hosts and maintains for a common service; in the API you reference it with a connector_id. A raw MCP server is one you run yourself for a custom or internal system, referenced with a server_url. Use the registry for common services and a custom server for everything it does not cover.

How many OpenAI surfaces use connectors?

Connectors show up in two main places: inside ChatGPT (now under the Apps label) for everyday use by staff, and in the API through the connector_id parameter for anything you build. Both draw on the same MCP foundation, so a connector approved for the workspace behaves consistently across them.

Is the connector registry safe for Australian business data?

It can be, with care. Connector traffic is processed on OpenAI’s infrastructure outside Australia, so for health, financial or government data you need to weigh the Privacy Act and the Australian Privacy Principles. We commonly scope connectors tightly, keep sensitive records on local infrastructure, and pass only de-identified context to the API. The registry’s default-deny and RBAC controls help, but they do not remove the data-residency question.

How much does it cost to run connectors in production?

The registry comes with the workspace plan; the real cost is token usage from the data connectors pull in. A moderate internal assistant usually runs $150 to $600 AUD per month in API fees on top of per-seat pricing, and the biggest lever is how much each connector returns per call. Trim results to the fields you need and costs stay predictable.

The connector registry is a governance tool, not a magic wand. Get the scoping and the approvals log right and it quietly does its job for years. Get them wrong and it becomes the thing nobody can explain during a security review. If you want a second pair of eyes on your connector setup, or you are weighing the registry against building a custom agent, get in touch with our team.