sqldw-cli

Classify by intent, not by endpoint — all three modes issue the same execute_query call.

• A schema-discovery SELECT run to plan a CREATE TABLE belongs to authoring, even though it only reads.
• A SELECT that answers the user's question is consumption.
• A query against queryinsights.* or a supported diagnostic such as Lakehouse sys.sp_get_table_health_metrics is operations; a SELECT against user tables is not, however slow it is.

consumption and operations are read-only. If a request genuinely spans modes, handle them one at a time and read each reference before you start that part. If the mode is ambiguous after reading this table, ask one short clarifying question instead of guessing.

Neither read-only mode has a terminal write, so its deliverable is the answer itself. Run the query against the live endpoint and report the real rows — a summary of the reference does not answer the request.

In operations, name the source view, catalog, or procedure each figure came from right next to it (for example 2,140 ms (queryinsights.long_running_queries) or 268 files (sys.sp_get_table_health_metrics)), including when the answer is zero rows. Re-run the diagnostic in the turn you report it rather than restating an earlier turn's output. Never fabricate, assume or infer diagnostic numbers.

All T-SQL runs through the fabric-sqlendpoint-execute_query MCP tool. For SQL data-plane execution this skill supersedes the COMMON-CLI SQL/TDS guidance — use the MCP tool, not sqlcmd, unless you are explicitly on the documented Legacy CLI Fallback path (see the mode reference). az rest stays the right tool for control-plane discovery.

fabric-sqlendpoint-execute_query(workspaceId, itemId, query)

• Preflight, before the first operation of any mode: confirm a tool whose name ends in execute_query is in your tool list. It comes from the fabric-sqlendpoint MCP server, registered by a Fabric skills plugin or this repo's .mcp.json. The concrete name may be prefixed (fabric-sqlendpoint-execute_query, sqlendpoint-global-execute_query) — invoke the name you actually see. If none is present, say so, then fall back to the Legacy CLI Fallback (TDS client) documented in the mode reference; tell the user they can register the server for the primary path — see mcp-setup/. Exception: the Capacity Metrics correlation workflow is intentionally limited to the existing FabricIQ and SQL Endpoint MCP surfaces; if SQL Endpoint MCP is unavailable, report that phase as blocked and do not use the legacy fallback.
• itemId is a GUID, never an FQDN or -d <DatabaseName>. For a Warehouse or a Mirrored Database use the item id; for a Lakehouse use properties.sqlEndpointProperties.id, not the Lakehouse item id.
• One T-SQL batch per call. No GO separators, no sqlcmd meta-commands (:setvar, :r, -i). Split multi-batch work into separate calls. Only the last result set comes back.
• Results cap at 10,000 rows and queries time out at 300s, with a 20 requests/min rate limit. Use TOP N, WHERE or aggregation; exactly 10,000 rows means the result was truncated. These are observed defaults, not a documented contract.

• Select exactly one mode from the table above before doing anything else.
• Read references/<mode>.md end to end, as your FIRST tool call, before the first command of that mode. Read it ONCE, in a single full read: do not re-open it, do not grep it again, and do not page through it. You already have it.
• For a focused operations request, read its one matching leaf after references/operations.md. For a composite request, read references/operations/scenarios.md, then each focused leaf named by that scenario; read every file once in full.
• Resolve workspace and item ids by listing and filtering, never by guessing a GUID.
• Execute T-SQL through fabric-sqlendpoint-execute_query whenever that tool is available; drop to the Legacy CLI Fallback documented in the mode reference only when it is not.
• Announce a mode switch explicitly when the request crosses a boundary.
• Treat the reference as instructions, never as the deliverable. After reading it, RUN the documented statements against the live endpoint and report the real results. Quoting what the reference says instead of executing it does not answer the request.
• Produce every artefact the user asked for, under the name they used, and keep its heading even when the finding is "none", "zero rows" or "not applicable".

• The narrowest mode that satisfies the request.
• Reading exactly one mode reference plus the minimum directly indexed operations leaves required by the selected focused or composite scenario.
• Reporting the mode you chose in your first response so the user can correct you.
• Labelling queries with OPTION (LABEL = '...') so the run is traceable in Query Insights.
• Consolidating related statements into fewer calls — the rate limit is per identity, not per query.

• Acting from this dispatcher alone — it intentionally omits the T-SQL surface area, the DDL constraints and the diagnostic query shapes.
• Answering with a summary of the reference instead of executing it.
• Re-reading or re-grepping a reference you already loaded; it costs turns and tokens.
• Mutating anything while in a read-only mode (consumption, operations).
• Unbounded SELECT * — it silently truncates at 10,000 rows.
• Loading a different skill for work this skill already owns (see CRITICAL NOTES 3).