Fabric Core MCP Server Tutorial: Connect Copilot to Microsoft Fabric

By A.J. · Documentation review: 24 October 2026 · Independent guide

Learning resources / Fabric Core MCP Server

1. What is the Fabric Core MCP Server?

The Fabric Core MCP Server is a remote endpoint hosted by Microsoft. It exposes supported Fabric REST API operations as tools that an MCP-compatible AI client can discover and call. Instead of building a custom integration for every assistant, you point a supported client at the endpoint and sign in once.

After that, the agent picks a tool to answer your request. Ask “show me my Fabric workspaces” and it can call the workspace-listing tool. Ask it to find lakehouses with “Customer” in the name and it can call the catalog search tool. Microsoft states that supported operations are recorded in Fabric audit logs under the identity that ran them.

What it can do

• Catalog search: find items across workspaces in the OneLake Catalog by display name, description, or workspace name, optionally filtered by item type.
• Workspaces: list, inspect, create, update, and delete.
• Items: create, read, update, and delete items such as lakehouses, semantic models, notebooks, and pipelines, and read or update an item’s definition.
• Permissions: list, grant, change, and remove workspace roles (Admin, Member, Contributor, Viewer).
• Folders: create, list, rename, move, and delete folders, and move several items into a folder at once.
• Capacities and operations: list capacities you can access, and check the state and result of long-running operations.

2. How the connection works

The server is hosted remotely by Microsoft, but your MCP client still runs where you choose, and the model behind it may process your prompts and the returned results under its own terms. Microsoft says plainly that the Core server may interact with clients and services that process data outside Fabric’s compliance boundaries, and that you are responsible for making sure the integration meets your requirements. “Remote server” does not mean the whole AI interaction stays inside Fabric.

Connection details

3. Choose the right Microsoft Fabric MCP server

Microsoft now documents a long list of Fabric MCP servers, and they are not interchangeable. Its directory was updated on 21 October 2026. Choosing Core because the name says “Fabric” is the most common mistake. Here is the directory grouped by the job you need done.

Two points from Microsoft’s own wording are worth remembering. First, “remote” and “local” describe where the server runs, not where your client or model processes data. Second, an agent can use more than one server if its client supports that, so you can pair Core with a data-access server for a fuller workflow. For the Power BI side, see our Power BI MCP Server guide. For the app-building context, see Microsoft Fabric Apps and Rayfin.

4. Prerequisites before you configure anything

• Fabric access: an active Fabric tenant with at least one workspace you can access, and a Microsoft work or school Entra ID account with Fabric permissions.
• An MCP host that supports Streamable HTTP and the server’s Entra ID authentication flow. Microsoft recommends VS Code with GitHub Copilot.
• Workspace permission: Microsoft suggests at least Viewer access to one workspace to verify the connection. Write operations need the matching role.
• Permission to create workspaces, if you plan to: Microsoft notes some organisations limit workspace creation to specific roles.
• A safe test workspace for anything that creates, changes, moves, or deletes.
• Approval controls you understand. Know how your client asks before running a tool, and never set it to approve destructive calls blindly.
• Organisation sign-off on the MCP host and model provider, in line with your data-handling and compliance rules.

5. Set up Fabric Core MCP Server in VS Code with GitHub Copilot

This follows Microsoft’s published quickstart, which estimates five to ten minutes. You are configuring a connection to a remote service. You are not cloning a repository or installing a local server.

Step 1: Add the server

1. Open Visual Studio Code with the GitHub Copilot extension and Copilot Chat available.
2. Open the Command Palette with Ctrl+Shift+P on Windows and Linux, or Cmd+Shift+P on macOS.
3. Type MCP: Add Server and choose HTTP.
4. Enter the endpoint exactly:

https://api.fabric.microsoft.com/v1/mcp/core

5. When asked for a server name, enter fabric.
6. VS Code opens your browser. Sign in with the Entra ID account that has access to your target workspace. The window closes on its own when sign-in succeeds.

Step 2: Confirm the server is connected

Back in VS Code, check that the server shows as connected in the MCP configuration area. The host must support both the Entra ID flow and remote Streamable HTTP. If your client only supports local stdio servers, pasting the endpoint into its configuration won’t work without extra host support.

Step 3: Run a read-only verification

Open Copilot Chat with Ctrl+Alt+I (or Cmd+Alt+I on macOS) and ask:

List all my Fabric workspaces. Do not create, modify, move, delete, or grant access to anything. Report the workspace names and IDs returned by the Fabric tools.

Compare the answer with the Fabric portal. If a workspace you can open in the portal is missing, check that the same account is signed in and your access is still valid.

6. Manual configuration in .vscode/mcp.json

If you prefer a project-level file, Microsoft documents this entry. Create or edit .vscode/mcp.json in your project:

{
  "servers": {
    "fabric": {
      "type": "http",
      "url": "https://api.fabric.microsoft.com/v1/mcp/core"
    }
  }
}

Save it, reconnect the server if needed, and complete the browser sign-in. The file holds only the endpoint. It has no secret, token, or password, and you shouldn’t add any.

Using another MCP host

Another host can connect only if it supports the required transport and sign-in flow. The documented parameters are:

• Transport: Streamable HTTP
• Authentication: OAuth 2.0 with Microsoft Entra ID
• Scope: https://api.fabric.microsoft.com/.default

Follow that host’s current instructions for registering a remote HTTP server and completing OAuth. Don’t copy a setup command meant for a different Fabric MCP server, because local servers, workload servers, and Core each have their own requirements.

7. First prompts that are safe to run

Use these in order. They start with discovery only.

List the Fabric workspaces I can access. Return each workspace's name, ID and any description. Do not change anything.

In the workspace named "Sales Analytics Dev", list every item you can see. Group them by item type and include the item IDs. Do not create or modify anything. If more than one workspace matches the name, stop and show me the choices.

For the workspace "Finance Dev", list the current role assignments and summarise who is Admin, Member, Contributor and Viewer. Do not change access. If the name is ambiguous, ask me to choose.

Search the OneLake Catalog for items whose name or description relates to customer retention. Group the results by workspace and item type. Do not open unrelated items or change anything.

8. How to review a tool call before you approve it

Microsoft’s overview warns that autonomous or misconfigured clients may perform destructive actions, and that safeguards such as “don’t delete” flags aren’t part of the MCP standard and may not exist in your client. So the approval prompt is your last control. Treat it like a code review for a command.

Check four things on every write

1. The tool name. Is it the operation you asked for, and not a neighbour of it? update_item and update_item_definition are very different changes.
2. The target IDs. Compare the workspace ID and item ID with what the agent listed earlier. Names can collide. IDs don’t.
3. The payload. Read the new name, role, or definition being sent. For a role change, check the user and the role.
4. The blast radius. Ask what else the call touches. Deleting a workspace removes everything inside it.

A watchlist of tools that need extra care

Make the agent plan before it acts

This prompt pattern works well for any change. It turns a one-step action into a proposal you can read.

I want to [describe the change]. Before you call any tool that changes something:
1. List what you found, with workspace and item IDs.
2. State the exact tool you plan to call and the values you will send.
3. Say what could go wrong or what else it affects.
4. Wait for my approval before running it.

9. Lab: prepare a development workspace safely

This lab shows a sensible resource-management flow: inspect, plan, create, verify. It is a set of instructions for your own tenant, not a record of steps run in a live environment.

Phase 1: discover before you create

List my Fabric workspaces and tell me whether one named "UIG Fabric MCP Lab - DEV" already exists. Do not create anything. If it exists, return its ID and list its items.

If it exists, inspect it rather than creating a duplicate. Tools generally want IDs even when people use display names.

Phase 2: plan the workspace, then create it

Propose a plan to create a development workspace named "UIG Fabric MCP Lab - DEV". Do not run it yet. Show the exact operation, the name, the permission it needs, and any side effects.

Read the proposed call. If it matches your intent and your organisation permits it, approve it through the normal tool-approval flow. Then list workspaces again to confirm. Remember that creating workspaces may need a specific permission in your tenant.

Phase 3: add a test lakehouse

In the workspace "UIG Fabric MCP Lab - DEV", propose creating one lakehouse named "McpLabLakehouse". First confirm the exact workspace ID and the item type. Do not run anything until I approve.

After approval, list the workspace items and confirm the lakehouse exists. If the operation is asynchronous, use the returned operation ID to check its state and fetch its result. Don’t assume a submitted request has finished.

Phase 4: verify, don’t trust the summary

• Re-list the workspace and confirm its ID and display name.
• Re-list the items and confirm the lakehouse and its item ID.
• Open the Fabric portal and check the same result yourself.
• Review the operation result and the audit trail where available.
• Note which identity ran the action and whether any permissions changed.

10. Tools reference

Microsoft’s tools reference (updated 23 September 2026) lists 28 tools. Each maps to a Fabric REST API operation with input validation and error handling. Availability still depends on your permissions.

• update_workspace and update_item change the name or description. update_folder renames a folder.
• Folders must be empty before deletion. Move or delete the items first.
• Role operations need user principal IDs. To use email addresses instead, add the Microsoft Graph MCP server, which resolves them for you (see section 12).

11. Workflows worth automating

The best uses of Core MCP are the repetitive housekeeping jobs people avoid because the portal makes them tedious. These four are low-risk to start and save real time.

1. Environment inventory

Useful before a migration, a clean-up, or a new team joining.

List every workspace I can access. For each one, list the items grouped by type and show the item count per type. Present the result as a table with workspace name, workspace ID, and counts for lakehouses, semantic models, notebooks and pipelines. Do not change anything.

2. Access review

Run it monthly for sensitive workspaces. It reads role assignments only.

For the workspaces named "Finance Dev" and "Finance Prod", list all role assignments. Flag anyone with the Admin role, and anyone who appears in one workspace but not the other. Present a table and do not change access.

Treat the output as a lead, not a verdict. A person in one workspace and not the other may be perfectly correct. The point is to get a list a human can check in a minute instead of clicking through two pages.

3. Naming and folder tidy-up, as a proposal

In the workspace "Sales Analytics Dev", list all items and all folders. Propose a folder structure by item purpose and a list of items to move into it. Do not move anything. I will approve the moves one folder at a time.

Approve moves in small batches, so a mistake affects a handful of items and not a whole workspace.

4. Bootstrap a development workspace

Microsoft’s own examples include creating a workspace with a lakehouse and adding your team as Contributors. Do it as a plan first, using the pattern in section 8, then approve each call. Add the Graph MCP server only if you want to give access by email address.

12. Rolling it out to a team

Connecting one laptop is easy. Making it safe for a team takes a little structure.

1. Pilot with two or three people in a development workspace. Collect the prompts that worked and the tool calls that surprised them.
2. Share the configuration, not the credentials. The .vscode/mcp.json file contains only the endpoint, so it is safe to keep in a repository. Every person signs in with their own account, so audit records show who did what.
3. Separate identities by risk. Day-to-day agent use should run under an account with limited roles. Keep Admin-level accounts for the few people who manage workspaces and roles.
4. Decide the approval policy. Reads can be quick. Anything that creates, changes, moves, or deletes needs a person to read the call. Write that down.
5. Add the Graph MCP server only if you need it. It lets the agent turn email addresses into user IDs for role operations, following Microsoft’s setup guide for the Microsoft MCP Server for Enterprise. It is another integration with its own permissions, so review it before you enable it.
6. Keep a change log. Record each write the agent made, who approved it, and the result. Compare it with the Fabric audit data when you review.
7. Review the data path with security. Agree which MCP host and model provider are allowed, and what may appear in prompts. Remember that results returned by tools are sent to the model too.

13. Security: what matters before production

A natural-language interface makes an administrative action easy to request. It does not make the action harmless. Microsoft also notes that MCP is a developing standard, and asks you to review the security of every system you connect, including hosts, clients, agents, and models.

What “uses your permissions” really means

The server calls Fabric APIs as the signed-in identity, and RBAC still applies. But if that identity is allowed to delete a workspace or grant access, an approved tool call can do exactly that. A prompt saying “read-only” is no substitute for reducing permissions and controlling tool execution.

Local does not mean private

The Core server is remote. Even when your client runs on your own machine, prompts and results may go to whichever AI service you chose. Read both Microsoft’s guidance and that provider’s terms. Organisations with strict compliance rules should run a formal data-flow review first.

14. Troubleshooting common problems

15. Frequently asked questions

16. Official documentation and further reading

• Get started with Fabric Core MCP Server: endpoint, VS Code setup, manual configuration, Graph MCP option, and cleanup.
• Fabric Core MCP Server overview: how it works, supported operations, limitations, and security considerations.
• Core MCP Server tools reference: the full tool list, example workflows, and troubleshooting.
• Choose a Microsoft Fabric MCP server: Microsoft’s directory by scenario and hosting model.
• Microsoft Graph MCP Server: get started: optional email-to-ID resolution for role operations.
• Security in Microsoft Fabric: identity, access control, and network security guidance.
• Microsoft Fabric Community: September 2026 feature summary: where the Core MCP Server is listed as generally available.