Supported data-source types

Myra AI Workspace connects your models and agents to external data sources through MCP connectors (Model Context Protocol). A connector is a governed bridge to a remote MCP server: the gateway proxies tool calls, applies your per-tool allow/deny policy, and — for OAuth connectors — holds each user's credential server-side. A data source is registered once as a connector; the AI then discovers the tools that source exposes and calls them when a task needs live data.

Connectors are added from a curated connector directory (verified endpoints that pre-fill the server URL and the recommended authentication) or by entering any MCP server URL by hand. See MCP connectors for the step-by-step setup, and My MCP connectors for the per-user variant.

Connector directory

Data source	What the AI can do	Authentication
Microsoft SharePoint	Search your tenant's SharePoint sites, document libraries and lists; get file / list-item metadata; manage lists.	Microsoft Entra OAuth (tenant-scoped)
Microsoft OneDrive	List files and folders in your tenant's OneDrive; get file metadata.	Microsoft Entra OAuth (tenant-scoped)
Confluence	Search (CQL), read, summarize, and create or update pages in your team's spaces.	OAuth 2.1 or Atlassian API token
Atlassian (Jira + Confluence + Jira Service Management + Bitbucket + Compass)	Work across the whole Atlassian suite through one endpoint.	OAuth 2.1 or Atlassian API token
GitHub	Read repositories, issues, and pull requests.	OAuth 2.1
Notion	Search and read Notion pages and databases.	OAuth 2.1
Linear	Query and update Linear issues.	OAuth 2.1
Sentry	Inspect Sentry issues and events.	OAuth 2.1
Slack	Read channels and summarize conversations.	OAuth 2.1
Gmail	Search, read and draft email in your Gmail mailbox.	Google OAuth 2.0
Google Drive	Search, browse and read files and folders in your Google Drive.	Google OAuth 2.0
Asana	Manage tasks and projects: search work, create and update tasks, and summarize project status.	OAuth 2.0
Salesforce	Query and read Salesforce records — standard and custom sObjects — through the Salesforce Hosted MCP server.	OAuth 2.0 (per-org External Client App)
DeepWiki, Microsoft Learn, Context7, GitMCP	Search public documentation and code references.	None (public)

Any MCP-compliant server not in the directory can still be added by hand with New connector.

Microsoft 365 (SharePoint & OneDrive)

For a Microsoft-shop organisation, the highest-value data sources are the Microsoft 365 workloads. The directory ships the official Microsoft remote MCP servers (Work IQ / Microsoft Agent 365) for SharePoint and OneDrive.

These are tenant-scoped: the MCP endpoint and the Microsoft Entra sign-in URLs embed your organisation's Entra Directory (tenant) ID. When you add the connector you enter that tenant ID once; the gateway validates it (a strict GUID check — a malformed or hostile value is rejected, never substituted) and completes the URLs server-side. Sign-in uses Microsoft Entra OAuth (per-user) through the gateway's MCP OAuth framework — you register an Entra enterprise application and supply its client ID/secret. Setup: see MCP connectors (shared) and the MCP API reference.

SharePoint sync (a knowledge-base data source, not a tool server). Alongside the live MCP servers, the directory ships a Microsoft Graph (SharePoint sync) card. This is a data source, not an MCP tool server: instead of the model querying SharePoint per turn, the connector-sync engine periodically pulls documents from a SharePoint document library (via the Microsoft Graph REST API) and ingests them into a knowledge base, so their content is searchable in chat. Sign-in is the same Microsoft Entra OAuth; the gateway pulls only the files the connected identity can read. See Connector sync for the sync contract and supported file types.

Confluence & Atlassian

Confluence is reached through the Atlassian Remote MCP Server (https://mcp.atlassian.com/v1/mcp), Atlassian's official hosted endpoint. Through it the AI can run CQL searches, read and summarize pages, and create or update pages, scoped to the spaces the connected account can access.

Confluence and the combined Atlassian suite are two directory entries for the one Atlassian Remote MCP endpoint — Confluence is surfaced by name so it is found in a search, while the Atlassian card exposes the full suite (Jira, Confluence, JSM, Bitbucket, Compass). Connecting either registers a single connection to that endpoint; the directory recognises an endpoint you have already added — by either card — and offers to configure the existing connector rather than create a duplicate, so one endpoint yields one connection (no repeated sign-in, no duplicated tools). If you genuinely need a second connection to the same endpoint — for example one with a personal OAuth login and another with a shared service-account token — create it with New connector.

Authentication

Two authentication methods work with the same endpoint:

OAuth 2.1 (recommended, interactive) — each user connects their own Atlassian account with a browser consent. The gateway self-registers with the Atlassian authorization server using Dynamic Client Registration, so no client ID or secret has to be pasted. This is the default for the Confluence and Atlassian directory cards. Tools then act with that user's Confluence permissions.
Atlassian API token / service account (headless) — for automation without an interactive login, an administrator creates a tenant-scoped connector using the Custom header authentication method and sets the header to Authorization: Basic <base64(email:api-token)>. The token is generated in the user's Atlassian account settings.

Both methods are handled by the same connection layer; only the credential differs.

Knowledge, code & documentation

Curated zero-config and OAuth connectors for developer and knowledge workflows — for example Microsoft Learn, DeepWiki, Context7, GitMCP (public repository docs), GitHub, Notion, Linear, Sentry, Slack, Gmail, Google Drive and Asana. No-auth entries are usable immediately; OAuth entries connect per user.

The Gmail and Google Drive entries reach Google's official Workspace remote MCP servers. Google does not support OAuth Dynamic Client Registration, so an administrator registers an OAuth 2.0 client in the Google Cloud console once and supplies its client ID, secret and authorize/token URLs when creating the connector (the same manual-OAuth path as Slack); each user then signs in with their own Google account and the tools act with that user's own permissions.

The Asana entry reaches Asana's official remote MCP server. Asana does not support OAuth Dynamic Client Registration, so an administrator registers an OAuth 2.0 app in the Asana developer console once and supplies its client ID, secret and authorize/token URLs when creating the connector (the same manual-OAuth path as Gmail and Slack); each user then signs in with their own Asana account and the tools act with that user's own permissions and workspace access.

Internal / custom systems

Any MCP-speaking service — an internal data warehouse, a line-of-business API, or a self-hosted connector — can be added by entering its server URL. Tenant administrators may target internal addresses (the intended data-warehouse case); member-created connectors are restricted to public endpoints.

Data residency and sovereignty

Connecting a data source routes data to that source's own service, and in every case the connection reaches your own tenant — reads and writes against content you already control, over the provider's own endpoints. Understand the posture before enabling one for regulated content:

Microsoft 365 — a SharePoint/OneDrive connector reaches your own Microsoft 365 tenant. Microsoft offers EU / EU Data Boundary (and, for eligible workloads, German) data residency for Microsoft 365; the residency of the content a connector touches is that of your tenant, configured in Microsoft 365 — the gateway does not relocate it.
Confluence / Atlassian — the connector works against your organisation's Atlassian Cloud site, not a Myra-hosted copy. Atlassian offers data residency, including EU regions; where your Confluence data lives at rest is governed by your Atlassian site's configuration, which you control in Atlassian. In transit, each tool call goes to Atlassian's hosted Remote MCP endpoint (https://mcp.atlassian.com/v1/mcp); at-rest residency does not by itself dictate where that request endpoint runs — if a specific transit region is required, confirm it against Atlassian's data-residency documentation for the Remote MCP Server. The gateway adds no data-residency guarantee of its own for this hop.
The gateway itself runs in Myra Security's German infrastructure.

Data minimisation. The gateway is a broker, not a store: for each tool call it forwards only the discrete arguments the model generated for that call (for example a CQL search string, a page identifier, or a SharePoint query) — not the whole chat history — and streams the tool result into the model context for the current turn. It does not persist connector content, and per-tool allow/deny policy lets you expose only the tools a connector actually needs (for example read/search only). Each user acts under their own identity (Entra for Microsoft 365, the connected Atlassian account for Confluence), so a connector can only reach what that user is already authorised to see — the gateway does not broaden the provider's own authorisation.

Two points for regulated content: tool-call arguments are model-generated, so they can contain content derived from the conversation. On a PII-active gateway (a pii_protector guardrail) or under a PII mandate (a pii_masking_enforced tenant, a pii_mandatory project, a forced agent invoke), the gateway blocks an outbound MCP tool call whose arguments carry a protected structured identifier — unless the connector is flagged a trusted_subprocessor (see MCP API — PII protection on outbound tool-call arguments). On a gateway without PII protection, arguments are forwarded as-is, so treat a connected data source as an external processor and enable it only where sending that class of content is acceptable. Credentials are stored encrypted and are never returned in list responses.

Fully sovereign alternative (self-hosted Graph)

The official Microsoft remote MCP servers are hosted by Microsoft. Where a deployment must keep the MCP layer entirely inside its own boundary (for example a strict public-sector requirement that no tool-brokering endpoint leave the organisation's control), a self-hosted Microsoft Graph MCP server — such as the open-source Softeria ms-365-mcp-server — can be run on your own infrastructure and added as an ordinary connector by URL. It talks to Microsoft Graph with your Entra app, so the MCP endpoint you connect to is one you operate.

Trade-off: the self-hosted option removes the dependency on Microsoft's hosted MCP endpoint and gives you full control of the broker, but you own its deployment, patching and Graph-permission scoping, and it exposes Graph API surface rather than the pre-certified, governance-integrated Work IQ tool set (which carries Microsoft 365 admin-centre allow/block controls and Defender observability). For most Microsoft 365 customers the official hosted connector is the lower-effort, better-governed default; the self-hosted server is the answer when sovereignty of the broker itself is a hard requirement.