Configure MCP servers in OneOrg.
OneOrg lets admins add MCP servers as governed tool sources, then control which roles and users can connect to those servers and use their tools.
Configure governed tool access
Admins configure MCP servers from the organization settings area. A server configuration includes a name, connection URL, transport choice, optional headers, and OAuth settings when the server requires authorization. The UI treats the server as an organization resource rather than a personal shortcut.
After a server is configured, users with access can connect it and make its tools available inside OneOrg workflows that support tools. This is how a team exposes approved external capabilities to agents without giving every user a separate setup path.
Access control is part of the configuration. Owners and admins can manage MCP servers broadly. Custom roles can be limited to specific servers or even specific tools on a server. That makes MCP useful for governed tool access rather than unrestricted tool exposure.
The practical flow is: add the server, configure authentication, test or connect it, then use roles to decide who can see and use it.
For users, the visible result is a controlled set of tools available where OneOrg supports tool use. For admins, the important configuration is the boundary around those tools.
Configure MCP servers like governed toolboxes, not open-ended shortcuts. Start with the smallest server scope that gives users the capability they need. Name the server for the business capability it exposes, then restrict access by role before broad rollout. If a server exposes many tools, decide which tools belong to which roles instead of assuming every authorized user needs everything. Test with a low-risk workflow first. If users do not understand what a tool is allowed to do, document that boundary in the related project instructions or skill before letting agents use it repeatedly.
Before rollout
Use MCP servers when your organization wants OneOrg agents or workflows to access external tools through a standard tool interface. They are a good fit for approved internal tools, developer tools, data tools, and third-party MCP-compatible systems.
Do not expose sensitive or broad-access servers to default member roles. Start narrow, assign access intentionally, and expand only when the tool is safe for a wider group. If the external system is a normal business integration rather than an MCP tool source, use the integrations flow instead.