Skip to main content
Connected systems give a support workflow the ability to read a request, investigate live state, carry out an approved action, and send the customer a response. Connectors expose the API operations used by cloud workers and the operator workspace. MCP servers extend supported interactive tools and dashboards; an MCP tool available in Copilot is not automatically available to a worker.
  • A connector defines named REST or SOAP endpoints and their request shape.
  • An MCP server publishes a tool catalog over Streamable HTTP or SSE.
Definitions, credentials, and tool availability are separate concerns. A shared definition does not require a shared secret, and an enabled tool cannot run until the effective credential is ready.

​
Connect the support loop

Define the operations needed to finish a case, including the customer response: For a cloud worker, use an enabled organization connector in service mode and configure the agent’s credential or OAuth account under Setup → Connections. Grant the required endpoints through organization, channel, and stage policy. Worker requests use permitted public HTTPS endpoints; private-network targets and personal per-member connector credentials are not available through this path. Worker connector writes require an independent authorized manager to approve the exact request. This includes customer replies, emails, infrastructure changes, and ticket closure. Changing the proposed request requires fresh approval. Test both reads and approved writes against the intended tenant before enabling unattended intake. See AI support agents and Run the full support loop. Give the agent a connection for each system it needs. The same workflow can investigate in one system, make an approved change in another, and return the result through the help desk. Every external write in this diagram keeps its own exact-request approval. A help-desk reply can already deliver customer email; add a separate mail connection only when your workflow needs it.

​
Choose connector or MCP

​
Personal and organization integrations

Create a personal integration for private experimentation. Use the organization catalog when a definition, description, and policy should be centrally maintained. For an organization definition, choose a credential mode: Use per-member credentials for user-level authorization and accountability. Use shared credentials only for an intentional service identity with a documented owner, rotation path, and external audit trail.

​
Create a connector

1

Define the system

Add a clear name, description, base URL, and visibility. Name the tenant or environment when confusion would be dangerous.
2

Choose authentication

Link a Key Chain entry or complete OAuth. Avoid inline legacy secret fields.
3

Add named endpoints

Define method, path, inputs, body, response, and side effects for each callable operation.
4

Test read-only first

Verify authentication, tenant, pagination, error shape, and rate limits with a safe endpoint.
5

Enable writes deliberately

Add mutation endpoints only after the approval view clearly identifies the target and payload.

​
Connector authentication

Studio supports none, basic, bearer, API key, OAuth 2 client credentials, OAuth 2 password, OAuth 2 authorization code, digest, AWS Signature Version 4, and custom header templates. Authorization-code flows can use OIDC discovery and public-client PKCE where supported. When an OAuth refresh fails, Studio keeps a visible re-authorization state rather than silently retrying forever. Store values in Key Chain. Custom header templates may reference named Key Chain values, but the template and endpoint description must not print the resolved secret.

​
Endpoint quality

​
Add an MCP server

Provide a name, server URL, transport, authentication, and visibility. Studio supports browser-compatible HTTP and SSE transports, not local stdio servers. MCP authentication supports none, API key, bearer, OAuth 2 client credentials, OAuth 2 authorization code, and MCP-standard automatic OAuth discovery. For automatic OAuth, Studio follows the server’s discovery and registration flow. Studio discovers the tool catalog after connection. An organization server can publish that catalog to the administration console, where an admin can disable the server or individual tools.

​
MCP Directory

Open the MCP Directory from the Connectors surface to search the curated catalog and install a definition. Review the source, requested server URL, authentication, and tool descriptions before connecting. A catalog listing is not a security guarantee.

​
Connect your account

When organization policy allows a per-member integration but your private credential is missing, Settings → Profile shows it in the connect-your-accounts checklist. Use the offered OAuth or Key Chain action. Admins can see readiness status, not the secret. Do not send a token to an admin in chat as a workaround.

​
Effective tool policy

An integration must pass every layer:
  1. Organization availability and per-tool policy.
  2. Member access and optional preload.
  3. Active channel policy.
  4. Worker-stage policy, for a digital worker.
  5. Credential readiness.
Studio enforces the result at discovery and dispatch. If an old conversation references a now-disabled MCP tool, runtime dispatch still rejects it.

​
Approvals and external effects

Read-only and write endpoints should be separate tools. An approval must identify the external system, tenant, target object, and proposed payload. Keep browser or Copilot Autopilot off while validating a new integration. For dashboards, choose read-only endpoints and sustainable refresh intervals. A dashboard can multiply traffic if several panels poll similar calls, even though Studio reuses compatible fetches where possible.

​
Troubleshooting

Organization administration

Maintain organization definitions, credential modes, tool catalogs, and member readiness.

Dashboards and generated apps

Build resilient views from connectors and review app capabilities.