A Copilot connector is the plumbing that brings your organisation’s external content into Microsoft 365 so Copilot can ground answers in real, company-specific data.
Practically speaking, a connector extracts or fetches items from a third‑party system (files, tickets, PRs, CRM records, etc.), indexes those items into the Microsoft Graph, and makes them available to Copilot and Microsoft Search under your tenant’s security and governance rules.
How it works in plain terms
A connector usually has three moving parts: the source adapter (code that knows how to read the external system), an agent or orchestration layer that schedules crawls and handles incremental updates, and the ingestion into Microsoft Graph where items are stored and security‑trimmed. Microsoft provides a Connectors SDK and a lightweight connector agent so you can build custom connectors or run Microsoft’s prebuilt ones; the agent handles full and incremental crawls, delete detection, ACL stamping, and ingestion into Graph.
Real connector examples
Copilot connectors already cover a wide range of enterprise systems. Here are practical examples you’ll see in the wild and the kinds of prompts they unlock:
- Salesforce – pull opportunity summaries and recent activity to prep for a customer call.
- Jira / Azure DevOps – surface sprint status, open bugs, or backlog items when you ask for release readiness.
- GitHub / GitLab / Bitbucket – summarise open pull requests, list failing CI runs, or extract changelog notes.
- Box / Dropbox / Google Drive / SharePoint – compare versions of a spec or summarise the latest product doc.
- ServiceNow / Zendesk / Freshservice – analyse incident trends and recommend process changes.
Each connector turns source content into indexed, searchable items so a prompt like “Summarise the top five customer issues from Zendesk this month and suggest fixes” returns grounded, citeable results instead of generic advice.
Connector versus MCP server versus calling an API
Copilot connector (indexed or federated).
A connector’s job is to make content available to Microsoft Graph and Copilot.
Many connectors perform a crawl and index model (content is ingested into the Microsoft Graph), while newer federated or user‑level connectors let Copilot fetch live data on demand using the user’s credentials. The indexed model is great for broad search and fast responses; federated connectors are useful when you need real‑time, user‑scoped access.
MCP server (Model Context Protocol).
MCP is a protocol and server model that standardizes how AI assistants call external tools and fetch context in real time. An MCP server exposes a set of tools/endpoints that agents (like Copilot or Teams Channel Agent) can discover and invoke; it’s about runtime tooling and live interactions, not indexing. Think of an MCP server as a live automation or tool host — for example, a calendar MCP server that creates events or a custom MCP server that exposes internal business actions to an agent. MCP servers are registered so Microsoft 365 agents can discover and securely call them.
Direct API Calls
Calling a service’s API is the most basic integration pattern: your app authenticates and requests data or performs actions directly. That’s perfect for bespoke workflows or when you need full control over data flow, but it doesn’t automatically make that data searchable inside Microsoft Graph or available to Copilot across the tenant. If you want Copilot to use that data as part of its knowledge, you either build a connector that indexes it into Graph or expose it via an MCP/federated connector for live access.
How they differ…
- If you index Jira with a connector, Copilot can quickly answer questions such as “What’s blocking Product release X?” using indexed issues.
- If you run an MCP server that exposes a ticket‑triage tool, Copilot (or an agent) can interface and directly open a triage workflow and assign owners in real time without needing to open the app.
- If you call the Jira API from a custom app, you can build any workflow you want – but Copilot won’t automatically see that data unless you also surface it via a connector or MCP endpoint.
Security, governance, admin controls
Connectors are designed to respect tenant boundaries and Microsoft 365 governance. Indexed content is ingested under your tenant, encrypted, and security‑trimmed so users only see what they’re allowed to see. Admins manage connectors from the Microsoft 365 admin center, control which connectors are available, and can stage rollouts or disable federated connectors if they don’t meet policy. The connector agent and SDK also let you enforce crawl schedules, incremental updates, and ACL mapping so indexing behaves predictably at scale.
Connector, MCP server, or API?
When you need Copilot (or an agent) to work with an external service, you usually have three realistic integration patterns to choose from: indexing via a Copilot/Graph connector, exposing live tools through an MCP server, or calling the service’s API directly from your app. Each option solves different problems.
Below I will try to explain the tradeoffs in plain language, give concrete examples, and finish with a short decision checklist you can use immediately. NB: I’m still learning this myself so bear with me!
- Use a Copilot connector when your goal is to make a lot of content searchable and citeable across the tenant so Copilot and Microsoft Search can answer questions quickly (think documents, tickets, PRs).
- Use an MCP server when you need runtime tooling – live, discoverable actions an agent can call (for example: triage a ticket, kick off a workflow, or run a business action) rather than just read data.
- Call the API directly if you are or need to build a bespoke app or workflow that needs full control, custom logic, or real‑time two‑way operations and you do not need Copilot to automatically see that data unless you also surface it via a connector or MCP.
These are not mutually exclusive, and sometimes you might need a combination of both. For example you may index the data for search and also expose a small set of live actions via MCP or direct API calls.
Deciding which you need
I found this check list helpful which some of my developer friends use…
- What do you need Copilot to do? If it’s answer/search/summarise → connector. If it’s act/execute/triage → MCP or API.
- Do you need tenant‑wide, security‑trimmed search? If yes, prioritise a connector.
- Do you need live user‑scoped actions or interactive workflows? If yes, design an MCP server or expose specific API endpoints as MCP tools.
- How fast do you need it? Real‑time → MCP/API. Fast search across many items → connector.
- What’s your governance posture? If you need Microsoft 365 controls and auditing, connectors and Power Platform connectors give built‑in alignment; MCP requires explicit registration and security design.
The other tip from my limited experience so far (I did say bear with me) is
- Use prebuilt connectors first – there are loads. Check the Microsoft Copilot connectors gallery for existing connectors before building custom ones.
- If you need to build (or get someone to build) a custom connextor, use the Connectors SDK and agent to build and test your connector; the agent handles crawling and ingestion.
- Pilot / test with real prompts and measure relevance, latency, and trust (are results correctly security‑trimmed and useful?).





























