Which integrations are available for this server?

Allows the server to scan and discover SSIS packages (.dtsx files) directly from local or remote Git repositories. Enables discovery and processing of SSIS packages stored within GitHub repositories for migration analysis. Exposes SSIS migration tools directly within GitHub Copilot, allowing users to scan, analyze, and convert packages via chat. Utilizes AI models to automatically translate SSIS C# Script Tasks into Python code during the Azure Data Factory conversion process.

How do I use ssis-adf-agent?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ssis-adf-agent Convert SalesETL.dtsx to Azure Data Factory JSON artifacts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ssis-adf-agent

by tyrrestrup

Overview Schema Related Servers Score Discussions

Python

Hybrid

SSIS → ADF Agent

Python License

An MCP (Model Context Protocol) server that reads SSIS packages (.dtsx) and converts them to Azure Data Factory (ADF) JSON artifacts, exposed as tools directly inside GitHub Copilot.

All generated artifacts follow Microsoft Recommended patterns from learn.microsoft.com.

.dtsx file(s)  ──┐
                  │      ┌────────────────────────┐
SQL Agent jobs ───┤      │   Optional configs:    │
                  ├─────▶│  • ESI tables JSON     │
  Config files ───┘      │  • Schema remap JSON   │
                         │  • Shared artifacts dir │
                         └──────────┬─────────────┘
                                    ▼
                    ┌─────────────────────────────┐
                    │      ssis-adf-agent         │  ← MCP stdio server
                    │                             │
                    │  scan → analyze → convert   │
                    │      → validate → deploy    │
                    │                             │
                    │  Detects:                   │
                    │  • Cross-DB / linked server  │
                    │  • Delta / MERGE patterns    │
                    │  • CDM-layer logic           │
                    │  • ESI reuse candidates      │
                    └──────────┬──────────────────┘
                               ▼
                    ADF JSON artifacts
            (pipeline / linkedService / dataset /
             dataflow / trigger / stubs)
                               ▼
                    Azure Data Factory

Related MCP server: MigratorXpress MCP Server

Prerequisites

Requirement	Version / Notes
Python	3.11 or later
pip	Included with Python; or use uv / hatch
Git	Required if scanning packages from a Git repository
ODBC Driver for SQL Server	17 or later — required only when scanning packages from SQL Server (`msdb`)
Azure CLI	`az` — required for `az login` when deploying from a developer machine
VS Code	Latest stable
GitHub Copilot extension	With agent / MCP support enabled

Installation

Clone the repository and install in editable mode (recommended for development):

git clone https://github.com/chsimons_microsoft/ssis_adf_agent.git
cd ssis_adf_agent
pip install -e .

To also install development tools (pytest, ruff, mypy):

pip install -e ".[dev]"

To enable automatic C# → Python translation of Script Tasks via Azure OpenAI:

pip install -e ".[llm]"

Verify the installation:

ssis-adf-agent --help

Note: When the package is published to PyPI, you can install it with pip install ssis-adf-agent without cloning the repository.

Registering as an MCP Server in VS Code

Add the server to your VS Code settings.json so GitHub Copilot can discover it as a set of agent tools.

Open Command Palette (Ctrl+Shift+P) → Preferences: Open User Settings (JSON)
Add the following inside the root object:

{
  "github.copilot.chat.experimental.mcpServers": {
    "ssis-adf-agent": {
      "type": "stdio",
      "command": "ssis-adf-agent",
      "args": []
    }
  }
}

If you installed into a virtual environment, replace "command": "ssis-adf-agent" with the full path to the script, e.g. "C:\\path\\to\\.venv\\Scripts\\ssis-adf-agent.exe" (Windows) or "/path/to/.venv/bin/ssis-adf-agent" (macOS/Linux).

Restart VS Code (or reload the window: Ctrl+Shift+P → Developer: Reload Window).
Open Copilot Chat, switch to Agent mode, and verify that the five tools appear:
- scan_ssis_packages
- analyze_ssis_package
- convert_ssis_package
- validate_adf_artifacts
- deploy_to_adf

Trying It Out — Samples Directory

The samples/ directory is intended as a convenient drop zone for .dtsx files you want to experiment with locally.

Copy one or more .dtsx files into samples/:

samples/
  MyETLPackage.dtsx
  LoadDimCustomer.dtsx

When using any tool that requires a package_path or path_or_connection, supply the absolute path to the file or directory. For example:
- Windows: C:\Users\you\ssis_adf_agent\samples\MyETLPackage.dtsx
- macOS/Linux: /home/you/ssis_adf_agent/samples/MyETLPackage.dtsx
For output, create a directory alongside samples/ (e.g. adf_output/) to keep generated artifacts separate from source packages.

The samples/ directory is .gitignore-friendly — add your test packages there without worrying about committing proprietary SSIS files.

Usage — End-to-End Walkthrough

All five tools are invoked from GitHub Copilot Chat in Agent mode. Type your request in natural language and Copilot will call the appropriate tool(s). The sections below show what each tool does and the key parameters it accepts.

1. Scan for packages

Tool: scan_ssis_packages

Discovers all .dtsx files from a local directory, a Git repository, or SQL Server (msdb).

Example prompts:

Scan C:\Projects\LegacyETL for all SSIS packages.

Scan the git repo at https://github.com/myorg/etl-packages for SSIS packages on the release branch.

List all SSIS packages stored in SQL Server at SERVER=MYSERVER;DATABASE=msdb.

Key parameters:

Parameter	Required	Description
`source_type`	Yes	`local`, `git`, or `sql`
`path_or_connection`	Yes	Local directory path, Git repo URL, or SQL connection string
`recursive`	No	Search subdirectories (default: `true`)
`git_branch`	No	Branch to check out when `source_type` is `git` (default: `main`)

2. Analyze a package

Tool: analyze_ssis_package

Produces a complexity score, gap analysis, component inventory, cross-database/linked server detection, CDM pattern flags, and optional ESI reuse candidates for a single package. Run this before converting to understand the scope of manual work required.

Example prompts:

Analyze the SSIS package at C:\Projects\LegacyETL\LoadFactSales.dtsx and tell me how complex it is.

Analyze C:\Projects\LegacyETL\LoadFactSales.dtsx with ESI tables config at C:\config\esi_tables.json.

Key parameters:

Parameter	Required	Description
`package_path`	Yes	Absolute path to the `.dtsx` file
`esi_tables_path`	No	Path to a JSON file mapping source systems to ESI-available tables (see ESI Reuse Detection)

Complexity score guide:

Score	Label	Typical Effort
0–25	Low	< 1 day
26–50	Medium	1–3 days
51–75	High	3–5 days
76–100	Very High	1+ weeks

Score drivers: Script Tasks (+20 each), Data Flow Tasks (+8 each), ForEach/ForLoop containers (+5 each), unknown task types (+10 each), linked server references (+8 each), cross-database references (+3 each).

Key output:

Complexity score and effort label
Component inventory (task types, connection managers, parameters, variables)
Gap analysis grouped by severity: manual_required / warning / info
Recommended execution order of tasks

3. Convert a package

Tool: convert_ssis_package

Converts a single .dtsx file to a complete set of ADF JSON artifacts.

Example prompt:

Convert C:\Projects\LegacyETL\LoadFactSales.dtsx to ADF artifacts and write them to C:\adf_output\LoadFactSales.

Key parameters:

Parameter	Required	Description
`package_path`	Yes	Absolute path to the `.dtsx` file
`output_dir`	Yes	Directory to write artifacts into
`generate_trigger`	No	Emit a `ScheduleTrigger` template (default: `true`)
`llm_translate`	No	Call Azure OpenAI to translate C# Script Tasks to Python. Default: `false`
`on_prem_ir_name`	No	Integration Runtime name for on-prem connections (default: `SelfHostedIR`)
`auth_type`	No	Default auth for Azure SQL linked services: `SystemAssignedManagedIdentity` (default), `SQL`, or `ServicePrincipal`
`use_key_vault`	No	Use Azure Key Vault secret references for passwords (default: `false`)
`kv_ls_name`	No	Name for the Key Vault linked service (default: `LS_KeyVault`)
`kv_url`	No	Azure Key Vault base URL (default: `https://TODO.vault.azure.net/`)
`esi_tables_path`	No	Path to ESI tables config JSON for reuse detection
`schema_remap_path`	No	Path to schema remap JSON for database consolidation
`shared_artifacts_dir`	No	Shared directory for cross-package linked service/dataset deduplication
`pipeline_prefix`	No	Prefix for pipeline names (default: `PL_`)

Sub-folders are created automatically inside output_dir. See Generated Artifact Structure.

4. Validate generated artifacts

Tool: validate_adf_artifacts

Checks the generated JSON files for structural correctness (required fields, valid activity references) before touching Azure. Always validate before deploying.

Example prompt:

Validate the ADF artifacts in C:\adf_output\LoadFactSales.

Key parameter:

Parameter	Required	Description
`artifacts_dir`	Yes	Directory containing the generated ADF JSON files

Fix any reported issues in the JSON files, then validate again before proceeding to deployment.

5. Deploy to Azure Data Factory

Tool: deploy_to_adf

Deploys the validated artifacts to an existing Azure Data Factory instance. Deployment order is enforced automatically: linked services → datasets → data flows → pipelines → triggers.

Important: Always run a dry run first to confirm what will be deployed without making any Azure API calls.

Example prompt (dry run):

Do a dry run deployment of C:\adf_output\LoadFactSales to my ADF instance named my-adf in resource group rg-data-prod, subscription 00000000-0000-0000-0000-000000000000.

Example prompt (live deployment):

Deploy C:\adf_output\LoadFactSales to ADF instance my-adf in resource group rg-data-prod, subscription 00000000-0000-0000-0000-000000000000.

Key parameters:

Parameter	Required	Description
`artifacts_dir`	Yes	Directory containing generated ADF JSON artifacts
`subscription_id`	Yes	Azure subscription GUID
`resource_group`	Yes	Azure resource group name
`factory_name`	Yes	Azure Data Factory instance name
`dry_run`	No	`true` to log only without calling Azure APIs (default: `false`)

Triggers are always deployed in Stopped state. Activate them manually in the ADF Studio after validating pipeline runs.

Enterprise Features

These features were designed for large-scale enterprise SSIS migrations where packages share connections, target consolidated databases, or operate alongside existing data platforms (ESI, CDM layers).

Self-Hosted Integration Runtime

On-prem connections are automatically detected (heuristics: localhost, IP addresses, non-.database.windows.net server names). These connections generate SqlServer linked services with a connectVia reference to a Self-Hosted Integration Runtime. Use on_prem_ir_name to override the default name SelfHostedIR.

Azure Key Vault Secrets

When use_key_vault=true, linked services reference Azure Key Vault secrets instead of embedding credentials:

{
  "password": {
    "type": "AzureKeyVaultSecret",
    "store": { "referenceName": "LS_KeyVault", "type": "LinkedServiceReference" },
    "secretName": "conn-MyDatabase-password"
  }
}

A Key Vault linked service (LS_KeyVault) is auto-generated. Customize the name with kv_ls_name and the vault URL with kv_url.

Cross-Package Deduplication

When migrating multiple SSIS packages that share connection managers, pass shared_artifacts_dir to avoid duplicate linked services and datasets:

Convert LoadDimCustomer.dtsx with shared_artifacts_dir=C:\output\shared
Convert LoadFactSales.dtsx with shared_artifacts_dir=C:\output\shared

The generator writes each linked service / dataset only once. Subsequent packages that reference the same connection reuse the existing file.

Schema Remapping (Database Consolidation)

When consolidating multiple on-prem databases into a single Azure SQL database, provide a schema remap config:

{
  "StagingDB": "staging",
  "ReportingDB": "reporting",
  "DWDB": "dw"
}

Keys are original database names; values are target schemas. Pass the file path via schema_remap_path. The converter replaces cross-database references in SQL text and qualified table names in datasets.

ESI Reuse Detection

If your organization maintains an ESI (Enterprise Source Integration) layer, you can provide a JSON config mapping source systems to tables already available in the ESI Azure SQL layer:

{
  "source_system": "SAP",
  "esi_database": "ESI_SAP",
  "tables": ["VBAK", "VBAP", "MARA", "KNA1"]
}

Pass this file via esi_tables_path (available on both analyze and convert tools). The analyzer produces INFO-level gap items identifying data flow sources that could read from ESI instead of pulling from the on-prem source via SHIR.

CDM Pattern Flagging

The analyzer automatically detects Common Data Model (CDM) layer patterns:

Multi-source joins \u2014 data flows with 3+ sources feeding a Merge Join or Union All
Aggregation \u2014 data flows with grouped aggregation transformations
Cross-system enrichment \u2014 joins between sources from different connection managers
Denormalization \u2014 3+ lookup transformations in a single data flow

Detected patterns produce INFO-level gap items with [CDM REVIEW] recommendations and cdm-review-required pipeline annotations. These are informational \u2014 they help teams decide whether to migrate the logic as-is or replace it with existing CDM entities.

SQL Agent Schedule Mapping

When the SSIS package source is a SQL Server (sql_server source type in scan_ssis_packages), the tool reads SQL Agent job schedules from msdb. The converted trigger uses the mapped ADF recurrence:

SQL Agent `freq_type`	ADF Recurrence
4 (Daily)	`Day` with `interval` from `freq_interval`
8 (Weekly)	`Week` with weekday schedule from bitmask
16 (Monthly, day-of-month)	`Month` with day schedule
32 (Monthly, relative)	`Month` \u2014 flag for manual review

If no SQL Agent schedule is available, the trigger falls back to a placeholder daily-at-midnight schedule.

LLM-Powered Script Task Translation

SSIS Script Tasks contain C# (or VB.NET) code that cannot be rule-based converted. By default the converter generates a Python Azure Function stub with TODO comments and the original source embedded as comments. When llm_translate=true is passed to convert_ssis_package, the agent extracts the embedded C# source from the DTSX binary blob and calls Azure OpenAI to produce a working Python implementation body.

How it works

Extraction — The parser decodes the base64-encoded ZIP blob inside DTS:ObjectData/ScriptProject/BinaryData, unzips it, and reads all .cs / .vb source files (excluding AssemblyInfo and designer files).
Translation — CSharpToPythonTranslator sends the source to Azure OpenAI Chat Completions with a structured prompt that preserves business logic and replaces unsupported patterns (SQL calls, file I/O, SMTP) with # TODO comments pointing to Azure equivalents.
Stub output — The generated stubs/<FunctionName>/__init__.py contains the translated Python body. The original C# is preserved as line comments below the implementation for reference.
Graceful fallback — If the API key is not configured, the model deployment is unavailable, or the DTSX uses a self-closing stub format (no embedded source), the converter falls back to the standard TODO stub without raising an error. A warning comment is embedded in the stub file.

Required environment variables

Variable	Description	Default
`AZURE_OPENAI_ENDPOINT`	Your Azure OpenAI resource URL, e.g. `https://my-resource.openai.azure.com/`	required
`AZURE_OPENAI_API_KEY`	Azure OpenAI API key	required
`AZURE_OPENAI_DEPLOYMENT`	Model deployment name	`gpt-4o`

Installation

The openai SDK is an optional dependency — install it alongside the package:

pip install "ssis-adf-agent[llm]"

Example prompt

Convert C:\Projects\LegacyETL\LoadFactSales.dtsx to C:\adf_output\LoadFactSales and translate all Script Tasks to Python using Azure OpenAI.

Note: Translated code should always be reviewed before deploying to production. The LLM preserves control flow and business logic but replaces infrastructure calls (SQL, file I/O, SMTP) with # TODO placeholders that require manual completion.

Using the Built-in Prompt Files

Three reusable prompt files are included in .vscode/ and can be invoked directly from Copilot Chat to run the full workflow with guided inputs.

Prompt File	Mode	Description
`analyze_packages.prompt.md`	Agent	Scan a source, then analyze every package found and produce a prioritized conversion report
`convert_package.prompt.md`	Agent	Analyze, convert, and validate a single package; produces a Markdown summary with a manual-steps checklist
`deploy_adf.prompt.md`	Agent	Validate artifacts and deploy to ADF with optional dry-run

To invoke from Copilot Chat:

Open Copilot Chat (Ctrl+Alt+I)
Switch to Agent mode
Type / and select the prompt file from the list, or type the prompt name
Fill in the prompted inputs (package path, output directory, Azure details, etc.)

Authentication

The deploy_to_adf tool uses DefaultAzureCredential, which tries the following in order:

Priority	Method	When to use
1	Environment variables	CI/CD pipelines (service principal)
2	Workload Identity	Azure-hosted compute (AKS, etc.)
3	Azure CLI (`az login`)	Local developer machines
4	Azure PowerShell	Local developer machines

For local development, the simplest approach is:

az login

For CI/CD pipelines, set these environment variables for a service principal:

Variable	Description
`AZURE_CLIENT_ID`	Service principal application (client) ID
`AZURE_CLIENT_SECRET`	Service principal secret
`AZURE_TENANT_ID`	Azure Active Directory tenant ID

The service principal must have the Data Factory Contributor role on the target ADF instance.

Azure OpenAI (for LLM Script Task translation)

Set the following environment variables before calling convert_ssis_package with llm_translate=true:

# Windows (PowerShell)
$env:AZURE_OPENAI_ENDPOINT   = "https://my-resource.openai.azure.com/"
$env:AZURE_OPENAI_API_KEY    = "<your-key>"
$env:AZURE_OPENAI_DEPLOYMENT = "gpt-4o"   # optional, defaults to gpt-4o

# macOS / Linux
export AZURE_OPENAI_ENDPOINT="https://my-resource.openai.azure.com/"
export AZURE_OPENAI_API_KEY="<your-key>"
export AZURE_OPENAI_DEPLOYMENT="gpt-4o"

SSIS Component Mapping Reference

SSIS Component	ADF Equivalent	Notes
Execute SQL Task	Stored Procedure / Script / Lookup Activity	Depends on `ResultSetType` and SQL pattern
Data Flow Task (simple)	Copy Activity	Single source → single destination. Sink pattern varies: `insert` (full load), `upsert` with keys (delta/merge). Retry policy: 2 retries, 60s interval.
Data Flow Task (complex)	Execute Data Flow Activity (Mapping Data Flow)	Multiple sources, transformations, or fanout. `READ_UNCOMMITTED` isolation, `errorHandlingOption: stopOnFirstError`.
Execute Package Task	Execute Pipeline Activity	Child pipeline must also be converted
Script Task (C# / VB)	Azure Function Activity	Stub generated at `stubs/<FunctionName>/__init__.py`. When `llm_translate=true`, C# source is extracted from the DTSX and translated to Python via Azure OpenAI; otherwise a `TODO` stub is generated.
ForEach Loop Container	ForEach Activity	Expression varies by enumerator type
For Loop Container	SetVariable (init) + Until Activity + SetVariable (increment)	Condition logic is inverted
Sequence Container	Flattened into parent with `dependsOn` chaining	No ADF equivalent
File System Task	Copy Activity (Azure paths) or Web Activity → Azure Function	Local paths need Azure-path substitution
Execute Process Task	Web Activity → Azure Function	Manual: wrap process call in a Function
FTP Task	Copy Activity via FTP connector	Requires FTP linked service
Send Mail Task	Logic App / Web Activity	No native ADF equivalent
Event Handler (`OnError`)	Pipeline fails path / error handling	Converted to sub-pipeline reference
Event Handler (`OnPostExecute`)	Succeeded dependency path	Converted to sub-pipeline reference
Connection Manager (Azure SQL)	Linked Service (`AzureSqlDatabase`)	Microsoft Recommended version: `server`/`database`/`authenticationType`. Default auth: `SystemAssignedManagedIdentity`.
Connection Manager (on-prem SQL)	Linked Service (`SqlServer`)	Auto-detected. Uses Self-Hosted IR with `pooling: false`.
SQL Agent Job Schedule	Schedule Trigger	Mapped from `msdb` `freq_type`/`freq_interval`. Falls back to placeholder if unavailable.

Generated Artifact Structure

convert_ssis_package writes the following directory structure under output_dir:

<output_dir>/
  pipeline/
    PL_<PackageName>.json       ← Main ADF pipeline (prefix configurable)
  linkedService/
    LS_<ConnectionName>.json    ← Microsoft Recommended version format
    LS_KeyVault.json            ← Auto-generated when use_key_vault=true
  dataset/
    DS_<DatasetName>.json       ← Uses schema+table (not deprecated tableName)
  dataflow/
    DF_<DataFlowName>.json      ← Mapping Data Flow with READ_UNCOMMITTED + error handling
  trigger/
    TR_<PackageName>.json       ← ScheduleTrigger (Stopped state); accurate if SQL Agent schedule provided
  stubs/
    <FunctionName>/
      __init__.py               ← Python stub with TODO blocks
      function.json             ← Azure Function binding definition

Linked Service Format

Linked services use the Microsoft Recommended version format with discrete properties instead of the legacy connectionString format:

{
  "type": "AzureSqlDatabase",
  "typeProperties": {
    "server": "myserver.database.windows.net",
    "database": "mydb",
    "encrypt": "mandatory",
    "trustServerCertificate": false,
    "authenticationType": "SystemAssignedManagedIdentity"
  }
}

For on-prem connections, the SqlServer connector type with Self-Hosted IR is used automatically:

{
  "type": "SqlServer",
  "typeProperties": {
    "server": "on-prem-server",
    "database": "mydb",
    "authenticationType": "Windows",
    "pooling": false
  },
  "connectVia": { "referenceName": "SelfHostedIR", "type": "IntegrationRuntimeReference" }
}

Dataset Format

Datasets use separate schema and table properties per Microsoft's recommendation:

{
  "type": "AzureSqlTable",
  "typeProperties": {
    "schema": "dbo",
    "table": "MyTable"
  }
}

Pipeline Annotations

Generated pipelines include automatic annotations based on detected patterns:

ssis-adf-agent — identifies the source tool
source-package:<name> — original SSIS package name
ingestion-pattern:delta or ingestion-pattern:merge — when delta/merge patterns detected
has-cross-db-references — when cross-database or linked server references found
cdm-review-required — when CDM-layer patterns detected
esi-reuse-candidate — when ESI reuse opportunities found

Manual Steps After Conversion

After running convert_ssis_package, review the following checklist before deploying:

Connection string passwords — packages with EncryptAllWithPassword protection level may have missing passwords. When use_key_vault=true, linked services reference Key Vault secrets — verify the secret names exist and are populated. Otherwise fill in plaintext credentials.
Script Task stubs — each stub in stubs/<FunctionName>/__init__.py contains TODO comments. If llm_translate=true was used, the stub contains LLM-translated Python. Deploy the Function to Azure Functions before running the pipeline.
Local file paths — File System Tasks that reference local paths have placeholder Azure Storage paths. Replace them with valid abfss:// or https:// URLs.
Trigger schedules — if no SQL Agent schedule was available, the trigger uses a placeholder daily-at-midnight schedule. Update it to match your production schedule. When SQL Agent metadata was provided, verify the mapped ADF recurrence matches the original.
Cross-database / linked server references — check the gap analysis for manual_required severity items. Replace linked server four-part names with Azure SQL elastic queries, external tables, or separate linked services. Remap three-part names if consolidating databases.
CDM review items — if the pipeline has a cdm-review-required annotation, coordinate with the CDM team to decide whether the transformation logic should migrate as-is or be replaced by existing CDM-layer entities.
ESI reuse candidates — if the pipeline has an esi-reuse-candidate annotation, review whether reading from the ESI Azure SQL layer is preferable to re-staging from the on-prem source via SHIR.
Upsert key columns — Copy Activities with writeBehavior: "upsert" include detected key columns. Verify these match the target table's unique key. Replace TODO_KEY_COLUMN placeholders where keys could not be auto-detected.
Re-validate — run validate_adf_artifacts again after all manual edits.
Activate triggers — triggers are deployed in Stopped state. Activate them in ADF Studio only after a successful pipeline smoke-test.

Development

Install development dependencies:

pip install -e ".[dev]"

Run tests:

pytest

Lint:

ruff check .

Type-check:

mypy ssis_adf_agent/

The project targets Python 3.11+, uses ruff with line-length = 100, and enforces mypy --strict.

License

This project is licensed under the MIT License.

MIT License

Copyright (c) 2026 chsimons_microsoft

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Available Tools

5 tools

analyze_ssis_packageA

Analyze a single SSIS package (.dtsx file) and return a detailed report including: complexity score (0-100), effort estimate (Low/Medium/High/Very High), component inventory, gap analysis (items needing manual work), cross-database/linked server references, CDM pattern detection, ESI reuse candidates, and dependency execution order.

ParametersJSON Schema

Name	Required	Description	Default
`package_path`	Yes	Absolute path to the .dtsx file.
`esi_tables_path`	No	Optional path to a JSON file mapping source_system → table list for ESI reuse detection. Format: {"PHINEOS": ["TocPartyAddress", "TLBenefit"]}.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It describes the output content but lacks behavioral details such as whether it's a read-only analysis, if it modifies the package, performance characteristics, error handling, or authentication needs. This is inadequate for a tool with no annotation coverage.

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

Conciseness5/5

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

The description is a single, dense sentence that efficiently lists all key output components without waste. It is front-loaded with the core action and resource, making it easy to scan and understand.

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

Completeness3/5

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

Given no annotations and no output schema, the description partially compensates by detailing the report contents. However, it lacks information on behavioral traits, error cases, or output structure, leaving gaps for a tool with two parameters and no structured output documentation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters fully. The description does not add any meaning beyond what the schema provides, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

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 verb ('analyze') and resource ('a single SSIS package (.dtsx file)'), and distinguishes it from siblings by specifying it analyzes a single package rather than scanning multiple packages (scan_ssis_packages) or converting/deploying (convert_ssis_package, deploy_to_adf).

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

Usage Guidelines3/5

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

The description implies usage by listing what the tool returns, but does not explicitly state when to use it versus alternatives like scan_ssis_packages (for multiple packages) or validate_adf_artifacts (for ADF validation). No exclusions or prerequisites are mentioned.

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

convert_ssis_packageA

Convert a single SSIS package (.dtsx file) to Azure Data Factory JSON artifacts. Generates: pipeline JSON, linked service JSONs, dataset JSONs, mapping data flow JSONs, trigger JSONs, and Azure Function stubs for Script Tasks. Supports Self-Hosted IR, Key Vault secrets, Microsoft Recommended linked service format, schema remapping, ESI reuse detection, CDM pattern flagging, and cross-package dedup. Returns a summary of generated files and any warnings.

ParametersJSON Schema

Name	Required	Description	Default
`package_path`	Yes	Absolute path to the .dtsx file to convert.
`output_dir`	Yes	Directory to write ADF artifacts to. Sub-folders pipeline/, linkedService/, dataset/, dataflow/, trigger/, stubs/ will be created automatically.
`generate_trigger`	No	Whether to emit a template ScheduleTrigger JSON. Default: true.
`llm_translate`	No	If true, call Azure OpenAI to translate C# Script Task source code to Python in the generated Azure Function stubs. Requires AZURE_OPENAI_ENDPOINT and AZURE_OPENAI_API_KEY environment variables. Falls back gracefully if unavailable. Default: false.
`on_prem_ir_name`	No	Integration Runtime name for on-prem connections. Default: 'SelfHostedIR'.	SelfHostedIR
`auth_type`	No	Default authentication type for Azure SQL linked services. Default: 'SystemAssignedManagedIdentity'.	SystemAssignedManagedIdentity
`use_key_vault`	No	Use Azure Key Vault secret references for passwords/connection strings. Default: false.
`kv_ls_name`	No	Name for the Key Vault linked service. Default: 'LS_KeyVault'.	LS_KeyVault
`kv_url`	No	Azure Key Vault base URL. Default: 'https://TODO.vault.azure.net/'.	https://TODO.vault.azure.net/
`esi_tables_path`	No	Optional path to a JSON file mapping source_system → table list for ESI reuse detection.
`schema_remap_path`	No	Optional path to a JSON file mapping old schema prefixes to new ones for database consolidation. Format: {"StagingDB.dbo": "ConsolidatedDB.staging"}.
`shared_artifacts_dir`	No	Optional shared directory for cross-package linked service/dataset deduplication. When converting multiple packages, point all to the same shared dir.
`pipeline_prefix`	No	Prefix for pipeline names. Default: 'PL_'.	PL_

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it generates multiple JSON artifacts and stubs, returns a summary and warnings, and supports specific features like Self-Hosted IR and cross-package dedup. However, it lacks details on error handling, performance, or side effects like file system changes.

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

Conciseness5/5

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

The description is front-loaded with the core purpose in the first sentence, followed by a concise list of generated artifacts and supported features. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.

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

Completeness4/5

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

Given the tool's complexity (13 parameters, no annotations, no output schema), the description is reasonably complete. It covers the conversion process, outputs, and key features, but lacks details on return values (beyond 'summary' and 'warnings') and error conditions, which could be important for a tool with many parameters and no output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 13 parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific action ('Convert a single SSIS package') and resource ('.dtsx file') to output ('Azure Data Factory JSON artifacts'), listing the exact types generated. It distinguishes from sibling tools like analyze_ssis_package or deploy_to_adf by focusing on conversion rather than analysis or deployment.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives like analyze_ssis_package or validate_adf_artifacts. It mentions the tool's capabilities but does not specify prerequisites, ideal scenarios, or when other tools might be more appropriate, leaving usage context implied at best.

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

deploy_to_adfA

Deploy ADF JSON artifacts from a local directory to an Azure Data Factory instance. Deploys in correct dependency order: linked services → datasets → data flows → pipelines → triggers. Triggers are deployed in Stopped state and must be activated manually. Uses DefaultAzureCredential (az login, managed identity, or service principal env vars).

ParametersJSON Schema

Name	Required	Description
`artifacts_dir`	Yes	Directory containing generated ADF JSON artifacts.
`subscription_id`	Yes	Azure subscription ID.
`resource_group`	Yes	Azure resource group name containing the ADF instance.
`factory_name`	Yes	Name of the Azure Data Factory to deploy to.
`dry_run`	No	If true, validate and log but do not call Azure APIs. Default: false.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and excels by disclosing critical behavioral traits: the deployment order (linked services → datasets → data flows → pipelines → triggers), that triggers are deployed in Stopped state requiring manual activation, and the authentication method (DefaultAzureCredential with specific options). This goes well beyond basic functionality.

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

Conciseness5/5

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

The description is perfectly front-loaded with the core purpose in the first sentence, followed by essential behavioral details. Every sentence adds value: deployment order, trigger state, and authentication method. There's zero wasted text.

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

Completeness4/5

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

For a complex deployment tool with no annotations and no output schema, the description is highly complete—covering purpose, behavior, and authentication. It lacks only minor details like error handling or response format, which would be needed for a perfect score given the tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description doesn't add any parameter-specific meaning beyond what's in the schema (e.g., it doesn't clarify artifact formats or directory structure). This meets the baseline for high schema coverage.

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 specific action ('Deploy ADF JSON artifacts') and resource ('to an Azure Data Factory instance'), with precise scope ('from a local directory'). It distinguishes from sibling tools like 'validate_adf_artifacts' by focusing on deployment rather than validation or SSIS-related tasks.

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 provides clear context for when to use this tool (deploying artifacts to ADF) and implies an alternative through the 'dry_run' parameter for validation without deployment. However, it doesn't explicitly state when NOT to use it or compare it to other deployment methods, keeping it from a perfect score.

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

scan_ssis_packagesA

Discover all SSIS packages (.dtsx files) from a given source. Returns a JSON list of found packages with name, path, and basic metadata. source_type must be one of: 'local', 'git', 'sql'.

ParametersJSON Schema

Name	Required	Description	Default
`source_type`	Yes	Where to find .dtsx files.
`path_or_connection`	Yes	For 'local': absolute filesystem directory path. For 'git': repository URL or local path. For 'sql': SQL Server connection string or 'SERVER=...;DATABASE=msdb'.
`recursive`	No	Search subdirectories (local/git only). Default: true.
`git_branch`	No	Branch to check out (git source only). Default: 'main'.	main

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the discovery action and return format, but doesn't mention important behavioral aspects like whether this is a read-only operation, potential performance impacts for large directories, authentication requirements for git/SQL sources, or error handling. The description adds basic context but lacks comprehensive behavioral details.

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

Conciseness5/5

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

The description is perfectly concise with two sentences that each earn their place: the first states the core purpose and output, the second provides critical constraint information. It's front-loaded with the main functionality and wastes no words on redundant information.

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

Completeness3/5

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

Given the tool's moderate complexity (4 parameters, multiple source types) and no annotations or output schema, the description is adequate but incomplete. It covers the basic purpose and constraints but lacks information about authentication needs, error conditions, performance characteristics, and what 'basic metadata' includes. For a discovery tool with multiple source types, more behavioral context would be helpful.

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

Parameters3/5

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

With 100% schema description coverage, the input schema already fully documents all 4 parameters. The description adds minimal value beyond the schema by mentioning the source_type enum values and that it discovers '.dtsx files', but doesn't provide additional semantic context about parameter interactions or usage patterns beyond what's in the schema descriptions.

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 specific action ('discover all SSIS packages'), target resource ('.dtsx files'), and output format ('JSON list of found packages with name, path, and basic metadata'). It distinguishes itself from siblings like analyze_ssis_package (which analyzes rather than discovers) and convert_ssis_package (which converts rather than discovers).

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 provides clear context about when to use this tool by specifying the source_type options and what it returns. However, it doesn't explicitly state when NOT to use it or mention alternatives among the sibling tools (e.g., use analyze_ssis_package for detailed analysis instead of just discovery).

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

validate_adf_artifactsA

Validate ADF JSON artifacts in a directory for structural correctness. Checks that required fields (name, properties, activities) are present. Returns a list of validation issues found, or a success message if all artifacts are valid.

ParametersJSON Schema

Name	Required	Description	Default
`artifacts_dir`	Yes	Directory containing the generated ADF JSON artifacts.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (validates for structural correctness) and what it returns (list of issues or success message), but doesn't mention error handling, performance characteristics, permission requirements, or whether it modifies files. It provides basic behavioral context but lacks depth.

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

Conciseness5/5

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

Three sentences with zero waste: first states purpose, second specifies validation criteria, third describes return behavior. Every sentence earns its place by adding distinct information. The description is appropriately sized and front-loaded with the core functionality.

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

Completeness4/5

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

For a single-parameter validation tool with no annotations and no output schema, the description provides adequate context about what it validates and what it returns. It could be more complete by specifying validation error formats or success message structure, but covers the essential functionality given the tool's relative simplicity.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the single parameter. The description adds minimal value beyond what the schema provides, only reinforcing that it's for 'generated ADF JSON artifacts' without adding format details or constraints. Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('validate'), target resource ('ADF JSON artifacts in a directory'), and scope ('structural correctness'). It distinguishes from siblings by focusing on validation rather than analysis, conversion, deployment, or scanning operations.

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

Usage Guidelines3/5

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

The description implies usage context (when you need to check ADF JSON artifacts for structural issues) but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about when NOT to use it or what specific scenarios warrant validation.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Apr 13, 2026
- First observedanalyze_ssis_package
- First observedconvert_ssis_package
- First observeddeploy_to_adf
- First observedscan_ssis_packages
- First observedvalidate_adf_artifacts

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a distinct and non-overlapping purpose: analyze_ssis_package examines SSIS packages for metrics and insights, convert_ssis_package transforms them to ADF JSON, deploy_to_adf deploys those artifacts, scan_ssis_packages discovers packages, and validate_adf_artifacts checks JSON validity. The descriptions clearly differentiate their functions, eliminating any ambiguity in tool selection.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun structure: analyze_ssis_package, convert_ssis_package, deploy_to_adf, scan_ssis_packages, and validate_adf_artifacts. The naming is predictable and aligns well with the actions each tool performs, making the set easy to navigate and understand.

Tool Count5/5

With 5 tools, this server is well-scoped for its purpose of migrating and managing SSIS packages to Azure Data Factory. Each tool serves a critical step in the workflow—discovery, analysis, conversion, validation, and deployment—without being overly sparse or bloated, making the count ideal for the domain.

Completeness5/5

The tool set provides complete coverage for the SSIS to ADF migration lifecycle: it starts with scanning and analyzing packages, converts them to ADF artifacts, validates the output, and deploys to Azure. There are no obvious gaps, as it supports the entire process from source discovery to deployment, ensuring agents can handle the migration end-to-end.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

CData Connect AIOAuth
com.cdata
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
Databases RAG Systems Cloud Platforms
2
Azure DevOps (ADO)OAuth
io.github.PremierInc
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
CI/CD & DevOps Version Control Project Management
21,997
Unified.to MCP Server C
to.unified.docs
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
App Automation Agent Orchestration Developer Tools
2
Google Big Query A
com.googleapis.bigquery
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
Databases Cloud Platforms Search
63

Related MCP Servers

MCP X++ Server
Developer Tools ERP Systems
astra-bright
F
license
Not graded
quality
D
maintenance
An MCP server for Microsoft Dynamics 365 Finance & Operations that enables the creation, modification, and analysis of D365 objects like classes, tables, and forms. It integrates with Visual Studio 2022 to provide tools for X++ code extraction, codebase search, and safe object deletion with dependency validation.
Updated 9 months ago (2025-12-09 20:57 UTC)
-
MigratorXpress MCP Server
Databases Developer Tools Data Platforms
arpe-io
A
license
A
quality
C
maintenance
This MCP server enables database migration between heterogeneous systems (Oracle, PostgreSQL, SQL Server, Netezza to PostgreSQL or SQL Server) through AI assistants by providing tools for command preview, execution, validation, and workflow suggestions.
Updated 6 months ago (2026-03-18 18:05 UTC)
6
MIT
data-detective
Databases Data Platforms Monitoring
themroats
A
license
Not graded
quality
D
maintenance
An MCP server that gives AI assistants the ability to connect to, query, profile, and monitor data sources — turning any LLM into an interactive data engineering copilot.
Updated 6 months ago (2026-02-28 23:16 UTC)
MIT
IFS Developer Intelligence MCP
Developer Tools RAG Systems Documentation Access
devansh-tntra
A
license
Not graded
quality
B
maintenance
An enterprise MCP server that transforms IFS Cloud documentation, local code, and Oracle error knowledge into AI-powered development intelligence, offering 60+ tools for code generation, review, error diagnosis, and deployment.
Updated 13 days ago (2026-08-24 05:21 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/tyrrestrup/ssis_adf_agent'

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

SSIS → ADF Agent

Table of Contents

Prerequisites

Installation

Registering as an MCP Server in VS Code

Trying It Out — Samples Directory

Usage — End-to-End Walkthrough

1. Scan for packages

2. Analyze a package

3. Convert a package

4. Validate generated artifacts

5. Deploy to Azure Data Factory

Enterprise Features

Self-Hosted Integration Runtime

Azure Key Vault Secrets

Cross-Package Deduplication

Schema Remapping (Database Consolidation)

ESI Reuse Detection

CDM Pattern Flagging

SQL Agent Schedule Mapping

LLM-Powered Script Task Translation

How it works

Required environment variables

Installation

Example prompt

Using the Built-in Prompt Files

Authentication

Azure OpenAI (for LLM Script Task translation)

SSIS Component Mapping Reference

Generated Artifact Structure

Linked Service Format

Dataset Format

Pipeline Annotations

Manual Steps After Conversion

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API