adf-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AZURE_CLIENT_ID | Yes | The Azure AD app registration client ID (Service Principal appId). | |
| AZURE_TENANT_ID | Yes | The Azure AD tenant ID where the app registration resides. | |
| AZURE_CLIENT_SECRET | Yes | The Azure AD app registration client secret (Service Principal password). | |
| AZURE_SUBSCRIPTION_ID | Yes | The Azure subscription ID containing the Data Factory resources. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| health_checkA | Report that the MCP server is up and configuration loaded correctly. Useful as a first call from any MCP client (VS Code, Claude Code) to confirm the server started, before any Azure-dependent tools exist. |
| check_authA | Verify Azure Service Principal credentials by acquiring a real ARM token. Makes no Azure Data Factory calls - it only proves auth is configured correctly (tenant/client/secret valid, SPN enabled) before any ADF connectivity exists. Run this after health_check and before Step 3. |
| list_factoriesA | List all Data Factory instances the configured Service Principal can see. Returns each factory's resource_group, which every other ADF tool below requires as an input - call this first. |
| get_factoryC | Get details for a single Data Factory instance. |
| list_pipelinesA | List pipelines in a factory with a lightweight activity summary (count and names only - use get_pipeline for full detail on one). |
| get_pipelineC | Get a single pipeline's activity list. |
| list_pipeline_runsA | List pipeline runs in a time window (default: last 24 hours). Time values are ISO 8601 strings, e.g. "2026-08-22T00:00:00Z". Narrow results with pipeline_name and/or status (e.g. "Failed", "Succeeded", "InProgress"). Run messages are truncated to 500 chars here - use get_pipeline_run with a run_id from this result for full detail. |
| get_pipeline_runB | Get full, untruncated detail for a single pipeline run. Get run_id from list_pipeline_runs first. |
| list_activity_runsA | List every activity run within a pipeline run, each with error detail populated if it failed. Time window defaults to the last 7 days. Get run_id from list_pipeline_runs first. |
| get_failed_activity_detailsA | RCA convenience tool: returns only the activities that failed within a pipeline run, each with error_code/message/failure_type already extracted. Prefer this over list_activity_runs when you just need "what went wrong" rather than the full activity list. |
| list_triggersA | List every trigger in a factory with its current runtime state (Started/Stopped). |
| get_trigger_statusB | Get a single trigger's current runtime state. A stopped trigger is a common silent cause of "why didn't this pipeline run today" - the pipeline simply was never invoked, so pipeline-run history alone won't show it. |
| list_trigger_runsA | List trigger firing history (default: last 7 days). Omit trigger_name to see every trigger's runs, or narrow to one; filter by status (e.g. "Succeeded", "Failed") to spot triggers that fired but errored. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool targets a distinct layer of the ADF workflow: health/auth bootstrap, factory discovery, pipeline inspection, run monitoring, activity diagnostics, and trigger management. Even the closest pair, list_activity_runs and get_failed_activity_details, is clearly separated by scope and purpose.
The naming is overwhelmingly consistent with list_/get_ + resource noun in snake_case, and the run-related tools follow a clear pattern. health_check is a minor convention break compared to check_auth, but this is a small deviation in an otherwise predictable set.
13 tools is well-scoped for an ADF server: each tool maps to a distinct object hierarchy or bootstrap step without unnecessary redundancy. The count is substantial enough to cover real workflows but not bloated.
The set covers the read-only factory, pipeline, run, activity, and trigger diagnostics lifecycle well, including failure RCA. It lacks any management/remediation operations such as stopping or starting triggers, canceling runs, or rerunning pipelines, so it is slightly incomplete for full operational control.