MCP Registry

Microsoft Fabric MCP Server

MCP tools for interacting with Microsoft Fabric

Install MCP server

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.

Overview
Installation
- IDE
  - VS Code (Recommended)
  - Manual Setup
  - Getting Started
  - What can you do with the Fabric MCP Server?
    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
    
    The manual configuration examples use mcpServers as the root object. In Visual Studio and Visual Studio Code, use servers instead.
    
    When using the VS Code extension, fabricMcp.enabledServices selects from core, docs, onelake, and datafactory. Leave the list empty to enable all toolsets. If an existing setting contains publicapis, replace it with docs or clear the list; saved settings are not migrated automatically.
    
    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:
    
    Manual setup instructions
    
    Use one of the following options to configure your mcp.json:
    
    Option 1: Configure using the .NET tool (NuGet)
    - Install the .NET 10 SDK or later. Verify it with dotnet --version.
    - Install the published Microsoft.Fabric.Mcp tool:
    dotnet tool install --global Microsoft.Fabric.Mcp --source https://api.nuget.org/v3/index.json
    - Ensure the .NET global tools directory is on the PATH available to your MCP client, then configure mcp.json:
    { "mcpServers": { "Fabric MCP Server": { "command": "fabmcp", "args": [ "server", "start", "--mode", "all" ], "type": "stdio" } } }
    
    Alternatively, .NET 10 supports running the published package on demand with dnx, without a permanent tool installation:
    
    dnx Microsoft.Fabric.Mcp --source https://api.nuget.org/v3/index.json -- server start --mode all
    
    Both commands use the latest published stable package unless you specify a version. To pin a released version, use --version <version> with dotnet tool install, or Microsoft.Fabric.Mcp@<version> with dnx.
    
    Option 2: Configure using Node.js (npm/npx)
    - Install a supported Node.js LTS version 22.0.0 or later, with npm and npx available on your system PATH. Verify your installation with node --version, npm --version, and npx --version.
    - Configure the mcp.json file with the following:
    { "mcpServers": { "fabric-mcp-server": { "command": "npx", "args": [ "-y", "@microsoft/fabric-mcp@latest", "server", "start", "--mode", "all" ] } } }
    
    Build from source (contributors)
    
    Building the repository is a separate development workflow, not required to use the published packages:
    
    git clone https://github.com/microsoft/mcp.git cd mcp dotnet build servers/Fabric.Mcp.Server/src/Fabric.Mcp.Server.csproj --configuration Release
    
    Use the built servers/Fabric.Mcp.Server/src/bin/Release/fabmcp executable as your MCP client's command, with ["server", "start", "--mode", "all"] as its arguments. On Windows, use backslashes and the .exe extension.
    
    Client-Specific Configuration
    - File Location
      - Claude Code: ~/.claude.json or .mcp.json (project)
      - Claude Desktop: ~/.claude/claude_desktop_config.json (macOS) %APPDATA%\Claude\claude_desktop_config.json (Windows)
      - Cursor: ~/.cursor/mcp.json or .cursor/mcp.json
      - VS Code: .vscode/mcp.json (workspace) settings.json (user)
      - Windsurf: ~/.codeium/windsurf/mcp_config.json
      - Claude Code: Claude Code MCP Configuration
      - Claude Desktop: Claude Desktop MCP Setup
      - Cursor: Cursor MCP Documentation
      - VS Code: VS Code MCP Documentation
      - Windsurf: Windsurf Cascade MCP Integration
      Docker
      
      The published container image is available from Microsoft Container Registry as mcr.microsoft.com/fabric/fabric-mcp. Use Docker with Linux containers. The latest tag selects the most recently published image; when pinning a version, choose a tag that already exists in the registry.
      
      The container does not inherit your host's az login session. For operational tools, configure an identity supported by the Fabric APIs you intend to call and grant it the required Fabric permissions. For example, supply a service principal using a local environment file stored outside your repository:
      AZURE_TENANT_ID=<tenant-id> AZURE_CLIENT_ID=<client-id> AZURE_CLIENT_SECRET=<client-secret> AZURE_TOKEN_CREDENTIALS=EnvironmentCredential
      Never commit this file or put its secret values in mcp.json. See environment credential options for other supported credential settings.
      
      Configure your MCP client, replacing the environment-file placeholder with an absolute path:
      
      { "mcpServers": { "fabric-mcp-server": { "command": "docker", "args": [ "run", "--rm", "-i", "--env-file", "", "mcr.microsoft.com/fabric/fabric-mcp:latest", "--mode", "all" ] } } }
      
      Keep stdin open with -i, without allocating a TTY. The image entrypoint already runs server start; do not repeat those arguments after the image name.
      
      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 "
      - "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."
      - Required
        
        workspace-id: Yes
        
        prefer-workspace-specific-endpoints: No
        
        Description
        
        workspace-id: Nonempty workspace UUID, not a name or URL. Accepted UUID representations are normalized before the request.
        
        prefer-workspace-specific-endpoints: Boolean endpoint preference. Omit to preserve the service default, or explicitly pass true or false.
        
        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 four toolsets: core, docs, onelake, and datafactory.
        
        API Documentation & Best Practices
        
        Description
        
        docs_list-item-types: Lists the Fabric item types that have public API specifications available, plus the non-item API areas (platform, admin, spark, realTimeIntelligence).
        
        docs_item-api-spec: Retrieves the complete OpenAPI specification for a specific Fabric item type.
        
        docs_platform-api-spec: Retrieves the OpenAPI specification for core Fabric platform APIs.
        
        docs_item-definitions: Retrieves the JSON schema definition for a Fabric item type.
        
        docs_best-practices: Retrieves best practice documentation and guidance for a specific topic.
        
        docs_api-examples: Retrieves example API request/response files for a specific item type.
        
        OneLake Data Operations
        
        Description
        
        onelake_list-workspaces: Lists available Microsoft Fabric workspaces.
        
        onelake_list-items: Lists workspace items with high-level metadata.
        
        onelake_list-items-dfs: Lists Fabric items via the DFS endpoint.
        
        onelake_list-files: Lists files using the hierarchical file-list endpoint.
        
        onelake_download-file: Downloads a OneLake file.
        
        onelake_upload-file: Uploads a file to OneLake storage.
        
        onelake_delete-file: Deletes a file from OneLake storage.
        
        onelake_create-directory: Creates a directory via the DFS endpoint.
        
        onelake_delete-directory: Deletes a directory (optionally recursive).
        
        onelake_get-table-config: Retrieves table API configuration for a workspace item.
        
        onelake_list-table-namespaces: Lists table namespaces (schemas) exposed through the table API.
        
        onelake_get-table-namespace: Retrieves metadata for a specific namespace.
        
        onelake_list-tables: Lists tables published within a namespace.
        
        onelake_get-table: Retrieves the definition for a specific table.
        
        OneLake Security — Data Access Roles
        
        Description
        
        onelake_list-data-access-roles: Lists all data access roles defined on a single item.
        
        onelake_get-data-access-role: Gets the full definition of a single data access role (members, permissions, decision rules).
        
        onelake_create-or-update-data-access-role: Upserts a single data access role on a single item.
        
        onelake_delete-data-access-role: Deletes a single data access role from an item.
        
        OneLake Shortcuts
        
        Description
        
        onelake_list-shortcuts: Lists shortcuts defined within an item. Hides DW-managed shortcuts by default (--include-managed to show).
        
        onelake_get-shortcut: Gets the properties of a single shortcut.
        
        onelake_create-shortcut-onelake: Creates a shortcut pointing to another OneLake location.
        
        onelake_create-shortcut-adls-gen2: Creates a shortcut pointing to Azure Data Lake Storage Gen2.
        
        onelake_create-shortcut-amazon-s3: Creates a shortcut pointing to Amazon S3.
        
        onelake_create-shortcut-azure-blob: Creates a shortcut pointing to Azure Blob Storage.
        
        onelake_create-shortcut-gcs: Creates a shortcut pointing to Google Cloud Storage.
        
        onelake_create-shortcut-s3-compatible: Creates a shortcut pointing to S3-compatible storage.
        
        onelake_create-shortcut-dataverse: Creates a shortcut pointing to a Dataverse environment.
        
        onelake_create-shortcut-onedrive-sharepoint: Creates a shortcut pointing to OneDrive/SharePoint Online.
        
        onelake_delete-shortcut: Deletes a single shortcut from an item (preserves destination data).
        
        onelake_reset-shortcut-cache: Drops cached shortcut reads, forcing re-resolution from destination.
        
        OneLake Settings
        
        Description
        
        onelake_get-settings: Gets OneLake settings for a workspace (diagnostics + immutability policy).
        
        onelake_modify-diagnostics: Modifies diagnostic logging configuration (status, destination lakehouse) at workspace scope.
        
        onelake_modify-immutability-policy: Modifies the workspace-level OneLake immutability policy (scope, retention days).
        
        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.
        
        Description
        
        core_assign-workspace-to-capacity: Submits one request to assign an existing workspace to a capacity. Returns an accepted/pending receipt, not confirmation of completion.
        
        core_create-item: Creates a Fabric item by workspace UUID, optionally with a definition or creation payload, an existing folder ID, definition options, and label settings. Returns completed metadata or an accepted operation receipt; optionally waits within a bounded budget.
        
        core_create-workspace: Creates a Fabric workspace, optionally assigning an existing capacity and domain in the same request.
        
        core_delete-item: Deletes one known Fabric item using workspace and item UUIDs. Permanent deletion requires explicitly setting hard-delete to true.
        
        core_delete-workspace: Deletes one explicitly identified Fabric workspace and the items under it. Requires a workspace UUID and workspace Admin access.
        
        core_get-capacity: Gets one Fabric capacity's ID, display name, SKU, region, and state using its capacity UUID.
        
        core_get-item: Gets generic metadata for one existing Fabric item using its workspace ID and item ID. Does not read item data or definitions.
        
        core_get-item-definition: Retrieves typed definition parts inline, optionally waits for completion, or resumes a completed definition operation. Can explicitly export to a new local directory without overwriting files.
        
        core_get-operation-result: Reads one completed operation's JSON or empty result, up to 1 MiB. Binary results are unsupported.
        
        core_get-operation-state: Reads one operation's current state and polling guidance, without polling or resubmitting the original request.
        
        core_get-workspace: Gets one workspace's metadata by UUID, including optional capacity, domain, identity, tags, and endpoints. Does not read item data or modify resources.
        
        core_list-capacities: Lists one page of accessible Fabric capacity metadata: ID, display name, SKU, region, and state, plus available continuation information.
        
        core_list-items: Lists one page of Fabric Core item metadata in a known workspace or folder, with optional type filtering and continuation information.
        
        core_list-workspaces: Lists one page of accessible workspace management metadata, optionally filtered by the caller's workspace roles. Returns continuation information and can request workspace-specific API endpoints.
        
        core_search-catalog: Searches one page of OneLake catalog metadata across workspaces. Continue with the returned token without repeating search or filter.
        
        core_update-item: Updates an existing item's display name or description and returns metadata only.
        
        core_update-item-definition: Replaces a known item's complete definition from inline content or explicitly selected saved files. Optionally applies supplied .platform metadata and waits for a no-result operation.
        
        core_update-workspace: Renames a workspace or updates or clears its description by UUID, leaving omitted properties unchanged. Requires workspace Admin access.
        
        Create Item (core_create-item)
        
        Calls the Create Item API once with display-name, item-type, and the optional request properties described below. 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. Omitting the optional properties preserves the existing no-definition request; the tool never invents request fields or defaults.
        
        Optional creation properties
        
        All four options below are available locally and over HTTP:
        
        Request property
        
        folder-id: folderId
        
        creation-payload: creationPayload
        
        options: options
        
        sensitivity-label-settings: sensitivityLabelSettings
        
        folder-id: Nonempty UUID of an existing folder in this workspace. Passed directly and normalized as a UUID, without a lookup or folder creation. Omit to use the workspace root.
        
        creation-payload: Item-specific properties as a JSON object string, not a file path or a full create-request body. Mutually exclusive with every inline or saved-file definition option. Consult the item's Create API for supported properties.
        
        options: Item-specific settings as a JSON object string. Requires a definition source; cannot accompany creation payload alone. Consult the item's Update Definition API for supported options. This is the request's top-level options, not LRO wait settings.
        
        sensitivity-label-settings: Optional typed JSON object string. When supplied, labelId is required and must be a nonempty UUID. sensitivityLabelApplyStrategy is optional; a supplied value must be exactly ApplyOrFail or Ignore.
        
        creation-payload and options each allow at most 1 MiB (1,048,576 UTF-8 bytes) and 32 JSON nesting levels. sensitivity-label-settings allows at most 4,096 UTF-8 bytes. These are host input limits, not Fabric API quotas. Non-object JSON, malformed input, duplicate properties (including nested properties), and repeated occurrences of these CLI options are rejected before reading definition files or contacting Fabric. Workload property names and values, including explicit nulls, false values, and empty objects, are otherwise passed through unchanged; Fabric validates their per-item meaning. Unknown label-setting fields are errors rather than silently ignored.
        
        When the whole label-settings object or its optional strategy is omitted, it stays omitted. A supplied object must contain a nonempty labelId; {} and strategy-only settings are rejected before file access, authentication, or the creation request. Fabric's documented default for an omitted strategy is ApplyOrFail; the tool does not insert a value. Explicit Ignore permits Fabric to proceed without applying the label if it cannot be applied, so select it only when that policy is intended. Explicit null/invalid IDs or strategies are rejected; omit the entire settings object when no label is requested. A label-related failure never causes a retry without the label, a fallback to Ignore, or another creation request.
        
        For example, the documented Lakehouse creation payload can enable schemas. This example creates a real item in an existing folder and requests a label with the strict policy:
        
        fabmcp core create-item --workspace-id cfafbeb1-8037-4d0c-896e-a46fb27ff229 --display-name "Sales" --item-type Lakehouse ` --folder-id bbbbbbbb-1111-2222-3333-cccccccccccc ` --creation-payload '{"enableSchemas":true}' ` --sensitivity-label-settings '{"labelId":"b7b4f4d9-3f0d-4b3e-8f3d-4f6d3f4f3f4f","sensitivityLabelApplyStrategy":"ApplyOrFail"}'
        
        For definition-based creation, pass supported item-specific settings through --options alongside either definition source below. Keep sync, max-wait-seconds, and early-poll as separate tool arguments. Folder IDs, labels, and workload properties do not trigger resource lookups, preflight calls, or metadata read-backs.
        
        Optional item definition input
        
        Choose exactly one source when supplying a definition:
        
        Arguments
        
        Inline content: definition: a JSON string containing parts and optional format, not a path or a complete create-request body
        
        Saved files: definition-directory: an existing absolute local directory; definition-files: a JSON string containing an explicit array of { "partPath": "...", "sourcePath": "..." }; optional definition-format
        
        Inline content: Local CLI, stdio, and HTTP
        
        Saved files: Local CLI and stdio only
        
        Every inline part must supply path, Base64 payload, and payloadType: "InlineBase64". definition-format applies only to saved files; for inline content put format inside the JSON. Neither source can be combined with creation-payload. Conflicting sources, incomplete selections, repeated definition options, malformed JSON, unknown definition-envelope fields, and duplicate JSON fields are errors, never silently preferred or dropped. Over HTTP, file options are omitted from discovery and rejected on invocation; the Fabric input service also checks its local-file capability before any filesystem access. The existing remote-capable tool remains available for inline, creation-payload, and no-definition creation.
        
        For a saved notebook, first save changes in your editor. This example reads only sales.ipynb from the selected directory and maps it to the Fabric part path without renaming the source file:
        
        fabmcp core create-item --workspace-id cfafbeb1-8037-4d0c-896e-a46fb27ff229 --display-name "Sales notebook" --item-type Notebook ` --definition-directory 'C:\Fabric\Sales.Notebook' ` --definition-files '[{"partPath":"artifact.content.ipynb","sourcePath":"sales.ipynb"}]' ` --definition-format ipynb
        
        sourcePath defaults to partPath. Both are relative to the selected directory; logical partPath values use / separators. List every part you intend to upload, including nested model/report parts, binary assets, and optional .platform where appropriate. There is no recursive scan, wildcard expansion, or automatic inclusion of editor state, caches, secrets, or even .platform. Explicitly selected files are uploaded, so review that selection. Files come from the MCP host, not a remote client's filesystem, Git HEAD, or unsaved editor buffers. Save and stop editing while packaging; this is not an atomic snapshot of concurrent edits.
        
        For content already supplied directly, including to a remote HTTP server:
        
        $definition = @{ format = 'ipynb' parts = @(@{ path = 'artifact.content.ipynb' payload = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('{"nbformat":4,"nbformat_minor":5,"cells":[],"metadata":{}}')) payloadType = 'InlineBase64' }) } | ConvertTo-Json -Depth 4 -Compress fabmcp core create-item --workspace-id cfafbeb1-8037-4d0c-896e-a46fb27ff229 --display-name "Empty notebook" --item-type Notebook --definition $definition
        
        These are alternative real item creation examples, not validation-only operations. Definition preparation performs no Fabric requests; after preparation there is still only one initiating POST /workspaces/{workspaceId}/items. There are no workspace/name lookups, dependency creation, preflight calls, or metadata read-backs. The existing sync/polling options below work with either source.
        
        Both sources share host packaging limits: by default 1,024 parts, 16 MiB decoded per part, and 32 MiB decoded total, plus encoded-payload and input-JSON bounds. These are local safeguards, not Fabric API quotas. Portable logical paths reject traversal, absolute paths, duplicate names (case-insensitively), and file/directory collisions. Saved-file input additionally rejects linked/junction paths and UNC/device paths. Selected bytes, encodings, line endings, and empty files are preserved. Filesystem checks require a trusted local filesystem; they are not an OS sandbox against concurrent hostile file replacement.
        
        Fabric validates item-specific layouts and content. The tool does not require particular filenames, notebook language files, or format-specific part combinations, even for recognized formats or when format is omitted. Safe part names, supplied format strings, and payload content are forwarded unchanged; an omitted format stays omitted so Fabric applies its defaults. The generic JSON/Base64/envelope checks, byte/count/depth limits, API/source exclusivity, UUID checks, and filesystem/HTTP safeguards above still apply before submission.
        
        Use the bundled item-definition articles through docs_item-definitions to prepare a complete definition. They are documentation for callers, not executable schemas or a local layout-validation policy. Fabric remains authoritative for supported item types/formats, required parts, content schemas, format combinations, and dependency/binding correctness. The tool does not rewrite report bindings, interpret .platform, or create referenced resources.
        
        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.
        
        Default
        
        sync: false
        
        max-wait-seconds: 120
        
        early-poll: true
        
        sync: False sends one POST and returns completed metadata or an accepted receipt, with zero follow-up reads. True asynchronously waits after 202 and retrieves the created item when available. It does not use blocking HTTP I/O.
        
        max-wait-seconds: Finite positive local wait budget after 202, up to 600 seconds (10 minutes) inclusive. Fractional seconds are allowed. Includes delays, authentication, and in-flight status/result reads. Larger values are rejected, not clamped, before submitting creation, even when sync=false.
        
        early-poll: Allows one first status probe after at most 3 seconds, or sooner if the initial server hint is shorter. False honors the initial validated Retry-After instead.
        
        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.
        
        Command status and payload
        
        Immediate 201 completion: HTTP 200 command response with results.item, preserving the existing completed shape.
        
        Accepted or wait budget expired while unconfirmed: HTTP 202 with operation.status Accepted or Pending; lastState is included only after a state read. Acceptance does not invent Running.
        
        Accepted without a usable x-ms-operation-id: HTTP 202 with AcceptedWithoutOperationId and an explicit issue. Check whether creation occurred; do not automatically resubmit. Location is not used to recover a missing ID.
        
        Wait observes Succeeded and retrieves valid item metadata: HTTP 200 with item and a Succeeded operation receipt.
        
        Wait observes Failed: HTTP 502 with a Failed receipt and safe operation error details. No result fetch or new POST is attempted.
        
        A state read fails: A sanitized error with a TrackingStopped receipt, preserving the ID and last-known state; this is not evidence that Fabric's operation failed.
        
        Operation succeeded but the result was not retrieved: ResultUnavailable, preserving lastState.status=Succeeded when observed. Budget expiry returns HTTP 202; read/validation failures retain their error status. Do not recreate the item.
        
        Caller cancels a post-acceptance wait: HTTP 408 with a receipt when the client can still receive it, distinguishing caller cancellation from budget expiry. Confirmed completion is not downgraded to running.
        
        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.
        
        Update Item Definition (core_update-item-definition)
        
        Calls Update Item Definition
        with one POST /workspaces/{workspaceId}/items/{itemId}/updateDefinition. Both workspace-id and
        item-id are required nonempty UUIDs. This is a complete replacement, not a changed-files patch:
        provide all required definition parts, not just the files edited since the last upload. The tool
        never fetches the old definition, merges parts, resolves names, downloads schemas, creates dependencies,
        or performs a metadata read-back.
        
        Exactly one definition source is required, reusing Create Item's input and file infrastructure:
        
        Arguments
        
        Inline: definition: JSON object string with parts and optional format
        
        Saved files: definition-directory: existing absolute directory; definition-files: explicit JSON array string of partPath and optional sourcePath; optional definition-format
        
        Inline: Local CLI, stdio, and HTTP
        
        Saved files: Local CLI and stdio only
        
        The same portable-path, strict JSON, Base64, byte/count, and local-file safeguards described above
        apply. Saved files come from the MCP hosting machine, not a remote client's filesystem or unsaved
        editor buffers. Save changes and explicitly list every part; no folder scan, wildcard, automatic
        .platform inclusion, or source-file modification occurs. Over HTTP, filesystem options are hidden
        and rejected. The input service independently rechecks local-file capability before any filesystem
        access, while inline updates remain available.
        
        Validation is generic and content-independent: it does not enforce item-type or format-specific
        filenames, required parts, or layout combinations. The supplied format, portable part paths, and
        payload bytes pass through unchanged for default, known, and future formats. There is no item-type
        hint, .platform interpretation, metadata preflight, or local completeness claim. Consult
        docs_item-definitions for the bundled reference and supply a complete definition; Fabric validates
        supported formats, required parts, content, and bindings.
        
        options supplies the API's optional top-level item-specific JSON object string. It is limited
        to 1 MiB of UTF-8 input and 32 nesting levels, rejects duplicate properties at any depth, and
        is validated before file reads. Omitted options stay omitted; {}, false values, null members,
        and future workload properties are preserved. Fabric validates supported properties for the
        actual item type. These options never control polling.
        
        update-metadata requires an explicit Boolean value. Omission leaves the query parameter omitted;
        false sends ?updateMetadata=false; only explicit true requests applying metadata from a
        supplied .platform part. The part's bytes are always preserved: the tool does not remove it
        when metadata application is disabled, add it when absent, or rewrite its contents or bindings.
        The flag can be sent without a .platform part; it does not cause the tool to invent metadata.
        This API does not change the sensitivity label. There are no sensitivity-label-settings,
        folder-id, creation-payload, display-name, or description arguments on this tool.
        
        This example replaces a real item's definition when run with authorized credentials. Review
        the complete file selection first. It includes .platform without opting into metadata application:
        
        fabmcp core update-item-definition ` --workspace-id cfafbeb1-8037-4d0c-896e-a46fb27ff229 --item-id 5b218778-e7a5-4d73-8187-f10824047715 ` --definition-directory 'C:\Fabric\Sales.Notebook' ` --definition-files '[{"partPath":"artifact.content.ipynb","sourcePath":"sales.ipynb"},{"partPath":".platform"}]' ` --definition-format ipynb --sync true --max-wait-seconds 120
        
        For inline content, supply --definition $definition instead of all three filesystem options,
        using a complete definition JSON string like the Create Item example above. Add
        --update-metadata true only when the supplied .platform metadata should also be applied.
        
        A documented empty HTTP 200 returns results.operation.status=Succeeded immediately, in either
        sync mode. A 202 returns an Accepted receipt without polling by default. With sync=true,
        the shared runner polls operation state only; confirmed Succeeded finishes without a
        /result or Get Item request because this endpoint has no result body. Its result contains only
        the operation receipt, never echoed definitions, options, paths, or fabricated item metadata.
        
        max-wait-seconds defaults to 120 and allows positive finite values up to 600 seconds, including
        fractions. early-poll defaults to true; the shared initial early-probe and subsequent Retry-After
        rules above apply. Only status GETs may be retried on 429/503; the initiating POST is never retried.
        Budget expiry returns HTTP 202 with Pending and last-known state. A reported failure returns a
        safe Failed receipt; read failures preserve a TrackingStopped receipt. Caller cancellation
        stops only local waiting and preserves a known receipt when the client can still receive it.
        Resume a pending update with core_get-operation-state and stop at Succeeded: do not call
        core_get-operation-result or resubmit the update to extend a wait. Missing operation IDs,
        unexpected success codes/bodies, and transport failures are surfaced without assuming success or
        following response URLs.
        
        Read and write item permissions are required. Delegated callers need Item.ReadWrite.All
        or the appropriate item-specific ReadWrite.All scope. Service-principal and managed-identity
        support depends on item type. Development coverage uses substituted HTTP and credentials; it
        does not authorize live updates or establish actual OBO permissions or recorded playback.
        
        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. For a completed Get Item Definition operation, use core_get-item-definition with operation-id instead: its typed definition reader has its own larger bound and optional local export.
        
        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 ''
        
        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 Item Definition (core_get-item-definition)
        
        Calls the Get Item Definition API
        with one POST /workspaces/{workspaceId}/items/{itemId}/getDefinition. For an initial request, supply
        both workspace-id and item-id as nonempty UUIDs. Optional format must not be empty or whitespace
        and allows at most 128 characters without control characters, encoded as one query value. Omit it to use the item's
        default; the tool does not look up item metadata, resolve names, download schemas or individual parts,
        or create/update any item.
        
        Inline content only; a 202 response returns an operation receipt without polling.
        
        fabmcp core get-item-definition --workspace-id cfafbeb1-8037-4d0c-896e-a46fb27ff229 --item-id 5b218778-e7a5-4d73-8187-f10824047715 --format ipynb
        
        Only the documented 200 completed definition and 202 accepted receipt are supported.
        Completed output contains a typed definition with parts (path, payload, payloadType) and
        format only when Fabric actually returned one. Payloads remain Base64 for inline use. No item type
        is required and no item-specific filename, layout, or format-combination rules are imposed on returned content.
        The bundled item-definition articles remain useful editing references through docs_item-definitions,
        not runtime schemas. Sensitivity labels are not included in the definition.
        
        sync defaults to false. With sync=true, the existing LRO runner polls state and retrieves the
        definition after success. max-wait-seconds defaults to 120, accepts positive finite fractional
        values, and has a 600-second maximum. early-poll defaults to true, allowing one initial probe
        after at most three seconds; set it to false to honor the initial server hint. Later polls and
        429/503 read retries honor validated hints. There is no automatic resubmission of the initial POST.
        
        Explicit local export
        
        Supply output-directory only when files are wanted. It must name a new absolute local directory
        below an existing parent. The existing definition file service preserves every returned part's
        bytes, encodings, line endings, relative path, binary assets, empty payloads, and .platform.
        It writes a temporary sibling directory and publishes only the completed directory; existing files
        and directories are never overwritten, merged, or deleted. Export errors and cancellation do not
        fall back to inline success or claim that a partial definition was saved.
        
        C:\Fabric already exists; Sales.Notebook must not exist.
        
        fabmcp core get-item-definition --workspace-id cfafbeb1-8037-4d0c-896e-a46fb27ff229 --item-id 5b218778-e7a5-4d73-8187-f10824047715 ` --format ipynb --sync true --output-directory 'C:\Fabric\Sales.Notebook'
        
        On completed export, the result still includes definition and adds the published outputDirectory.
        Keep any returned format when packaging edited files later; the tool does not invent a format or
        write an extra manifest. Omission of output-directory means no filesystem access or output.
        The option is hidden and rejected over HTTP, and a separate service-level capability check rejects
        file access even when command-schema checks are bypassed. File paths are on the local MCP host,
        not the remote client's machine. Linked/junction, UNC/device, and unsafe part paths are rejected.
        These checks assume a trusted local filesystem, not an OS sandbox against concurrent hostile changes.
        
        Resuming without restarting
        
        Acceptance, local wait expiry, and failed tracking never imply a saved definition. A receipt retains
        its operation ID and last-known state when available; no background poller or file writer continues
        after the call ends. Caller cancellation stops local waiting, not the Fabric operation.
        Check state using the receipt, respecting its polling guidance. When state is Succeeded, select
        the tool's mutually exclusive resume mode:
        
        fabmcp core get-operation-state --operation-id 0acd697c-1550-43cd-b998-91bfbfbd47c6
        
        Only after Succeeded; omit output-directory to retrieve inline content instead.
        
        fabmcp core get-item-definition --operation-id 0acd697c-1550-43cd-b998-91bfbfbd47c6 --output-directory 'C:\Fabric\Sales.Notebook'
        
        Resume sends exactly one GET to /operations/{operationId}/result, without a state preflight,
        polling, or another POST. Do not combine operation-id with workspace/item IDs, format, or
        sync=true. The result endpoint does not identify its source item; use an operation ID retained
        from the intended Get Item Definition request, rather than assuming item provenance was verified.
        Only returned format information is preserved. A missing, malformed, not-ready, or oversized result
        is an explicit error. If Fabric reports success but result retrieval fails, the receipt preserves
        completion and the operation ID without pretending that the definition was retrieved or exported.
        
        Bounds, permissions, and metadata
        
        Definition JSON has a separate 64 MiB (67,108,864 byte) wire limit, also enforced for streams
        without Content-Length. The existing Create Item, state, and generic operation-result limits stay
        at 1 MiB. Generic definition validation requires a nonempty part list, unique portable paths
        without file/directory collisions, valid InlineBase64, and the shared host budgets (defaults:
        1,024 parts, 16 MiB decoded per part, 32 MiB decoded total). Invalid or oversized content is
        rejected before export, never truncated or silently skipped. These are host safeguards, not Fabric quotas.
        
        Fabric requires read AND write item permissions, plus Item.ReadWrite.All or the item-specific
        ReadWrite.All delegated scope. Service-principal and managed-identity support depends on item type.
        Encrypted sensitivity labels can require additional usage rights. Returning definition contents can
        expose sensitive code or configuration, so the tool advertises Secret=true and uses the existing
        MCP consent flow; clients without elicitation support are rejected by default. It remains remote-capable
        for inline results (LocalRequired=false). Because it can optionally write local files, it conservatively
        advertises ReadOnly=false and is excluded from read-only server mode in every transport, even
        when no export was requested. No-overwrite export is non-destructive and repeated calls cannot replace
        existing files. Errors omit raw backend bodies, definition contents, and filesystem details.
        
        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.
        
        Behavior
        
        --roles: Comma-separated Admin, Member, Contributor, or Viewer roles for the calling principal. Case and surrounding whitespace are normalized; duplicate roles are removed. Unknown roles and empty entries are rejected. Omit for no role filter.
        
        --continuation-token: Token returned by the preceding page. Pass it unchanged, including any percent escapes, and repeat the same roles and endpoint preference. Omit for the first page. Empty or whitespace-only tokens are rejected.
        
        --prefer-workspace-specific-endpoints: Set true to request each workspace's apiEndpoint metadata, or false to exclude it. Omission preserves the API default. Returned endpoints are not contacted by this tool.
        
        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 ''
        
        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).
        
        Required
        
        workspace-id: Yes
        
        type: No
        
        recursive: No
        
        root-folder-id: No
        
        continuation-token: No
        
        workspace-id: Nonempty workspace UUID; workspace names are not resolved.
        
        type: Fabric item type, such as Lakehouse or Notebook. Omit for all types. New service-defined types are accepted without a client-side enum restriction.
        
        recursive: Defaults to true, including nested folders. Set false for direct items only.
        
        root-folder-id: Nonempty folder UUID. Omit to use the workspace root.
        
        continuation-token: Token from a previous response, copied unchanged. Keep the same workspace and filters.
        
        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.
        
        Required
        
        display-name: Yes
        
        description: No
        
        capacity-id: No
        
        domain-id: No
        
        display-name: Workspace display name, not empty or whitespace, at most 256 characters. Only unused names are allowed. Admin monitoring is reserved, including case variations and surrounding whitespace.
        
        description: At most 4000 characters. An explicitly empty string is preserved.
        
        capacity-id: Nonempty UUID of an existing capacity to assign during creation. Names are not resolved.
        
        domain-id: Nonempty UUID of an existing domain to assign during creation. Names are not resolved.
        
        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 "" ` --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 to 'Finance Analytics' without changing its description"
        
        "Set the description of Fabric workspace to 'Quarterly reporting' without renaming it"
        
        "Clear the description of Fabric workspace 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:
        
        Behavior
        
        workspace-id: Required workspace UUID; names and name resolution are not supported.
        
        display-name: Optional name, up to 256 characters; cannot be empty or whitespace-only. Names must be unique within the tenant; Admin monitoring is reserved.
        
        description: Optional description, up to 4000 characters. An empty string clears it.
        
        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": "", "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.
        
        Required
        
        workspace-id: Yes
        
        item-id: Yes
        
        hard-delete: No
        
        workspace-id: Nonempty UUID of the workspace containing the item.
        
        item-id: Nonempty UUID of the item to delete.
        
        hard-delete: Omit to leave the API parameter unspecified, explicitly pass false to send hardDelete=false, or explicitly pass true to request permanent deletion.
        
        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 "" --item-id ""
        
        Explicitly do not request permanent deletion.
        
        fabmcp core delete-item --workspace-id "" --item-id "" --hard-delete false
        
        Explicitly request irreversible permanent deletion.
        
        fabmcp core delete-item --workspace-id "" --item-id "" --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.
        
        Warning
        
        Deleting a workspace also deletes the items under it. Verify the exact workspace UUID and obtain authorization for that specific deletion before invoking this tool. No recovery, retention, or permanent-deletion semantics are promised by this tool.
        
        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 to capacity ; 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
        
        Description
        
        datafactory_list-pipelines: Lists all pipelines in a Microsoft Fabric workspace.
        
        datafactory_create-pipeline: Creates a new pipeline in a workspace.
        
        datafactory_get-pipeline: Gets details of a specific pipeline.
        
        datafactory_run-pipeline: Runs a pipeline on demand.
        
        datafactory_list-dataflows: Lists all Dataflow Gen2 items in a workspace.
        
        datafactory_create-dataflow: Creates a new Dataflow Gen2 item.
        
        datafactory_execute-query: Executes an M (Power Query) query against a dataflow.
        
        Always verify available commands via --help. Command names and availability may change between releases.

MCP Registry

Microsoft Fabric MCP Server

Table of Contents

Overview

Installation

IDE

VS Code (Recommended)

Manual Setup

Option 1: Configure using the .NET tool (NuGet)

Option 2: Configure using Node.js (npm/npx)

Build from source (contributors)

Docker

Usage

Getting Started

What can you do with the Fabric MCP Server?

Capacity Discovery

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

Only after the state says Succeeded:

Initial page.

Next page: copy the token unchanged; do not repeat search or filter.

Inline content only; a 202 response returns an operation receipt without polling.

C:\Fabric already exists; Sales.Notebook must not exist.

Only after Succeeded; omit output-directory to retrieve inline content instead.

First page of all workspace items, including nested folders.

Direct Lakehouses in one folder, excluding its nested folders.

Delete a Fabric item

Default API deletion behavior; recovery is not guaranteed.

Explicitly do not request permanent deletion.

Explicitly request irreversible permanent deletion.

Data Factory Operations