Add Data Factory tools to Fabric MCP Server

[Ebram-Tawfik]

Summary

Adds Data Factory pipeline and dataflow management tools to the Fabric MCP Server, consuming the shared handler layer from the Microsoft.DataFactory.MCP.Core NuGet package.

New Commands

Command	Description
list-pipelines	List all pipelines in a workspace
create-pipeline	Create a new pipeline
get-pipeline	Get pipeline details by ID
run-pipeline	Trigger a pipeline run
list-dataflows	List all dataflows in a workspace
create-dataflow	Create a new dataflow
execute-query	Execute an M (Power Query) expression against a dataflow

Architecture

• Thin GlobalCommand<T> wrappers following existing Fabric MCP patterns
• Business logic delegated to PipelineHandler / DataflowHandler / DataflowQueryHandler from the NuGet Core package
• Registered via DataFactoryAreaSetup : IAreaSetup in Program.cs
• AOT-compatible with custom JsonSerializerContext

Changes

• New project: tools/Fabric.Mcp.Tools.DataFactory/ — 7 commands, options, models, area setup
• Program.cs: Register DataFactoryAreaSetup in area list
• Fabric.Mcp.Server.slnx: Add project to solution
• Directory.Packages.props: Add Microsoft.DataFactory.MCP.Core version entry (0.20.0-beta)
• Cleanup: Removed submodule (replaced by NuGet package reference)

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds the DataFactory.MCP.Core submodule and wires it into Fabric.Mcp.Server as a project reference, along with centrally-managed package versions required to build the integrated dependency.

Changes:

• Add DataFactory.MCP.Core project reference to Fabric.Mcp.Server
• Add external/DataFactory.MCP git submodule configuration (pinned commit + .gitmodules)
• Add missing central package versions needed by DataFactory.MCP.Core

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
servers/Fabric.Mcp.Server/src/Fabric.Mcp.Server.csproj	Adds a project reference to the DataFactory MCP core project in the new submodule
external/DataFactory.MCP	Pins the submodule to a specific commit for reproducible builds
Directory.Packages.props	Adds central package versions required by the submodule project
.gitmodules	Registers the DataFactory.MCP Git submodule source and path

[github-actions]

Thank you for your contribution @Ebram-Tawfik! We will review the pull request and get back to you soon.

[jongio]

This PR introduces a git submodule to pull in DataFactory.MCP.Core. I have a few concerns that need to be addressed before merging.

CI will break: The build pipeline (eng/pipelines/templates/jobs/build.yml) uses checkout: self without submodules: recursive. Once merged, Fabric.Mcp.Server builds will fail because external/DataFactory.MCP won't exist in CI. The CONTRIBUTING.md update is helpful for local dev, but CI needs the equivalent configuration.

AOT compatibility: DataFactory.MCP.Core doesn't set IsAotCompatible=true. Fabric.Mcp.Server enables AOT/Trim analyzers with TreatWarningsAsErrors=true. Referencing a project without AOT annotations will likely produce analyzer warnings that become build-breaking errors.

Submodule vs NuGet package: Git submodules are fragile in practice - they break git clone without --recurse-submodules, complicate CI checkout steps, create merge conflicts on pointer updates, and confuse contributors. The conventional .NET approach is publishing DataFactory.MCP.Core as a NuGet package (internal feed works fine) and adding a PackageReference. This sidesteps the AOT/build-props conflicts entirely since the package arrives pre-compiled.

Dead code until follow-up: The project reference compiles DataFactory.MCP.Core into the binary (including Apache.Arrow and embedded HTML/CSS/JS resources) but nothing registers its tools via IAreaSetup. The server grows for zero functional benefit right now. Consider combining this with the registration PR so each merge leaves the server in a working incremental state.

I'd suggest either switching to a NuGet package reference, or at minimum addressing the CI and AOT issues first. Happy to discuss tradeoffs.

[Copilot]

Pull request overview

Copilot reviewed 23 out of 23 changed files in this pull request and generated 10 comments.

[jongio]

Addresses my previous feedback. The switch from submodule to NuGet package is the right call - CI is green across all 15 checks and the build story is much simpler.

Commands follow Fabric toolset patterns: sealed classes, primary constructors, CommandMetadata, proper option binding. Area setup registers all 7 commands correctly.

Follow-up items (non-blocking):

• Unit tests cover constructor, metadata, options, and null guards but don't test ExecuteAsync paths. Other Fabric toolsets (OneLake) include execution success/error tests. Worth adding in a subsequent PR.

• ExecuteQueryCommandResult.Data is typed as object?, which is tricky for source-generated System.Text.Json under AOT. Native builds pass today, but if the handler returns complex types, serialization could fail at runtime. Worth watching.