As of June 15, 2026, the practical question for a small team is not only whether ChatGPT can search shared documents. It is whether company knowledge should also pull from a custom connector that reaches into an internal system.

OpenAI's ChatGPT Business release notes say company knowledge now supports custom MCP connectors with search and fetch functionality when those connectors are enabled for the organization. OpenAI's company knowledge help page also says company knowledge can use custom apps built with MCP to leverage company-specific data, with search/fetch functionality only.

That is useful when the important answer is not in Google Drive or SharePoint. It may live in a support system, customer portal, product database, project tracker, pricing catalog, policy store or internal operations app.

It also raises a different rollout question. A custom MCP connector can make proprietary data feel as searchable as a handbook. Before that happens, run an acceptance test that checks source quality, permissions, citations and fallback behavior.

Start with one answer job

Do not begin with "connect our internal system." Begin with one answer job that already costs time.

Good first jobs are narrow:

  • "Which support policy applies to this plan?"
  • "What is the current implementation status for this customer?"
  • "Which product limits are active for this SKU?"
  • "Which internal process owns this approval?"
  • "What changed in the last release note for this account?"

Weak first jobs are broad:

  • "Answer questions about customers."
  • "Search the whole product database."
  • "Summarize everything about a project."
  • "Tell the team what to do."

The acceptance test should name five to ten real questions, the expected source records and the person who can judge whether the answer is correct. If nobody can name the expected source, the connector is not ready for broad company knowledge use.

Separate search from action

OpenAI describes company knowledge support for custom MCP connectors in search/fetch terms. That distinction matters. The connector used for company knowledge should help ChatGPT find and cite relevant context. It should not quietly turn a lookup pilot into a workflow that changes tickets, updates accounts or triggers approvals.

OpenAI's apps in ChatGPT help page says custom apps can be built with MCP to let ChatGPT call approved tools and retrieve information from services. It also notes that workspace admins can control whether custom apps are allowed and how they are rolled out.

For the first company knowledge pilot, keep the job read-oriented:

  • search a controlled set of records;
  • fetch a specific record when needed;
  • return a citation or source link;
  • explain what source was used;
  • say when the source does not answer the question.

If the same MCP app also has write actions, test those separately. Do not let "company knowledge is useful" become the reason to enable actions before the team has reviewed them.

Pick a source system that is clean enough

Company knowledge does not fix a weak source system. If the internal system has duplicate records, stale status fields, old plan names or inconsistent permissions, the connector may simply make those problems easier to ask about.

Before enabling a custom connector for users, check:

  • Which object types are exposed?
  • Which fields are returned in search results?
  • Which fields are fetched only after a specific result is selected?
  • Are draft, archived or deleted records excluded?
  • Are timestamps and owners visible enough for review?
  • Can the answer show where the information came from?

Small teams often have one system that everyone treats as truth and another system that is only a working board. Do not connect both at once. Start with the system that has the clearest ownership and the least ambiguous record state.

Test permissions with real roles

OpenAI's company knowledge documentation says ChatGPT respects existing permissions and can only access what each user is allowed to view. That is necessary, but it is not the whole acceptance test.

Run the same questions with at least three user types:

  • a workspace admin or owner;
  • a normal user who should see the source;
  • a user who should not see the source.

For each question, check whether the connector returns the right result, refuses the right result or avoids leaking details from a record the user should not know exists. A safe answer for the wrong user might say it cannot find relevant information, not that a restricted customer record exists.

If the connector depends on OAuth, test what happens when a user has not connected the app. If the answer falls back to older general context without saying so, the team may think company knowledge is more complete than it is.

Require citations before usefulness

The first success metric should not be "people liked the answer." It should be "people could verify the answer."

For each test question, record:

  • the answer ChatGPT gave;
  • the cited record or source link;
  • whether the cited source actually supports the answer;
  • whether the answer used the newest source;
  • whether missing context was made visible;
  • what the user should do if the source is incomplete.

This is where many pilots become safer. A custom connector can answer quickly, but a small team needs to know when it is reading the correct source, when it is guessing from partial context and when the source system itself needs cleanup.

Do not approve the connector because the answer sounds fluent. Approve it when the evidence path is boring enough to check.

Decide who owns connector drift

A custom connector is not a static document. The internal system can change fields, permissions, statuses, schemas and business meanings. The MCP app can also change.

OpenAI's developer mode and MCP apps help page describes building, testing and deploying MCP-powered apps. That means the team should treat the connector as maintained software, not as a one-time setting.

Name an owner for:

  • source system changes;
  • connector updates;
  • permission reviews;
  • failed or stale-answer reports;
  • user access requests;
  • the next acceptance-test run.

Then set a review date. A good first pilot may run for two weeks with a limited user group and a short log of failed questions. If the team cannot maintain that log, it probably is not ready to maintain a custom connector that affects daily decisions.

Keep admin controls part of the launch

OpenAI's admin controls page for apps says Business workspace admins can control which apps are enabled and manage role-scoped app permissions. It also describes role-based controls for Enterprise and Edu workspaces.

Use those controls deliberately:

  • keep the first connector audience small;
  • restrict access by role where available;
  • document which users can connect it;
  • disable broad availability until citations pass;
  • review whether the connector appears in the expected app settings;
  • keep a rollback path if answer quality is poor.

For small teams, the main risk is not only a security incident. It is operational trust moving too fast. Once people see ChatGPT answer from an internal system, they may stop opening the system itself. That is only acceptable when the answer path has been tested.

The acceptance-test decision

Use a custom MCP connector in company knowledge when the team has a narrow answer job, a clean enough source, role-based permission behavior, reliable citations and a named owner.

Wait when the source system is messy, permissions are unclear, citations are weak or the real request is to automate actions rather than answer questions.

The useful first rollout is not "ChatGPT can search our custom system." It is "ChatGPT can answer these five internal questions from this source, for these users, with evidence we can check."