MCP Servers

Model Context Protocol (MCP) servers let an agent access external tools and data sources beyond its default tool set.

There are two MCP directions:

• MCP servers connected to an agent: external tools that an agent can use.
• Remote MCP: The platform's own MCP endpoint for external AI clients. Developers should see Remote MCP.

This page covers MCP servers connected to agents.

Where to manage MCP servers

Manage MCP servers in the platform:

• hosted deployment: https://your-deployment.example/app/integrations

From there you can add a server, configure auth, test it, and assign it to agents.

Server scopes

MCP servers are scoped so access can be managed:

• Platform: active operator-managed servers can be inherited by eligible agents; users do not assign them manually.
• Organization: shared within one Organization.
• Team: limited to agents in the selected Team.
• Personal / My workspace: owned by a user and limited to the matching personal or Organization-private workspace.

The exact scopes available depend on your role and deployment. Ordinary workspace servers require explicit agent assignments. Product-managed integrations can instead be inherited within their workspace, with availability still subject to active configuration, credentials, and runtime policy.

Connection types

Depending on deployment, MCP servers can use:

• Remote server URL for hosted MCP services.
• Local command for ordinary workspace servers where the agent's sandbox execution path is enabled. Those commands run inside the agent sandbox; operator-managed platform commands have a separate trusted-runtime policy.

Remote URLs require public HTTPS and cannot redirect to another endpoint. Private networks, loopback and metadata services are blocked. A deployment operator can explicitly enable exact origins for local development; personal server metadata cannot enable this exception. Use the final server URL, including its correct path.

Authentication

MCP server auth can involve headers, environment-style configuration, or OAuth depending on the server.

If OAuth is required:

1. Create or edit the MCP server.
2. Save it.
3. Start the OAuth connection.
4. Complete the provider flow.
5. Confirm the server shows as connected.

OAuth endpoints are discovered and verified by the platform. Authorization and token services may use different public HTTPS hosts when advertised by the provider. Custom metadata paths/headers and callback endpoint overrides are not supported. If the server URL changes, reconnect to authorize the new destination. Connections created before endpoint binding also require reconnection; OAuth cannot use a local-development network exception.

Use secrets and environment variable names for sensitive values. Do not paste credentials into chat.

Assign a server to an agent

You can usually assign MCP servers from either:

• The agent's settings or integrations view.
• The MCP server management page.

These assignment controls apply to ordinary workspace servers. Platform servers and product-managed inherited integrations do not use manual assignment. Enable only the editable servers the agent needs, and use the integration's own setup or disable controls for managed connections.

Troubleshooting

• OAuth connection required: complete or refresh the OAuth flow.
• Destination policy or setup error: confirm a public HTTPS destination with public DNS answers and no redirects. Reconfigure an unsafe saved URL, then reconnect OAuth. Repeated authentication attempts cannot repair a destination-policy rejection.
• Tool missing: confirm the server is assigned to the agent and available in the current context.
• Auth error: verify configured headers, secrets, or OAuth status without exposing secret values.
• Unexpected behavior: narrow the agent's charter or disable broad tools.
• Local command issue: confirm sandbox availability, the command and dependencies inside the sandbox, and the server's authentication. A command installed only on the host does not establish sandbox readiness.