AI 에이전트가 Power BI 보고서에 직접 묻는다, 읽기 전용 Fabric IQ MCP

결론부터 적으면, Fabric IQ MCP는 AI 에이전트가 Power BI에서 볼 수 있는 범위를 넓히지 않고 데이터가 움직이는 거리를 늘립니다. 서버까지는 로그인한 사용자의 권한과 행 수준 보안(RLS)이 그대로 따라가지만, 서버를 나온 결과가 MCP 클라이언트와 LLM 제공자에게 넘어가는 순간부터는 Power BI가 아니라 조직의 AI 데이터 정책이 지켜야 합니다. Microsoft 문서가 일반 공급(GA)으로 안내하는 이 서버는 원격 MCP이고, 도구 여섯 개가 모두 읽기 전용입니다. 이 글은 경계가 어디에 그어지는지, 경계 안쪽에서 무엇이 데이터를 걸러 주는지, 바깥쪽에서 무엇을 직접 정해야 하는지를 차례로 짚습니다. 기준일은 2026-10-27(UTC)이고, 공식 시작 문서는 10월 21일 판이 가장 최신입니다.

권한이 멈추는 선과 데이터가 계속 가는 길

먼저 데이터 하나가 지나가는 길을 그림으로 보겠습니다. 초록 구역은 Power BI의 권한과 보안 규칙이 일하는 곳이고, 노란 구역은 그렇지 않은 곳입니다.

그림 1. 서버를 나온 결과는 클라이언트와 LLM 제공자로 이어진다. 점선의 다른 서버는 같은 클라이언트에 함께 등록된 경우의 길이다

초록 구역 안에서는 로그인한 사용자의 권한이 모든 호출에 붙고, RLS와 OLS(개체 수준 보안)가 반환 값을 걸러 줍니다. 그림에서 두 구역이 만나는 선이 이 글의 중심입니다. Microsoft는 MCP 서버가 접근 범위는 넓히지 않지만 데이터를 옮긴다고 직접 적고 있습니다. 메타데이터, 스키마, 쿼리 결과가 MCP 클라이언트로 가고, 클라이언트는 이를 설정된 LLM 제공자에게 대화 문맥으로 전달할 수 있습니다. 이 이동은 Power BI의 보안 통제가 아니라 조직의 AI 데이터 취급 정책과 제공자 약관으로 다스리라는 것이 문서의 요구입니다.

넘어가는 것이 쿼리 결과만이 아니라는 점도 놓치기 쉽습니다. 테이블과 열의 이름, 측정값의 정의, 모델 작성자가 적어 둔 지침이 스키마 조회 때 클라이언트로 오고, 값 검색을 하면 모델에 저장된 고객명이나 제품명 같은 값도 옵니다. 숫자 한 줄이 아니라 모델의 구조와 용어까지 대화 문맥에 들어간다고 보고 정책을 정해야 합니다.

클라이언트가 한 종류가 아니라는 점도 있습니다. Microsoft 개요 문서는 Fabric IQ를 Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry, 사용자 지정 에이전트가 Power BI 데이터로 답을 얻는 지원 경로로 소개합니다. 노란 구역의 모습은 연결하는 클라이언트마다 다르고, 그 정책을 대신 정해 주는 서버는 없습니다.

토큰 하나로 열리는 범위, 다섯 겹

서버가 어떤 권한으로 움직이는지를 겹겹으로 나누면 이렇습니다. 위에서 아래로 갈수록 데이터에 가까워집니다.

• 위임 토큰(Microsoft Entra)Power BI Service API의 Item.Read.All, Item.Execute.All 두 위임 권한이 모든 클라이언트에 필요하다. 서비스 주체와 앱 전용 인증은 지원하지 않는다
• 동의 정책이 두 권한은 기본으로 관리자 동의가 필요 없고 테넌트 설정이 허용하면 사용자가 직접 동의한다. 관리자는 사용자 동의를 막거나 승인 절차를 요구할 수 있고, 권한은 엔드포인트 전체에 걸린다
• Power BI 접근 권한사용자가 원래 열 수 있는 보고서와 모델만 보인다. 관리자 대리 경로는 없고 작업 영역 역할이나 Build 권한도 따로 요구하지 않는다
• RLS와 OLS같은 질의도 사람마다 다른 행과 열을 돌려준다. MCP로 연결해도 이 규칙은 그대로 적용된다
• 의미 모델의 데이터마지막으로 성공한 새로 고침 시점의 값이다. 모델이 노출하지 않은 필드나 측정값이 필요한 질문은 실패하거나 불완전하게 답한다

가장 위의 층이 중요한 이유는 서비스 주체를 막아 두었기 때문입니다. 무인 파이프라인이 서비스 주체로 모델을 질의하게 되면 사람의 RLS가 아니라 주체 자신의 권한으로 읽게 됩니다. 이전 Consumption 엔드포인트의 문서는 서비스 주체 인증에서 RLS가 적용되지 않는다고 직접 경고합니다. Fabric IQ는 처음부터 위임 인증만 허용하므로 이 구멍은 구조상 열려 있지 않습니다. 대신 “서비스 계정으로 밤마다 돌린다”는 용도는 이 서버로 할 수 없습니다.

세 번째 층의 “작업 영역 역할이 필요 없다”는 말도 양면입니다. 보고서나 모델에 접근할 수 있다면 질의가 가능하고, 모델의 Build 권한을 따로 받을 필요가 없습니다. 접근 문턱이 낮은 만큼 그 보고서를 열 수 있는 사람은 모두 이 서버로 물을 수 있는 사람이 됩니다. 보고서 공유 범위를 정리하는 일이 AI 도입 전의 숙제가 되는 이유입니다.

그리고 Power BI의 테넌트 설정 Users can use the Power BI Model Context Protocol server endpoints (preview)는 Fabric IQ를 켜거나 끄지 않습니다. 문서가 밝히듯 이 설정은 모델 작성(Authoring) 경험을 제어합니다. 그래서 이 설정을 꺼 두었다는 사실만으로 읽기 전용 서버까지 막혔다고 생각하면 안 됩니다. 문서가 밝힌 관리자 쪽 통제는 위의 두 번째 층, 곧 사용자 동의를 막거나 승인 절차를 요구하는 것입니다.

같은 질문에 두 사람이 다른 답을 받는다

RLS가 이어지는지는 말보다 시험이 빠릅니다. 아래는 편집부가 만든 가상의 상황입니다. 한 영업 모델에 지역별 RLS가 걸려 있고, 지역 영업 담당자 A는 자기 지역 행만, 본사 분석가 B는 전체를 본다고 가정합니다. 두 사람이 같은 보고서에 같은 질문을 던집니다.

• A의 에이전트는 “최신 분기 지역별 총매출”에서 A의 지역 한 줄만 돌려받습니다
• B의 에이전트는 모든 지역의 합계를 돌려받습니다
• 두 에이전트의 DAX는 똑같아도 됩니다. 걸러지는 것은 쿼리가 아니라 사용자이기 때문입니다

에이전트가 틀린 것이 아니라 보안이 정상 작동한 결과입니다. 거꾸로 A의 답에 다른 지역의 숫자가 보인다면 모델의 RLS 설정을 의심해야 합니다. 이 시험은 MCP 서버를 처음 붙인 날 한 번 해 두면 좋습니다. 다만 서버가 RLS를 올바르게 전달하는지가 아니라 모델의 규칙이 의도대로 짜였는지를 확인하는 시험입니다. 규칙 자체가 비어 있으면 서버는 그 상태를 그대로 따를 뿐입니다.

개체 수준 보안(OLS)도 같은 자리에서 일합니다. 문서는 RLS와 OLS 둘 다 반환되는 데이터를 계속 제한한다고 적으므로, 에이전트의 답에서 어떤 열이 빠져 있다면 서버의 결함보다 그 사용자에게 열린 범위를 먼저 확인하는 편이 맞습니다.

질문 한 번이 지나는 여덟 걸음

그러면 이 보안이 호출 중 어느 시점에 붙는지 봅니다. 문서의 시험 예시(“Using the Sales Analytics report, show total sales by region for the latest quarter”)가 지나는 길을 순서대로 그렸습니다.

그림 2. 순서는 에이전트가 정한다. 문서의 예시는 이 흐름이며 질문에 따라 단계가 줄거나 늘어난다

네 번의 도구 호출 가운데 데이터 값이 처음 서버를 떠나는 것은 값 검색과 쿼리 실행입니다. 앞의 둘(찾기, 구조 읽기)은 이름과 구조를 가져오는 호출입니다. 그림의 “run as the user”에서 보듯 실행은 서버가 대신 하지만 신분은 사용자의 것입니다. 이 여덟 걸음 어디에도 서버가 자기 권한으로 읽는 단계는 없습니다. 아래 표는 도구마다 클라이언트로 무엇이 넘어가는지를 정리한 것입니다.

도구	하는 일	클라이언트로 넘어가는 것
DiscoverArtifacts	이름으로 보고서와 의미 모델 검색(최대 50건, 보고서 우선)	찾은 항목의 목록
ResolveFabricItem	브라우저 주소나 GUID를 정식 식별자, 항목 종류, 작업 영역 ID로 변환	식별자와 종류
GetReportMetadata	보고서의 페이지, 시각 요소, 필터, 쓰는 의미 모델 읽기	보고서 구조와 필터
GetSemanticModelSchema	테이블·열·측정값·관계, 작성자의 지침과 검증된 답변 읽기	모델 구조와 작성자의 글
ValueSearch	저장된 값의 정확한 표기 찾기	모델에 저장된 값
ExecuteQuery	의미 모델 하나에 DAX 1~4개 실행	쿼리 결과 행

자연어로 답을 만들어 주는 도구는 없습니다. 도구를 고르고 DAX를 짜고 결과를 풀어 쓰는 일은 모두 호출하는 에이전트의 몫입니다. 보고서를 찾을 때 브라우저 주소를 붙여 넣어도 되지만 Power BI 공유 링크는 쓸 수 없고, 작업 영역 앱 안의 보고서 주소에는 ResolveFabricItem이 꼭 필요합니다. 도구별 상세 규격(쿼리 1~4개, 최대 1,000행, 최대 50건)은 Microsoft가 공개한 Fabric IQ 스킬 문서에 적힌 값이고, 공식 시작 문서는 입력 규격의 기준으로 실행 시점의 tools/list 응답을 쓰라고 안내합니다.

읽기만 하는 DAX가 따르는 규칙

에이전트가 만드는 쿼리는 이런 모양입니다. 테이블 이름은 예시이고, 실제로는 스키마에서 읽은 이름을 씁니다. 모델에는 아무 흔적도 남기지 않는 조회입니다.

EVALUATE
SUMMARIZECOLUMNS(
    'Region'[Region Name],
    "Total Sales", [Total Sales]
)
ORDER BY [Total Sales] DESC

Fabric IQ 스킬 문서가 정한 규칙은 이렇습니다. 쿼리마다 EVALUATE는 하나이고, 여러 행을 돌려주면 ORDER BY를 붙입니다. 순위는 TOPN으로 줄이며 특별한 요청이 없으면 50행 이하로 합니다. 보고서 안에서 정의한 측정값은 보고서 층에만 있어 이름만 불러서는 실패하므로, 보고서 메타데이터에서 식을 읽어 쿼리 안에서 다시 정의해야 합니다. 이렇게요.

DEFINE
    MEASURE 'Sales'[Sales YoY] =
        DIVIDE([Total Sales] - [Total Sales LY], [Total Sales LY])
EVALUATE
TOPN(
    10,
    SUMMARIZECOLUMNS('Product'[Category], "YoY", 'Sales'[Sales YoY]),
    [YoY], DESC
)
ORDER BY [YoY] DESC

이름은 모두 예시입니다. 눈여겨볼 곳은 DEFINE MEASURE입니다. 이것은 모델을 바꾸지 않고 이 쿼리 안에서만 살아 있는 임시 정의입니다. 읽기 전용 서버에서도 에이전트가 새 계산을 시도할 수 있는 길이 여기에 있고, 그 결과가 모델에 저장되는 일은 없습니다.

반대로 막힌 문법도 있습니다. INFO 함수, DMV 쿼리, MDX는 지원하지 않는다고 스킬 문서에 적혀 있습니다. 모델의 메타 정보를 임의의 쿼리로 훑는 길이 닫혀 있고, 구조는 스키마 도구가 주는 만큼만 보입니다. 오류에 대한 규칙도 있습니다. 잘못된 DAX는 한 번 고쳐 다시 실행하고, 결과가 비면 스키마와 측정값, 필터를 점검한 뒤 최대 한 번 다시 시도하며, 권한 오류는 접근 부족일 수도 도구의 한계일 수도 있다고 알립니다. 제한에 걸리면 사용자에게 잠시 뒤 다시 시도하라고 안내하고, 시간 초과는 한 번 재시도한 뒤 몇 분 기다리라고 합니다.

한 번에 나갈 수 있는 행 수

읽기 전용이라고 해서 나가는 양이 문제가 되지 않는 것은 아닙니다. 그래서 상한을 같은 축에 놓았습니다.

그림 3. 한 번의 호출이 돌려줄 수 있는 행 수의 상한. Authoring 쪽 100,000행은 Microsoft Authoring 문서에 적힌 DAX 실행 도구의 한도다

Fabric IQ는 maxRows를 정하지 않으면 250행, 정하면 1,000행까지입니다. 모델을 만들고 고치는 Authoring MCP의 DAX 실행 도구는 한도가 100,000행입니다. 편집부가 계산하면 최대치끼리 100배 차이입니다. 소비용 서버는 설계에서부터 한 번에 흘려 보낼 수 있는 양에 천장이 있고, 그 천장이 한 번에 흘러나갈 수 있는 양의 상한 역할도 합니다. 막대가 이렇게 극단으로 갈리는 이유는 두 서버의 설계 목적이 달라서입니다. 하나는 사람의 질문 한 건에 답하기 위한 것이고, 다른 하나는 모델을 개발하는 사람이 대량의 결과를 검증하기 위한 것입니다.

큰 결과는 서버가 임베디드 CSV 리소스로 돌려줍니다. 클라이언트는 보통 작은 미리 보기만 화면에 보이고 전체 데이터는 CSV 리소스로 받게 하지만, 임베디드 리소스 지원은 클라이언트마다 다르고 Power BI의 쿼리 한도 때문에 결과가 잘릴 수도 있습니다. 문서의 권고는 집계와 필터, 초점을 좁힌 쿼리로 결과를 줄이라는 것입니다. 이는 성능을 위한 권고이면서 동시에 나가는 데이터를 줄이는 방법이기도 합니다. 한 번에 모델 하나만 질의하므로 여러 모델의 결과를 합쳐 보려면 에이전트가 모델별로 따로 실행해 이어 붙여야 하고, 서버가 모델을 가로질러 조인해 주지는 않습니다.

서버 넷을 한 계정에 모으면

한 클라이언트에 여러 MCP 서버를 등록하면 그림 1의 점선이 현실이 됩니다. Power BI 쪽에는 서버가 둘이고, 이전 Consumption 엔드포인트가 기존 연동용으로 남아 있어 실제로는 넷을 구분해야 합니다. 같은 사용자 계정으로 붙는다면 각 서버의 권한이 그대로 합쳐집니다.

서버	상태	모델을 바꿀 수 있나	필요한 것
Fabric IQ MCP	GA	아니오(읽기 전용)	Entra 로그인, 위임 권한 2개
Authoring MCP, 호스팅형	미리 보기	예	모델 Write 권한(Build만 있으면 DAX 실행만), 관리자가 켜는 테넌트 설정
Authoring MCP, 로컬형	GA	예 + Desktop·PBIP·TMDL 파일	XMLA 읽기/쓰기, 서비스 주체 가능, macOS 미지원
Consumption MCP(이전)	미리 보기	아니오(쿼리 실행)	Build 권한, 테넌트 설정, 모델 ID 직접 제공, 쿼리 생성 도구는 Copilot 라이선스

Microsoft 개요 문서는 용도를 선명하게 나눕니다. 모델 개체를 만들고 고치는 일은 Authoring, 사용자의 질문에 답하는 일은 Fabric IQ입니다. Authoring 서버가 DAX를 실행할 수 있어도 최종 사용자의 질문에 답하려고 설계된 서버가 아니며, 소비에는 Fabric IQ를 쓰라고 문서가 못박습니다. 권하는 조합은 “Authoring으로 모델을 만들고 문서화한 뒤 Fabric IQ로 모두가 묻게 한다”입니다.

위험은 두 가지입니다. 첫째, 읽기용 클라이언트에 Authoring 서버를 함께 등록하면 Fabric IQ의 읽기 전용이라는 성질이 의미를 잃습니다. 모델에 Write 권한이 있는 사용자라면 에이전트가 모델 개체를 바꿀 수 있고, 자율 동작하는 에이전트나 잘못 설정한 클라이언트가 의도하지 않은 동작을 할 수 있다고 Microsoft도 경고합니다. 둘째, Authoring의 로컬형과 호스팅형을 동시에 등록하는 것도 권하지 않습니다. 에이전트가 겹치는 도구를 두 벌 보게 되어 라우팅이 모호해지고 요청마다 토큰이 더 들기 때문입니다.

모델 작성자가 정해 두는 길잡이

답의 방향은 서버가 아니라 모델이 정합니다. Fabric IQ 스킬 문서가 정한 작업 순서는 아홉 단계입니다. 항목을 확인하고, 보고서에 걸린 필터를 반영하고, 스키마를 끝까지 읽고, 검증된 답변과 맞는지 보고, 값을 확정하고, DAX를 쓰고, 실행하고, 결과를 점검하고, 결론부터 답합니다. 그중 검증된 답변이 가장 센 길잡이입니다. 질문이 검증된 답변과 맞으면 스킬은 그 바인딩과 필터, 집계 단위를 그대로 따르게 하고, 날짜 필터 같은 것을 마음대로 더하지 못하게 하며, 모델의 지침도 그 위로 올라서지 못한다고 정합니다.

검증된 답변과 모델의 “AI 지침”, “AI 데이터 스키마”는 Power BI의 Prep data for AI 기능으로 만들고, 보고서가 아니라 의미 모델에 저장됩니다. Desktop과 서비스 양쪽에서 작성할 수 있고 Q&A 사용 설정이 필요합니다. 결과가 매번 같다는 보장은 없다고 문서가 못박는 비결정적 기능이므로 만든 뒤 Copilot 창에서 시험하는 것이 권장 절차입니다. 이 설정이 MCP 스키마 도구로 에이전트에게 전달되는 것은 스킬 문서에 적힌 동작입니다. 이 길잡이가 비어 있다면 에이전트는 열 이름과 측정값 이름에서 의도를 추측해야 하고, 그만큼 답이 흔들립니다.

스킬은 에이전트에게 “어떻게 할지”를 가르치는 마크다운 지침이고, 서버가 실제 접근과 실행을 맡습니다. 스킬은 정적 지식이라 스스로 코드를 실행하지 않습니다. 스킬 없이도 연결은 되지만 Fabric 고유의 순서와 안전 규칙을 클라이언트가 스스로 정해야 합니다. 설치 명령은 Copilot CLI와 Claude Code가 같습니다.

/plugin marketplace add microsoft/skills-for-fabric
/plugin install fabric-skills@fabric-collection
/quit
/skills

Skills for Fabric는 두 개의 플러그인으로 나뉩니다. 위의 fabric-skills에는 Power BI 플러그인이 들어 있지 않고, 모델을 만드는 powerbi-authoring@fabric-collection은 따로 설치합니다. 눈여겨볼 점은 Authoring 문서가 이 플러그인에 로컬 Authoring MCP 서버가 함께 들어 있어서 한 번 설치로 도구와 지침을 같이 얻는다고 설명한다는 것입니다. 읽기 전용 클라이언트라면 이 플러그인은 설치하지 않는 편이 맞습니다. 사전 요건으로는 Node.js, PowerShell 7, Git, Azure CLI(az login)가 문서에 나오고, 설치 뒤에는 /quit으로 도구를 다시 시작해 /skills 목록에 보이는지 확인합니다.

연결해서 권한이 이어지는지 확인하기

공식 문서의 안내 클라이언트는 GitHub Copilot CLI입니다. 설정은 마지막 절에 있고, 아래 순서로 연결과 권한 이어짐을 같이 확인합니다.

1. 홈 폴더의 .copilot/mcp-config.json(윈도에서는 %USERPROFILE%\.copilot\mcp-config.json)에 서버를 추가하고 Copilot CLI를 시작합니다.
2. /mcp show FabricIQ를 실행하면 브라우저가 열립니다. Microsoft Entra 업무·학교 계정으로 로그인하고 권한을 요청하면 수락합니다. Copilot CLI는 미리 등록된 Entra 앱을 쓰므로 앱 등록이 필요 없습니다.
3. 연결 상태와 도구 6개 목록이 나오면 엔드포인트, 인증, MCP 악수가 확인된 것입니다.
4. "Find the Sales Analytics report in Microsoft Fabric"처럼 접근할 수 있는 보고서를 찾게 합니다. DiscoverArtifacts가 불려 결과가 나오면 인증, Fabric 권한, 도구 실행, 대상 접근이 모두 확인된 것입니다.
5. 데이터가 필요한 질문("Using the Sales Analytics report, show total sales by region for the latest quarter")을 던져 끝에서 끝까지 확인합니다.
6. RLS가 걸린 모델이라면 권한이 다른 두 사람의 계정으로 같은 질문을 던져 결과가 달라지는지 비교합니다.

여기서 Authorization 헤더를 직접 넣으면 대화형 OAuth와 자동 토큰 관리가 무시되므로 넣지 않습니다. 토큰이 무효이거나 만료되었을 때는 헤더를 지우면 대화형 로그인으로 돌아갑니다. 조직이 프라이빗 링크를 쓴다면 엔드포인트를 https://api.fabric.microsoft.com/v1/mcp/fabriciq로 바꿉니다.

다른 MCP 클라이언트를 쓸 때는 두 조건을 봅니다. Streamable HTTP와 필요한 OAuth 2.0 흐름을 지원해야 하고, 일부 클라이언트는 단일 테넌트 Entra 앱 등록을 요구합니다. 그런 경우 Entra 관리 센터에서 “이 조직 디렉터리의 계정만” 앱을 만들고 클라이언트가 요구하는 리디렉션 URI를 인증에 넣은 뒤, Power BI Service의 위임 권한 두 개를 추가해 앱(클라이언트) ID와 테넌트 ID를 클라이언트에 넘깁니다. 도구 목록은 코드에 박아 두지 말고 tools/list로 실행 시점에 읽고, 도구나 필드가 늘어도 견디도록 만드는 것이 문서의 권고입니다. 도구 규격 버전을 고정하려면 initialize, tools/list, tools/call 모든 요청에 X-Variants: Fabric.Routing.FabricIQ.V1 헤더를 붙입니다. 엔드포인트의 v1은 주소의 일부일 뿐 도구 규격 버전이 아닙니다.

막히는 증상과 지원하지 않는 곳

공식 문제 해결 표를 증상별로 줄이면 이렇습니다.

증상	원인으로 꼽힌 것	확인할 것
로그인 창이 안 뜬다	클라이언트가 OAuth 자동 탐색을 지원하지 않거나 앱 등록이 필요함	클라이언트의 OAuth 설정, 단일 테넌트 앱 등록
인증이 실패한다	토큰 만료, 잘못된 대상, 위임 권한 누락, 동의 정책	재인증, Power BI Service 위임 권한, 테넌트 동의 정책
도구가 문서와 다르다	X-Variants 헤더 없음 또는 값 오류	헤더를 Fabric.Routing.FabricIQ.V1로 맞추고 재연결
아는 보고서가 안 나온다	권한 없음, 지원하지 않는 형식, 이름이 모호함	더 구체적인 이름, 또는 브라우저 주소 붙여 넣기
제한 오류	요청이 너무 빠르거나 Power BI 쪽에서 제한	잠시 뒤 재시도, 요청 묶음 줄이기, 결과 좁히기
숫자가 오래됐다	의미 모델이 최근에 새로 고침되지 않음	모델의 새로 고침 이력 확인

도구 목록이 비어 보이면 연결이 낡은 경우도 있으니 연결을 다시 시작해 실행 시점의 도구 목록을 확인합니다. 권한 오류가 나면 요청한 내용에 접근할 수 없는 신분이라는 뜻이므로 보고서·모델 접근 권한과 RLS·OLS 제한을 봅니다.

지원하지 않는 곳도 있습니다.

• 지원 항목은 Power BI 보고서와 의미 모델뿐입니다. 대시보드, 페이지 매김(RDL) 보고서, Power BI 앱은 지원하지 않고, Fabric 온톨로지와 데이터 에이전트도 지금은 지원하지 않는다고 문서가 적습니다
• 테넌트의 홈 리전이 모든 Fabric 워크로드를 지원해야 하고, Power BI 전용 리전과 소버린 클라우드에서는 쓸 수 없습니다. 반대로 보고서와 모델이 Fabric이나 Premium 용량에 있을 필요는 없습니다
• 작업 영역 관리, 개발, 항목 생성은 이 서버의 일이 아닙니다. 그런 작업은 Skills for Fabric와 더 넓은 Fabric MCP 서버로 하라고 문서가 안내합니다
• 속도 제한이 있습니다. Power BI의 서비스 쪽 제한이 메타데이터와 DAX 작업에 적용되고, 제한 오류는 재시도할 수 있지만 클라이언트가 잠시 물러났다가 다시 시도해야 합니다

읽기 전용 클라이언트에 등록할 설정

지금까지의 위험 지도를 설정 하나로 줄이면 이렇습니다. 읽기용 클라이언트에는 Fabric IQ만 등록하고, 문서 예시의 “*” 대신 도구 이름을 적어 허용 목록으로 씁니다. 문서가 도구가 늘어나도 견디라고 권하는 만큼, 새 도구가 서버에 생겨도 목록에 적지 않은 것은 자동으로 열리지 않게 하려는 것입니다. Authoring 서버와 powerbi-authoring 플러그인은 이 클라이언트에 두지 않고 모델 작성용 클라이언트를 따로 둡니다. 헤더 설정을 지원하는 클라이언트라면 도구 규격을 고정하는 X-Variants 헤더도 여기에 같이 넣을 수 있습니다.

{
  "mcpServers": {
    "FabricIQ": {
      "type": "http",
      "url": "https://fabriciq.svc.cloud.microsoft/v1/mcp/fabriciq",
      "tools": [
        "DiscoverArtifacts",
        "ResolveFabricItem",
        "GetReportMetadata",
        "GetSemanticModelSchema",
        "ValueSearch",
        "ExecuteQuery"
      ]
    }
  }
}