foundry-copilot-mcp

Bring a Microsoft Foundry agent — and your Power BI semantic models — into GitHub Copilot Chat, over MCP.

Your agent already works in the Foundry playground. Your analysts already live in VS Code. This is the ~400 lines of glue in between, written to be read: three bridges, each one small enough to hold in your head.

<picture> <source media="(prefers-color-scheme: dark)" srcset="docs/img/architecture-dark.svg"> <img alt="VS Code Copilot Chat talks over MCP to this server, which bridges to Microsoft Foundry, to Microsoft's Power BI modeling MCP server, and to the Fabric REST API. Every call runs as the signed-in user." src="docs/img/architecture.svg" width="100%"> </picture>

Everything runs as the signed-in user, never a service principal. That is a design decision, not an omission — see Security.

The three bridges

1. A Foundry agent as a Copilot tool

The whole bridge, minus error handling:

project = AIProjectClient(endpoint=PROJECT_ENDPOINT, credential=DefaultAzureCredential())
client  = project.get_openai_client(agent_name=AGENT_NAME)   # pre-bound to your agent
reply   = client.responses.create(input=prompt).output_text

No model name, no system prompt on the client. The instructions, tools and model deployment stay server-side in Foundry, so you change the agent in the portal and every user picks it up on their next message — no redeploy, no version drift across machines.

→ docs/01-foundry-bridge.md

2. An MCP server that is also an MCP client

Plenty of people write MCP servers. Far fewer write a client — and that is where the interesting architecture lives. This server launches Microsoft's official Power BI modeling MCP server as a child process, speaks JSON-RPC to it over stdio, and re-exposes the result as one opinionated tool.

You get to add policy at the boundary: the child is launched --read-only by default, so no chain of LLM calls can quietly mutate a production model.

StdioMcpClient is generic — point it at any MCP server, not just this one.

→ docs/02-mcp-calls-mcp.md

3. Fabric GUIDs → names

The modeling server connects by name. What the user has in front of them is a Fabric URL full of GUIDs. So we resolve them against the Fabric REST API instead of asking people to go hunting for display names.

→ docs/03-fabric-rest.md

Tools exposed to Copilot

Tool	What it does	Writes?
ask_agent_tool	Puts a question to your Foundry agent	no
inspect_model	Connects to a semantic model and summarises it	no
show_measure	Shows the current DAX of one measure	no
update_measure_dax	Rewrites a measure	yes — needs confirm=True
resolve_fabric_ids	Turns the GUIDs in a Fabric URL into names	no

Getting started

Requirements: Python 3.11+, VS Code with GitHub Copilot, az login done. Node.js only if you want the Power BI tools (it runs the official server via npx).

git clone https://github.com/Nambu89/foundry-copilot-mcp
cd foundry-copilot-mcp
python -m venv .venv
.venv/Scripts/activate          # macOS/Linux: source .venv/bin/activate
pip install -r requirements.txt

cp .vscode/mcp.json.sample .vscode/mcp.json   # then fill in your endpoint and agent name

Check the Foundry connection before you trust it — and definitely before you demo it:

python -m foundry_mcp.server --selftest "Hello, who are you?"

Then open VS Code, switch Copilot Chat to Agent mode, and the tools show up. Ask it something like "ask the agent what it can do" or "inspect the model in samples/sample-model".

No Foundry project yet? The Power BI and TMDL parts work standalone, and samples/sample-model is a small semantic model you can point them at.

Security

Four decisions worth copying into whatever you build:

The user's identity, not a service principal. DefaultAzureCredential and the modeling server's interactive sign-in mean every read runs as the person asking. Row-level security therefore applies. Wire a service principal in and RLS is silently bypassed — users see rows they should not, with no error to warn you. That is the quietest data leak on this list.

Read-only by default. The one writing tool (update_measure_dax) needs an explicit confirm=True, and shows the current and proposed DAX first so a human can compare them.

Validation stays with the engine. Measure updates go through the official server's measure_operations/Update, so the tabular engine rejects invalid DAX. Hand-patching TMDL text would happily write a broken model.

No secrets in the repo. Configuration is environment variables in .vscode/mcp.json, which is gitignored. Only .vscode/mcp.json.sample is tracked.

Tests

pytest

21 tests, no network, no Azure, no Node.js — including fake MCP servers that exercise the real JSON-RPC framing, the notification handling and the timeout.

Talk

This repo backs a talk on connecting Microsoft Foundry agents to Copilot Chat over MCP. Slides and video will be linked here after the conference.

Licence

MIT — see LICENSE.