Microsoft Fabric MCP Server

A local-first Model Context Protocol (MCP) server that provides AI agents with comprehensive access to Microsoft Fabric's public APIs, item definitions, and best practices. Documentation tools use bundled specifications without connecting to live Fabric environments; operational tools call Fabric APIs using the configured identity.

Table of Contents

• Overview
• Installation
  • IDE
    • VS Code (Recommended)
    • Manual Setup
• Usage
  • Getting Started
  • What can you do with the Fabric MCP Server?
    • Catalog Discovery
    • Fabric Item Types & APIs
    • Resource Definitions & Schemas
    • Best Practices & Examples
    • Development Workflows
  • Workspace Metadata
  • Available Tools
    • API Documentation & Best Practices
    • OneLake Data Operations
    • OneLake Security — Data Access Roles
    • OneLake Shortcuts
    • OneLake Settings
    • Core Fabric Operations
    • Data Factory Operations
• Support and Reference
  • Documentation
  • Feedback and Support
  • Security
  • Data Collection
  • Contributing
  • Code of Conduct
• License

Overview

Microsoft Fabric MCP Server gives your AI agents the knowledge they need to generate robust, production-ready code for Microsoft Fabric, alongside authenticated tools for working with Fabric resources.

Key capabilities:

• Complete API Context: Full OpenAPI specifications for all supported Fabric item types
• Item Definition Knowledge: JSON schemas for every Fabric item type (Lakehouses, pipelines, semantic models, notebooks, etc.)
• Built-in Best Practices: Embedded guidance on pagination, error handling, and recommended patterns
• Local-First Documentation: Documentation tools read bundled resources locally; operational tools access Fabric under the configured identity
• Workspace Metadata Updates: Rename a known workspace or update or clear its description without changing other properties
• Data Factory Integration: Pipeline and Dataflow Gen2 management with M query execution

Installation

IDE

Start using Fabric MCP with your favorite IDE. We recommend VS Code:

VS Code (Recommended)

Compatible with both the Stable and Insiders builds of VS Code.

1. Install the GitHub Copilot Chat extension.
2. Install the Fabric MCP Server extension.

Manual Setup

Fabric MCP Server can also be configured across other IDEs, CLIs, and MCP clients:

Usage

Getting Started

1. Open GitHub Copilot in VS Code and switch to Agent mode.
2. Click refresh on the tools list
   • You should see the Fabric MCP Server in the list of tools
3. Try a prompt that uses Fabric context, such as What Fabric item types are available?
   • The agent should be able to use the Fabric MCP Server tools to complete your query
4. Check out the Microsoft Fabric documentation and review the troubleshooting guide for commonly asked questions
5. We're building this in the open. Your feedback is much appreciated!
   • Open an issue in the public repository

What can you do with the Fabric MCP Server?

The Fabric MCP Server supercharges your agents with Microsoft Fabric context. Here are some prompts you can try:

Capacity Discovery

• "List Fabric capacities where I am an administrator or contributor"
• "Show the IDs, SKUs, regions, and states of my accessible Fabric capacities"
• "Get the next page of Fabric capacities using the continuation token from the previous response"

core_list-capacities returns exactly one page of capacity metadata in capacities, with continuationToken and continuationUri when supplied by Fabric. Pass the token unchanged through --continuation-token to request another page. Returned URIs are metadata only and are never followed; the tool does not retrieve all pages automatically.

The Fabric List Capacities API lists capacities where the calling principal is an administrator or contributor. It supports users, service principals, and managed identities. Delegated calls require Capacity.Read.All or Capacity.ReadWrite.All; this is not an Azure subscription inventory and takes no subscription parameter.

Catalog Discovery

• "Search the OneLake catalog for items related to 'sales revenue'"
• "Find a Lakehouse with 'customer' in the name across my workspaces"
• "Discover all Report items in the catalog and show which workspace they live in"
• "Filter the catalog to Warehouse and Notebook items"
• "List the Fabric workspaces I can access and show their capacity and domain metadata"
• "List my Fabric workspaces where I am an Admin or Member"
• "List accessible Fabric workspaces and include their workspace-specific API endpoints"
• "List item metadata in my Fabric workspace, including nested folders"
• "Show only the Lakehouses directly in this Fabric folder"

Fabric Item Types & APIs

• "What are the available Fabric item types I can work with?"
• "Show me the OpenAPI operations for 'notebook' and give a sample creation body"
• "Get the platform-level API specifications for Microsoft Fabric"
• "List all supported Fabric item types"

Resource Definitions & Schemas

• "Create a Lakehouse resource definition with a schema that enforces a string column and a datetime column"
• "Show me the JSON schema for a Data Pipeline item definition"
• "Generate a Semantic Model configuration with sample measures"
• "What properties are required for creating a KQL Database?"

Best Practices & Examples

• "Show me best practices for handling API throttling in Fabric"
• "How should I implement retry logic for Fabric API rate limits?"
• "List recommended retry/backoff behavior for Fabric APIs when rate-limited"
• "Show me best practices for authenticating with Fabric APIs"
• "Get example request/response payloads for creating a Notebook"
• "What are the pagination patterns for Fabric REST APIs?"

Development Workflows

• "Get the metadata for Fabric item '' in workspace '' without reading its data or definition"
• "Show the display name, description, and type of Fabric item '' in workspace ''"
• "Generate a data pipeline configuration with sample data sources"
• "Help me scaffold a Fabric workspace with Lakehouse and notebooks"
• "Create a Microsoft Fabric workspace called Sales Planning"
• "Create a Fabric workspace called Capacity Analytics using the existing capacity with ID <capacity-id>"
• "Show me how to handle long-running operations in Fabric APIs"
• "What's the recommended error handling pattern for Fabric API calls?"

Workspace Metadata

Use core_get-workspace to retrieve metadata for one known workspace through the Get Workspace REST API.

• "Get metadata for Fabric workspace aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa."
• "Show the capacity, domain, and workspace identity for Fabric workspace aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa."
• "Get Fabric workspace aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa with workspace-specific API and OneLake endpoints."

fabmcp core get-workspace --workspace-id aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa
fabmcp core get-workspace --workspace-id aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa --prefer-workspace-specific-endpoints true

The result contains a workspace object with id and displayName. When returned by Fabric it also includes type, description, capacityId, capacityAssignmentProgress, capacityRegion, domainId, workspaceIdentity, oneLakeEndpoints, apiEndpoint, and applied tags. Missing/null optional fields are omitted; an explicitly empty tag list remains empty. New workspace types, capacity regions, and progress values are preserved.

Workspace identity fields contain application and service-principal IDs, not credentials. Returned endpoints are metadata only: this tool never contacts them. Workspaces with public access disabled may return workspace-specific OneLake endpoints even when the preference is omitted or false; an absent API endpoint is not inferred.

The tool does not list workspaces or items, read item data or definitions, modify resources, or poll capacity assignments. Errors retain their HTTP status without exposing backend bodies. A 429 includes validated Retry-After guidance when available, but the tool does not automatically retry.

Permissions: The caller needs Viewer-or-higher workspace access. Delegated callers also need Workspace.Read.All or Workspace.ReadWrite.All. The API supports users, service principals, and managed identities subject to their permissions and Fabric configuration. The tool preserves the server's configured credentials: stdio/hosting identity uses the host's credential provider, and HTTP/OBO uses the current caller's delegated context.

By default, the MCP text response contains the command envelope with results.workspace. With --structured-output-mode compact or --structured-output-mode duplicated, the server also advertises the typed output schema and returns structuredContent.workspace.

Available Tools

The Fabric MCP Server exposes tools organized into three categories:

API Documentation & Best Practices

OneLake Data Operations

OneLake Security — Data Access Roles

OneLake Shortcuts

OneLake Settings

Core Fabric Operations

The configured Fabric Core HTTP client does not automatically follow redirects. This policy applies to all Core operations, including existing create/search and update calls as well as deletion: a returned 3xx response is surfaced as a failure instead of following its Location. Existing configured handlers, proxy settings, timeouts, credentials, and recording wrappers are retained. Workspace type is optional in Get, List, Create, and Update responses; omitted/null values are not invented, while present nonempty future type strings are preserved.

Create Item (core_create-item)

Calls the Create Item API once with display-name, item-type, and optional description. Supply a nonempty workspace UUID using workspace-id or the backward-compatible workspace alias. Workspace names are not resolved. A workspace-id that is not empty or whitespace takes precedence when both options are supplied, even if it is invalid; the command does not silently fall back to the alias. Invalid and all-zero UUIDs are rejected before authentication or HTTP, and accepted UUID formats are normalized in the request URL.

Missing required options are identified by their registered names, such as --display-name or --item-type, before any service call. Other parser failures return sanitized guidance without echoing supplied values or unknown option names.

This example creates a real item when run with authorized credentials:

fabmcp core create-item --workspace-id cfafbeb1-8037-4d0c-896e-a46fb27ff229 --display-name "Sales" --item-type Lakehouse

The caller needs Contributor or higher workspace access. Delegated calls require Item.ReadWrite.All or the item-specific ReadWrite.All scope. Non-Power BI items require a supported Fabric capacity and tenant/capacity settings that enable Fabric item creation; Power BI items require the appropriate license. Service-principal and managed-identity support depends on the item type. Item types remain strings rather than a fixed client-side list.

Display names must follow the item's naming rules, and descriptions allow at most 256 characters. The tool does not supply item definitions, creation payloads, folders, or sensitivity-label settings. Item types that require a definition or creation payload need a different creation path.

Create Item supports both outcomes documented by its endpoint: 201 returns validated metadata in the existing results.item shape; 202 returns an explicit results.operation receipt, never an empty/default item. Both modes return a synchronous 201 result immediately, without operation reads or requiring an operation ID. Other success codes, including 200 and 204, are not part of this endpoint's contract: they produce a sanitized unconfirmed-outcome error with guidance to check whether creation occurred. The shared LRO infrastructure also supports synchronous 200 for future adapters whose endpoints document it; it does not accept arbitrary success codes.

Choose the mode before the single creation request. This is an alternative to the earlier creation example, not a way to resume an already accepted creation:

fabmcp core create-item --workspace-id cfafbeb1-8037-4d0c-896e-a46fb27ff229 --display-name "Sales" --item-type Lakehouse --sync true --max-wait-seconds 120 --early-poll false

The early first probe is a deliberate exception to the initial successful 202 Retry-After guidance (often 20 seconds); it is not a claim that every server hint is honored. The receipt keeps serverRetryAfterSeconds separate from recommendedPollAfterSeconds. After that first probe, subsequent polls honor validated returned hints. Only safe operation GETs can be retried on HTTP 429/503, within the remaining budget; those hints are never shortened by the early-probe exception. Missing, malformed, multiple, negative, or overflowing hints use a conservative 20-second fallback. Valid HTTP-date hints are supported; zero/past hints have a one-second scheduling floor to prevent a tight loop.

The 600-second maximum is a server-enforced operational guard on MCP waiting, not a Fabric API requirement or a limit on how long the Fabric operation may run. The shared service validation enforces it even when invoked without the command binding layer.

Creation is never automatically resubmitted. Stopping MCP waiting does not cancel Fabric's operation, and no detached job continues polling. Client cancellation or a shorter HTTP/client timeout can end the wait sooner than the configured budget. A local budget expiry is not a failed mutation: resume using the operation ID, rather than increasing the budget by issuing another create call.

Failures suppress raw backend messages, exception details, stack traces, and local paths. HTTP 403 can indicate permissions or unavailable tenant/capacity features; status-less network failures retain HTTP 503. Before acceptance is known, a timeout, cancellation, network failure, or invalid response can leave the mutation outcome uncertain; check whether creation occurred before retrying.

Long-running operation tools

The Get Operation State and Get Operation Result tools each take only operation-id, a nonempty UUID. Each invocation performs one GET, with no implicit polling, retries, mutation, or cancellation. URLs are constructed from the fixed Fabric API base and the validated ID. Returned links are not followed or returned as action URLs, and a response cannot replace the requested operation ID.

An agent-driven flow starts with the receipt from the original sync=false creation:

{
  "operation": {
    "status": "Accepted",
    "operationId": "0acd697c-1550-43cd-b998-91bfbfbd47c6",
    "serverRetryAfterSeconds": 20,
    "recommendedPollAfterSeconds": 3
  }
}

Wait for the recommendation, then make one state read. If still pending, wait for that response's guidance before the next read. After Succeeded, fetch the result for Create Item, which is a result-bearing API:

fabmcp core get-operation-state --operation-id 0acd697c-1550-43cd-b998-91bfbfbd47c6
# Only after the state says Succeeded:
fabmcp core get-operation-result --operation-id 0acd697c-1550-43cd-b998-91bfbfbd47c6

A state GET returning HTTP 200 means the read succeeded, not necessarily the mutation. The returned state.status can be Undefined, NotStarted, Running, Succeeded, Failed, or a future string. Unknown states are preserved and handled conservatively, never interpreted as successful completion. Progress (0-100) and timestamps are optional. Failed states expose only a safe error code and request UUID, not backend error text or nested details.

The generic result is not assumed to be a Fabric item. It uses { "operationId": "...", "hasBody": true, "value": ... } for JSON objects, arrays, or scalars. JSON null remains hasBody=true, value=null; an actually empty HTTP 200 body uses hasBody=false with value omitted. Nonempty bodies require application/json. Binary (application/octet-stream) and other media are explicitly unsupported, even if empty. JSON responses are limited to 1 MiB (1,048,576 bytes), including streamed responses without Content-Length; oversized or malformed content produces a sanitized error, never truncation or fabricated success.

As described in the Fabric LRO guidance, not every operation has a result. For an API explicitly documented as having no result, confirmed Succeeded is sufficient; do not fetch /result. Neither HTTP 404 nor an absent Location proves successful no-result completion. The shared dispatcher/poller supports explicit result-bearing and no-result adapters; workspace capacity assignment retains its existing submit-only contract and is not retrofitted with sync waiting in this release.

Both read tools require the same resource permissions and delegated scopes as the initiating API. Read-only discovery is not an authorization grant. Credential resolution remains per call, including every poll and result read, with the configured caller's identity.

Catalog Search (core_search-catalog)

Calls the Catalog Search API for one page of metadata visible to the caller. Delegated calls require Catalog.Read.All; catalog discovery does not grant access to item contents.

# Initial page.
fabmcp core search-catalog --search "Sales" --filter "Type eq 'Report'" --page-size 25

# Next page: copy the token unchanged; do not repeat search or filter.
fabmcp core search-catalog --continuation-token '<token from the preceding page>'

A continuation token already carries the original search, filter, and page size. Combining continuation-token with search or filter is rejected locally with HTTP 400 before service, authentication, or network calls; supplied criteria are never silently dropped. page-size remains optional and must be between 1 and 1000 when supplied, including with a token.

Success keeps the existing nested command envelope: entries are in results.results.value, and the next token is in results.results.continuationToken. Entries retain their typed metadata and available hierarchy.workspace information. There is no all-pages fetch, polling, or automatic retry. HTTP failures retain their original status with sanitized messages, while status-less network failures retain HTTP 503; raw exception details are not included in public error results.

Get Item (core_get-item)

Calls the Get Item API once.
Both workspace-id and item-id are required nonempty UUIDs, normalized before authentication or HTTP.
The result contains an item object with id, displayName, type, workspaceId, and description
when available. Missing/null descriptions are omitted and an explicitly empty description is preserved.
The returned item and workspace IDs must match the requested IDs. Unlike workspace metadata, item
type is required; future nonempty type strings are accepted.

fabmcp core get-item --workspace-id <workspace-id> --item-id <item-id>

The caller needs read permission for the item. Delegated callers also need Item.Read.All,
Item.ReadWrite.All, or an appropriate item-specific read scope. Authentication uses the host's
configured credential provider and preserves the caller's context; the tool does not grant permissions.

This read-only tool does not resolve names, retrieve definitions or data, return workload-specific
properties, or request default-identity information. Use core_search-catalog to discover an unknown
item ID. Only the documented HTTP 200 metadata response is accepted.

For MCP clients, --structured-output-mode compact or --structured-output-mode duplicated exposes
the typed output schema and structuredContent.item. The default mode keeps content-only responses
with results.item.

Command validation uses the shared sanitized handling; service errors do not expose raw backend
bodies. HTTP 429 includes a valid Retry-After delay in seconds or retry time in UTC when supplied.
Missing, malformed, negative, out-of-range, or multiple headers produce generic retry guidance.
The tool does not retry automatically or follow redirects.

Get Capacity (core_get-capacity)

Calls Get Capacity:
GET https://api.fabric.microsoft.com/v1/capacities/{capacityId}.
The required capacity-id argument (--capacity-id in the CLI) must be a nonempty UUID, not a capacity name or Azure resource ID. Invalid IDs are rejected before authentication or network access.

fabmcp core get-capacity --capacity-id 96f3f0ff-4fe2-4712-b61b-05a456ba9357

The typed result contains only capacity metadata:

{
  "capacity": {
    "id": "96f3f0ff-4fe2-4712-b61b-05a456ba9357",
    "displayName": "F4 Capacity",
    "sku": "F4",
    "region": "West Central US",
    "state": "Active"
  }
}

All five fields are required. SKU, region, and state remain strings so new service values are preserved. The tool does not list capacities, access ARM or billing, read item data, change capacity settings, assign workspaces, or start or poll long-running operations.

The caller needs Administrator or Contributor permission on the capacity. Delegated access requires Capacity.Read.All or Capacity.ReadWrite.All. The API documents support for users, service principals, and managed identities; this tool uses the server's configured credential without changing authentication behavior.

Failures preserve the service status with sanitized messages. For throttling, valid Retry-After guidance is returned without automatic retries. The operation expects a synchronous HTTP 200 response and rejects incomplete or invalid metadata instead of returning an empty success.

Example prompts: "Get metadata for Fabric capacity 96f3f0ff-4fe2-4712-b61b-05a456ba9357" or "Show the SKU, region, and state of Fabric capacity 96f3f0ff-4fe2-4712-b61b-05a456ba9357."

Listing workspace management metadata

core_list-workspaces calls the Core List Workspaces REST API. Use it to discover workspace IDs and inspect management metadata. Unlike onelake_list-workspaces, it does not use the OneLake storage/data-plane listing. Unlike core_search-catalog, it enumerates workspaces rather than searching catalog items. It does not read item data or definitions, modify resources, or perform long-running operations.

fabmcp core list-workspaces
fabmcp core list-workspaces --roles Admin,Member --prefer-workspace-specific-endpoints true
fabmcp core list-workspaces --roles Admin,Member --prefer-workspace-specific-endpoints true --continuation-token '<token from the preceding page>'

Each call returns one server-sized page in results.workspaces, plus results.continuationToken and results.continuationUri when supplied by Fabric. Structured MCP output uses the same payload without the command envelope. An empty workspace array can still have continuation information; no continuation information means enumeration is complete. There is no page-size option or automatic all-pages fetch. continuationUri is informational only and is never followed.

Workspace entries contain id, displayName, and type, with description, capacityId, capacityRegion, domainId, tags (ID and display name), and apiEndpoint when available. Missing optional metadata is omitted rather than guessed or fetched separately; explicit empty descriptions and tag arrays are preserved. The role filter does not add a role field to the response. Requesting endpoint metadata does not configure private-link connectivity or change the listing endpoint.

The API supports users, service principals, and managed identities. Delegated access requires Workspace.Read.All or Workspace.ReadWrite.All; service principals and managed identities also require the Fabric tenant setting permitting service principals to use Fabric APIs. Results are limited to workspaces accessible to the configured calling identity, including the authenticated caller when using HTTP/OBO. The tool does not change authentication configuration.

Failures preserve the service's HTTP status without exposing raw backend error bodies. For HTTP 429, the tool returns parsed Retry-After guidance when available, or a generic wait-before-retrying message. It does not automatically retry or sleep.

Workspace and folder inventory

core_list-items calls the Fabric Core List Items API. Use it for a scoped metadata inventory, not for OneLake file/blob listing (onelake_list-items) or cross-workspace discovery (core_search-catalog).

# First page of all workspace items, including nested folders.
fabmcp core list-items --workspace-id aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb

# Direct Lakehouses in one folder, excluding its nested folders.
fabmcp core list-items --workspace-id aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb --root-folder-id bbbbbbbb-1111-2222-3333-cccccccccccc --type Lakehouse --recursive false

Each invocation returns exactly one page: an items array and any continuationToken and continuationUri supplied by Fabric. An empty array can still have a next page. Call again with continuation-token and unchanged filters to continue; this tool never fetches all pages automatically or follows the returned URI. Copy the token without decoding Base64 or changing existing percent escapes.

Items contain ID, display name, type, workspace ID, and available description, folder ID, logical ID, tags, and sensitivity-label ID. Optional null properties are omitted. No item data, definitions, or workload-specific properties are returned. The optional REST include=DefaultIdentity expansion is intentionally unsupported: it is neither requested nor serialized.

The caller needs workspace Viewer access. Delegated calls require Workspace.Read.All or Workspace.ReadWrite.All; the API supports user, service-principal, and managed identities. The tool preserves the server's configured authentication strategy, including its existing HTTP/OBO credential path. A 429 response retains its status and provides retry guidance when a valid Retry-After header is available; the tool does not retry automatically.

Creating a workspace

core_create-workspace implements Create Workspace with one POST /v1/workspaces, expecting a synchronous 201 Created response.

Omitted optional fields are not sent. The tool does not provision a capacity or domain, check name availability, call assignToCapacity, create items, or poll an operation.

These examples create real workspaces when run with authorized credentials. Replace the placeholders with existing resource IDs before using the second example:

fabmcp core create-workspace --display-name "Sales Planning"

fabmcp core create-workspace --display-name "Capacity Analytics" `
  --description "Analytics workspace" `
  --capacity-id "<capacity-id>" `
  --domain-id "<domain-id>"

The typed result contains workspace and, when supplied by Fabric, location. Workspace metadata includes ID, display name, type, and any returned description, capacity ID/region, domain ID, API endpoint, and applied tags. Missing optional metadata remains absent; the result does not infer capacity-assignment completion. Location and API endpoints are metadata only and are never followed. A valid workspace body succeeds even if the Location header is absent.

Permissions: The caller needs workspace-creation permission granted by a Fabric administrator. When assigning a capacity, the caller needs capacity contributor or admin permission. Domain assignment also requires the relevant domain permission. Delegated callers need Workspace.ReadWrite.All. For service principals, the administrator must enable Service principals can create workspaces, connections, and deployment pipelines for an allowed security group containing the principal. The separate Service principals can call Fabric public APIs setting alone does not grant workspace-creation permission. Admin access on an existing workspace is not the creation prerequisite.

Failure handling: Creation is mutating and not idempotent. The tool never automatically retries, including after throttling, and preserves failure status with sanitized messages and valid Retry-After guidance. A timeout, cancellation, network failure, or invalid success response can leave the creation outcome uncertain. Check whether the workspace exists before making another creation request. The tool is unavailable in read-only server mode.

Updating workspace metadata

• "Rename Fabric workspace <workspace-id> to 'Finance Analytics' without changing its description"
• "Set the description of Fabric workspace <workspace-id> to 'Quarterly reporting' without renaming it"
• "Clear the description of Fabric workspace <workspace-id> and keep its display name"

core_update-workspace (fabmcp core update-workspace) implements the synchronous
Update Workspace API.
It requires a nonempty workspace UUID and at least one update:

Omitted or null optional values are not sent and leave those properties unchanged. Supplied text is
not trimmed. For example, MCP arguments to clear only the description are:

{ "workspace-id": "<workspace-id>", "description": "" }

The caller needs the workspace Admin role and, for delegated access, Workspace.ReadWrite.All.
This mutating tool is unavailable in read-only mode and uses the server's standard destructive-operation
confirmation. Its result contains workspace with only id, displayName, type, and description
when returned by Fabric; an empty returned description remains empty.

The tool makes one application-level PATCH with no application retries, prefetch, follow-up requests,
polling, or enrichment. The Fabric Core HTTP client does not automatically follow redirects.
Response URLs are not followed by application code. Capacity, domain,
identity, permissions, tags, endpoints, items, and data cannot be updated through this tool.
Failures retain the HTTP status and expose only sanitized messages and validated Retry-After
guidance. If a request times out or returns an invalid success payload, the update might already
have been applied; verify the workspace before manually retrying.

Updating item metadata

core_update-item implements Update Item:
one application-level PATCH /v1/workspaces/{workspaceId}/items/{itemId} with a synchronous 200 Item response.
It requires workspace-id and item-id as nonempty UUIDs, plus at least one of display-name or description.
It does not resolve names, fetch the item first, read item data, or change definitions, permissions, tags, or identity.

Omitted properties remain unchanged. An explicitly empty description clears it; JSON null is treated as omitted.
Descriptions may contain at most 256 characters and are not trimmed. Display names must not be empty or whitespace-only and must follow the item's
type-specific naming rules; there is no universal display-name length limit enforced by this tool.
For example, these MCP arguments clear only the description:

{
  "workspace-id": "cfafbeb1-8037-4d0c-896e-a46fb27ff229",
  "item-id": "5b218778-e7a5-4d73-8187-f10824047715",
  "description": ""
}

The result contains an item with id, displayName, type, workspaceId, and an optional description.
Definitions, data, identities, tags, and workload-specific properties are not returned. Existing server output modes apply:
the default returns text content; compact and duplicated modes additionally expose the typed output schema and structured content.

The caller needs read and write permission on the item. Delegated callers need Item.ReadWrite.All or the corresponding
item-specific scope, such as Notebook.ReadWrite.All. Service-principal and managed-identity support depends on the item type.
The tool is mutating and idempotent, is unavailable in read-only mode, and uses the existing host authentication and confirmation policies.
It performs no automatic retry or long-running-operation polling. HTTP failures preserve their status and suppress backend details;
valid nonnegative integer Retry-After values provide wait guidance. After a timeout or invalid response, the update may already
have completed: verify the item's state before retrying.
The Fabric Core HTTP client does not automatically follow redirects.

Delete a Fabric item

core_delete-item sends one Delete Item API request. It does not resolve names, inspect item types, retry requests, or poll operations.
The Fabric Core HTTP client does not automatically follow redirects, including 307/308 responses that would otherwise repeat the DELETE.

Deletion is destructive in every mode. Omission or false uses Fabric's default deletion behavior, which soft-deletes only supported item types. It does not guarantee that the item can be recovered. Rejected default/soft deletions are returned as errors; the tool never falls back to permanent deletion.

Permanent deletion cannot be recovered. The CLI requires an explicit value: --hard-delete true. A bare --hard-delete, invalid value, or repeated occurrence is rejected before authentication or deletion. MCP advertises an optional Boolean input and preserves the existing argument conversion behavior: an explicitly supplied string "true" or string array ["true"] can also bind as one explicit true value. The command does not enforce the original JSON type. Omission, null, an empty value, and false never enable hard deletion; empty/invalid values are rejected.

Illustrative CLI syntax (replace the placeholders only when intentionally deleting an item):

# Default API deletion behavior; recovery is not guaranteed.
fabmcp core delete-item --workspace-id "<workspace-uuid>" --item-id "<item-uuid>"

# Explicitly do not request permanent deletion.
fabmcp core delete-item --workspace-id "<workspace-uuid>" --item-id "<item-uuid>" --hard-delete false

# Explicitly request irreversible permanent deletion.
fabmcp core delete-item --workspace-id "<workspace-uuid>" --item-id "<item-uuid>" --hard-delete true

Soft deletion requires write permission on the item; hard/permanent deletion requires the workspace Admin role. Delegated callers need Item.ReadWrite.All or the corresponding item-specific write scope. Service principal and managed identity support depends on the item type. Existing host authentication and destructive-operation consent requirements apply; the tool is unavailable in read-only mode.

On the documented empty HTTP 200 response, the tool returns only workspaceId, itemId, and hardDeleteRequested. These identify the requested target and mode, not item metadata or a recovery guarantee. A 404 or other failure is an error, not a successful deletion. An upstream 400 reports Fabric rejection with item-state, soft-delete support, and tenant-setting guidance, not a missing-ID diagnosis. Throttling responses retain status 429 and include validated Retry-After guidance when available, without automatic retries. A genuinely canceled or timed-out request does not confirm deletion, but cancellation arriving after a completed HTTP 200 response does not discard that confirmation.

Delete Workspace implements the Fabric Core Delete Workspace API.

The CLI command is fabmcp core delete-workspace --workspace-id <workspace-uuid>. Its only option, workspace-id, is required and must be a nonempty UUID. Invalid IDs are rejected before authentication or HTTP. Names, fuzzy lookup, implicit target selection, and bulk deletion are not supported.

The caller must have the Admin workspace role. Delegated callers additionally require Workspace.ReadWrite.All. The API documents support for users, service principals, and managed identities; this does not imply those identity flows have been exercised by the offline tests.

The tool sends one DELETE /v1/workspaces/{workspaceId} request with no body or automatic redirects. Only the documented synchronous, empty 200 OK produces a typed acknowledgement: {"workspaceId":"<canonical-workspace-uuid>","deleted":true}. It does not read or deserialize a workspace response body, enumerate or individually delete items, change permissions, retry automatically, or poll. Failures retain their HTTP status and expose sanitized messages; 403 and 404 never count as successful deletion. An upstream 400 advises checking workspace state and tenant restrictions rather than claiming the validated UUID is missing. Validated Retry-After guidance can be returned for throttling. A genuinely canceled or timed-out request does not confirm the outcome; check the workspace state before attempting another deletion. A returned HTTP 200 still confirms success if cancellation arrives afterward.

The tool is marked destructive, not read-only, and idempotent in the no-additional-effects sense; repeated requests can still return 404. Read-only MCP servers hide and reject this tool. The existing MCP elicitation gate requires consent and rejects unsupported or declined consent unless explicitly disabled by the host's dangerous configuration. Annotations alone do not guarantee human confirmation, and direct CLI execution does not use the MCP elicitation gate. Implementation or test approval does not authorize real deletion; API-level tests use substituted HTTP and credentials only.

Workspace capacity assignment

Example prompt: "Submit a request to assign workspace <workspace-id> to capacity <capacity-id>; do not wait for completion."

fabmcp core assign-workspace-to-capacity requires both --workspace-id and --capacity-id as nonempty GUIDs. It uses Assign To Capacity to send one POST with { "capacityId": "<target-capacity-id>" }.

The documented response is 202 Accepted, with no response body: assignment is in progress. The tool preserves status 202 and returns its own receipt:

{
  "workspaceId": "cfafbeb1-8037-4d0c-896e-a46fb27ff512",
  "capacityId": "0f084df7-c13d-451b-af5f-ed0c466403b2",
  "accepted": true,
  "state": "Pending"
}

capacityId is the requested target, not a verified current assignment. The tool never reports completion, invents an operation handle, polls, or follows up automatically. A caller can later inspect capacityId and capacityAssignmentProgress through Get Workspace. Assignment can still fail after acceptance.

The caller needs workspace Admin and capacity Contributor or Admin permissions, with both Capacity.ReadWrite.All and Workspace.ReadWrite.All scopes. The API supports users, service principals, and managed identities. Authentication uses the server's configured identity provider; remote OBO calls use the caller's permissions.

Workspaces containing Fabric items other than Power BI items cannot migrate across regions. Such workspaces can only be assigned to Fabric, Fabric trial, or Power BI Premium capacity. These restrictions are enforced by Fabric: the tool makes no preflight calls or eligibility guarantees. It does not create workspaces or provision, resize, or activate capacities; creating a workspace with a capacityId is a separate API operation.

Failures preserve the service's HTTP status and return sanitized guidance. On throttling, a valid Retry-After delay is reported without automatically retrying. If a timeout or network failure prevents confirmation, inspect the workspace before submitting again. The tool never chooses a different target capacity.

Data Factory Operations

Always verify available commands via --help. Command names and availability may change between releases.

Support and Reference

Documentation

• See the Microsoft Fabric documentation to learn about the Microsoft Fabric platform.
• For MCP server-specific troubleshooting, see the Troubleshooting Guide.

Feedback and Support

• Support for this server implementation is primarily provided through community channels and GitHub repositories. Customers with qualifying Microsoft enterprise support agreements may have access to limited support for broader Microsoft Fabric and platform scenarios; review the Microsoft Support Policy section of this project for more details.
• Check the Troubleshooting guide to diagnose and resolve common issues.
• We're building this in the open. Your feedback is much appreciated!
  • Open an issue in the public GitHub repository — we'd love to hear from you!

Security

The Fabric MCP Server is a local-first tool. Its documentation tools provide API specifications, schemas, and best practices without connecting to live Fabric environments. Operational tools, including Get Workspace, make authenticated requests using the server's configured identity and permissions.

core_create-workspace creates a real workspace and can assign it to an existing capacity and domain; review those arguments and use an appropriately authorized identity before invoking it.

core_update-item modifies an existing item's name or description; review its arguments and item permissions before use.

core_delete-workspace can delete a workspace and its items. Review the exact UUID, permissions, and destructive-operation controls before invoking it.

core_assign-workspace-to-capacity is a mutating control-plane operation. Verify both target IDs and permissions before invoking it; acceptance does not confirm completion.

MCP as a phenomenon is very novel and cutting-edge. As with all new technology standards, consider doing a security review to ensure any systems that integrate with MCP servers follow all regulations and standards your system is expected to adhere to.

Data Collection

The software may collect information about you and your use of the software and send it to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may turn off the telemetry as described in the repository. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft's privacy statement. You can learn more about data collection and use in the help documentation and our privacy statement. Your use of the software operates as your consent to these practices.

Contributing

We welcome contributions to the Fabric MCP Server! Whether you're fixing bugs, adding new features, or improving documentation, your contributions are welcome.

Please read our Contributing Guide for guidelines on:

• Setting up your development environment
• Adding new commands
• Code style and testing requirements
• Making pull requests

Code of Conduct

This project has adopted the
Microsoft Open Source Code of Conduct.
For more information, see the
Code of Conduct FAQ
or contact open@microsoft.com
with any additional questions or comments.

License

This project is licensed under the MIT License — see the LICENSE file for details.