Loading ToolBench
MCP server for Microsoft Fabric Analytics with Synapse-to-Fabric migration - enables LLMs to access, analyze, and migrate workloads to Microsoft Fabric
This server presents 19 tools for Microsoft Fabric Analytics and Synapse migration. While tool names follow verb_noun conventions and schemas are visible, there are critical gaps in description quality, parameter documentation, and output schema definition. Output schemas are not documented. Error handling is not evident in the provided source. The server lacks pagination support despite tools that list resources. Baseline expectations for production-grade tools (descriptions 10 - 1024 chars with 100% param annotation, documented return types) are not consistently met. Most tools would score 40 - 55 individually.
Assign a capacity to a workspace
Create a new Fabric lakehouse
Create Fabric Spark pools based on Synapse configuration
Discover assets from Synapse workspace
Assign a workspace to a dedicated Fabric capacity
List all available Fabric capacities
List all workspaces assigned to a specific capacity
Parameter descriptions are minimal and under 20 characters in most tools. Example: bearerToken described as 'Optional bearer token if not using configured authentication' (acceptable ~75 chars), but many parameter descriptions lack detail on format, constraints, or when to use them.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | 1.13.0+ | v1 |
Unassign a workspace from its capacity (move to shared capacity)
Get Synapse Spark pools configuration
List all available Fabric capacities
List Synapse Spark pools
List available Synapse workspaces
Migrate Synapse Spark pools to Fabric
Execute complete migration from Synapse to Fabric
Provision transformed notebooks to Fabric workspace
Recommend Fabric capacity based on Synapse usage
Analyze Synapse compute spend
Get Synapse workspace details
Transform notebooks (can be used standalone after discovery)
Output schemas are not documented in tool definitions. LLMs cannot plan downstream calls or extract return values without knowing the response structure. All 19 tools lack documented return types, violating the baseline that 100% of A+ tools have documented return types.
List tools (fabric_list_capacities, fabric_list_capacity_workspaces, list_synapse_workspaces, list_synapse_spark_pools, list_fabric_capacities) lack pagination parameters (limit, offset/page, cursor). Without pagination, large result sets blow the context window. No limit caps are documented.
Irreversible operations (migrate_synapse_to_fabric, migrate_spark_pools_to_fabric, provision_notebooks) lack confirmation or dry-run safety mechanisms. While migrate_synapse_to_fabric and transform_notebooks offer a 'dryRun' boolean parameter, the lack of confirmation gates before execution risks catastrophic agent errors.
Tool descriptions often lack clarity on WHEN to use the tool vs alternatives. For example, list_fabric_capacities and fabric_list_capacities appear to be duplicates; the descriptions do not explain the distinction. This forces LLMs to guess which to call.
Bearer token credentials exposed as a tool parameter (bearerToken) in multiple tools. Per security patterns, credentials must never appear in tool parameters, use server-side secret injection instead. Tokens in parameters leak into logs and prompt traces.
No error handling guidance visible in tool definitions. Tools do not document what errors can occur, what they mean, or what the LLM should do (retry, ask user, abandon). Example: discover_synapse_workspace could fail due to invalid subscription or insufficient permissions, neither case is documented.
Parameters accept JSON strings (inventoryJson, transformedNotebooksJson, synapsePoolsJson, synapseComputeSummaryJson) instead of structured objects. This forces LLMs to serialize/deserialize JSON, increasing error surface. Tools should accept structured input with explicit schemas.
Tool composition issues: migrate_synapse_to_fabric appears to subsume multiple subtasks (discovery, transform, provision, capacity assignment). Complex orchestrations should be decomposed so agents can compose them, currently the LLM cannot skip steps or retry individual phases.
Some parameters lack type constraints and validation guidance. Example: startDate and endDate in synapse_compute_spend are documented as 'YYYY-MM-DD' format but lack explicit format constraints or validation error examples. LLMs may pass invalid dates.