The Impossible Bridge II: One Server, Two AIs, Every SharePoint List I Built the SharePoint Integration Microsoft Hasn't The First SharePoint MCP That Talks to Copilot and Claude
The First SharePoint MCP
for Copilot Studio & Claude Desktop
A friendly, step-by-step walkthrough. We'll deploy one MCP server, connect it to two different AI assistants, and ask huge SharePoint lists questions in plain English.
No coding background needed. No Power Automate flows. No custom connector. No 5,000-item wall.
⭐ github.com/PowerofAutomation2026/TalkToSharePointImagine opening a SharePoint list with 47,000 rows and just asking it: "how many open high-priority tickets came from EMEA this week?" — and getting the answer in three seconds, in chat.
That's what we're building. A small server (an MCP server) that sits between your AI assistant and SharePoint. You ask in plain English; it does the heavy lifting against SharePoint and hands back the answer. The magic: the same server works with Microsoft Copilot Studio and Claude Desktop — no flows, no custom connectors.
Think of it as a universal translator: it turns "what your AI wants" into "what SharePoint understands," and any MCP-aware AI can plug into it.
What you'll need
Five things. If you have a Microsoft 365 tenant and a Windows machine, you're most of the way there.
- An Azure subscription — the server runs on Azure Container Apps (a cheap, tiny container).
- The Azure CLI installed — that's the
azcommand we'll use to deploy. - PowerShell — already on Windows. We run one script.
- A SharePoint list you want to query (any size — bigger is better for the demo).
- The deployment package — the zip with the server and the deploy script (link at the bottom).
You won't write code. You'll run one script that sets everything up, then click through a short wizard in Copilot Studio. That's it.
The Azure App Registration
Every secure Microsoft integration needs an App Registration in Microsoft Entra ID (formerly Azure AD). It's the identity card that lets your server prove who it is and ask SharePoint for data on your behalf.
You do not have to click through the Azure portal. When you run deploy.ps1 in Step 3, it builds the entire App Registration automatically — name, identity URI, scope, permissions, consent, and secret. Skip straight to the build if you like.
But if you're the kind of person who likes to understand what just happened — or your admin wants to do it by hand — here's exactly what the script creates, step by step:
Create the registration
Portal → Microsoft Entra ID → App registrations → New registration. Name it (e.g. SharePoint MCP), choose single tenant, click Register. Copy the Application (client) ID and Directory (tenant) ID it gives you.
Expose an API + add a scope
Under Expose an API, set the Application ID URI to api://<client-id>, then add a scope called user_impersonation. This is how the server identifies the token meant for it.
Set the token version to 2
In the Manifest, set requestedAccessTokenVersion to 2. The MCP framework only accepts modern v2 tokens — this one line saves hours of "issuer mismatch" confusion.
Add the SharePoint permissions
Under API permissions → Add → Microsoft Graph → Delegated, add: User.Read, Sites.Read.All, Sites.ReadWrite.All, offline_access, openid, profile. Then click Grant admin consent.
Add the sign-in redirect URIs
Under Authentication, add the server's callback URL and the AI clients' callbacks (the package lists them). This is where sign-in returns after you approve access.
Create a client secret
Under Certificates & secrets → New client secret, copy the value immediately (it's shown once). The server uses it to securely exchange your sign-in token for a SharePoint token.
Six pieces: an identity, a scope, v2 tokens, Graph permissions, redirect URLs, and a secret. The script assembles all six in about twenty seconds. Now you know what each one is for.
Deploy it in 5 steps
Sign in to Azure
Open PowerShell and log in. A browser window pops up — pick your work account.
Choose the subscription you want when it asks. Done.
Open the package folder
Unzip the deployment package, then point PowerShell at that folder.
This folder has the server and the one script that does all the setup.
Run the deploy script
One command builds the server, creates the security app, and pushes it live.
It walks through five stages on its own — login check, resource setup, the security (Entra) app, the container build, and a health check. Just watch the green OK lines roll by.
OK Health check: version 6.1 live
Connect Copilot Studio
In your agent: Tools → Add a tool → New tool → Model Context Protocol. Paste your server URL (the script prints it, ends in /mcp).
For authentication, pick OAuth 2.0 → Dynamic discovery. This one choice is the whole trick — it lets Copilot connect the same easy way Claude Desktop does.
Ask your first question
Open the Test panel and try these, in order:
If the first returns your email, auth works and everything else follows.
The connect-and-test flow, screen by screen
Here's exactly what you'll see in Copilot Studio. Three screens: add the server, watch the tools load, then ask your first question.
Screen 1 — Add the MCP server
Pick OAuth 2.0 → Dynamic discovery. That's the whole trick — it connects Copilot the same effortless way Claude Desktop connects.
Screen 2 — Sign in, tools load automatically
Screen 3 — Ask in the Test panel
That list has 47,000 rows. SharePoint normally refuses to filter it. The server gets around the wall by filtering on indexed columns and paging through results — so the limit never appears. You never think about it. You just ask.
Lessons I learned the hard way
This didn't work on the first try. Or the tenth. Here's what broke and what fixed it — so you skip the pain.
A library auto-upgraded and broke itself
A newer version of the MCP framework removed a feature the server used. Fix: pin the version. The package already pins it — don't bump it without testing.
I was using the wrong door for Copilot
I tried to wire Copilot in with a custom connector — which routes auth a totally different way and caused endless token errors. Fix: use Copilot's Dynamic discovery option instead. Same path Claude already used. Instant relief.
The server held the wrong kind of token
The token that proves who you are isn't the same token Microsoft Graph accepts. Fix: the server now does an On-Behalf-Of exchange — it swaps your sign-in token for a proper Graph token behind the scenes.
A Windows console encoding quirk
The Azure build log contains characters the default Windows console can't print, and it crashed mid-build. Fix: the script now forces UTF-8 and builds without streaming that log. No more crash.
Expected — and a 30-second fix
Each redeploy resets the server's memory of connected clients. Fix: in Copilot Studio, delete the connection and create a new one. It re-registers instantly.
What this project actually demonstrates
If you found this post while sourcing talent, here's the honest read: this isn't a tutorial I copied. It's a net-new integration I designed, debugged, and shipped to production — the first SharePoint MCP server to connect natively to both Microsoft Copilot Studio and Claude Desktop. It sits right at the intersection Microsoft is investing in: the Microsoft cloud, agentic AI, and enterprise-grade security.
More than the checklist: I take a vague, "this has never been done" problem and turn it into something that works, is documented, and a beginner can deploy in ten minutes. That's the engineer I am. If you're building the future of agents on the Microsoft stack, I would love to be part of it.
Kerolos — Senior Infrastructure & Security Engineer. Open to conversations with Microsoft and partners building in this space. Let's talk →
Get the package
The server, the Dockerfile, the one-shot deploy script with every fix above baked in, and the Copilot Studio + Claude Desktop setup guides.
Kerolos — Senior Infrastructure & Security Engineer. I build the bridges that were supposed to be impossible, then write down how, so the next person doesn't bleed for it. Power of Automation · June 2026.
Comments
Post a Comment