Skip to main content
Glama
sdebruyn

fabric-dw-mcp-cli

by sdebruyn

create_table

Create a new SQL table in a Fabric Data Warehouse using a CTAS query. Provide a read-only SELECT or WITH statement as the source. Optionally specify clustering columns.

Instructions

Create a new SQL table via CTAS (CREATE TABLE AS SELECT).

Only supported on Fabric Data Warehouses (not SQL Analytics Endpoints). The service rejects SQL Analytics Endpoints with a ToolError.

CAUTION: select_body is executed verbatim as DDL on the warehouse. Ensure the body matches the user's intent before calling this tool.

select_body must be a single read-only SELECT or WITH (CTE) statement. The guard is always on and fail-closed: a write keyword (DELETE, DROP, INSERT, etc.) or a semicolon anywhere in the body is rejected, even inside a string literal or quoted identifier. If a legitimate query body contains a write keyword (e.g. a column alias 'DELETE'), rewrite the expression to avoid the keyword.

When cluster_by is supplied, the DDL becomes CREATE TABLE … WITH (CLUSTER BY ([c1], [c2])) AS SELECT …. Column existence is not validated for CTAS because the result columns come from the SELECT and are not known ahead of time.

Args: workspace: Workspace name or GUID. item: Warehouse name or GUID. SQL Analytics Endpoints are rejected. qualified_name: Dot-separated qualified table name, e.g. dbo.sales. select_body: Single read-only SELECT or WITH (CTE) statement for the CTAS source. Write keywords and semicolons are rejected fail-closed, even inside string literals or quoted identifiers. cluster_by: Optional list of column names for the CLUSTER BY clause (up to 4).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemYes
workspaceYes
cluster_byNo
select_bodyYes
qualified_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description provides important behavioral details: the DDL is executed verbatim, the guard against write keywords and semicolons, and the behavior with cluster_by. It does not mention permissions or rollback, but covers key safety aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for overview, support restrictions, caution, and parameter details. It is somewhat lengthy but every sentence adds value. A slightly more concise wording could improve readability without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, 0% schema coverage, many siblings), the description is comprehensive. It covers purpose, usage constraints, parameter details, and behavioral nuances. The presence of an output schema (not shown) means return values do not need to be described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description thoroughly explains all 5 parameters: workspace, item, qualified_name (dot-separated), select_body (single read-only SELECT/CTE), and cluster_by (up to 4). It adds meaning beyond the schema, including the guard details for select_body.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a new SQL table') and the method ('via CTAS'), distinguishing it from sibling tools like clone_table and create_empty_table. The verb and resource are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies that the tool is only supported on Fabric Data Warehouses and not on SQL Analytics Endpoints, providing clear context. It could be improved by explicitly contrasting with similar tools (e.g., clone_table), but the constraints are well communicated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sdebruyn/fabric-dw-mcp-cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server