> ## Documentation Index > Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Astro Private Cloud MCP server skills > The skills the Astro Private Cloud MCP server ships, how to invoke them, and which route works in each client. A skill is Astronomer-authored guidance that the Model Context Protocol (MCP) server delivers to an AI agent on demand: a procedure the model follows, such as diagnosing a failed Dag (directed acyclic graph) or migrating a project to Airflow 3. Two skills ship with the Astro Private Cloud (APC) MCP server. > [!NOTE] > > **Astro Private Cloud 2.2** > > This feature was introduced in Astro Private Cloud 2.2. To access this feature, upgrade your Astro Private Cloud installation to 2.2 or later. > [!NOTE] > > A skill is guidance, not access. It adds nothing to the catalog: the enabled tool groups fix the available tools, and loading a skill grants no permission the caller didn't already have. A skill tells the model which tools to call and in what order, and the caller's own role still authorizes every call. See the [MCP server security posture](https://astronomer.io/docs/astro-private-cloud/v-2-x/apc-mcp-server-security.md). ## The two skills | Skill | What it is for | Reach for it when | Minimum tool groups | | - | - | - | - | | `debugging-dags` | Systematic diagnosis of a failed Dag: find the failure, read the error, categorize the cause, and propose a fix. Operator-based Deployments only. | A Dag fails to import or parse, or a task or run is failing and needs a root cause. | `airflow_read`, `platform_read` | | `migrating-airflow-2-to-3` | A guided migration of Airflow 2.x Dag code to Airflow 3.x: imports, operators, context keys, scheduling, and metadata-database access. | A user is upgrading a project to Airflow 3 or hitting 2-to-3 breaking changes. | `airflow_read`, `platform_read` | Each skill declares the minimum groups it needs, and enabling skills implies those read-only groups, so you don't have to add them to `enabledGroups` by hand. A skill implies only read-only groups and never turns on a destructive group. Beyond its minimum, `debugging-dags` also uses the remediation tools (`clear_dag_run`, `clear_task_instances`, and `delete_dag_run` in `airflow_destroy`) when that group is also enabled, and skips them when it is not. ## Enable skills Skills are off by default. A System Admin turns them on with one Helm chart value. ```yaml wrap theme={null} astronomer: mcpServer: skills: enabled: true ``` Enabling skills exposes the skill-delivery tools and both skills. Disabling them removes every skill surface at once: the per-skill prompts disappear, the skill tools leave the catalog and refuse any call, and the reference documents are no longer listed. For the full configuration, see [Set up and configure the MCP server](https://astronomer.io/docs/astro-private-cloud/v-2-x/apc-mcp-server-setup.md#enable-skills). ## Invoke a skill Both routes deliver the same guidance body from the same source, so they can't drift. ### As a prompt The user-invoked route. The server registers one prompt per skill, which a client that supports prompts surfaces as a menu entry or slash command. The user picks the skill, and the client sends the guidance to the model. Each prompt takes one required argument, `deployment`, the Deployment identifier the guidance applies to. Where a client supports it, the prompt is the better route because the user chooses the skill deliberately. Prompt support is uneven across clients. See [Client support](#client-support). ### With `load_skill` The model-facing route. `load_skill` is an ordinary MCP tool, so it works in every client, and the model can select a skill on its own. Skill tools: | Tool | Returns | | - | - | | `list_skills` | Every loadable skill, each with its name, description, and origin. | | `load_skill` | A skill's guidance body by name, the same content the prompt surfaces. | | `read_skill_file` | The text of a skill's reference file by name. See [Reference documents](#reference-documents). | All three are read-only and carry no permission requirement of their own. They return bundled content, not platform state, and belong to the `skills_load` group, which the skills toggle controls, so they exist whenever skills are enabled regardless of which other tool groups are on. An administrator can still remove an individual tool with `disabledTools`, which outranks the group. Disabling `load_skill` or `read_skill_file` drops that client fallback. See [Disable a single tool](https://astronomer.io/docs/astro-private-cloud/v-2-x/apc-mcp-server-setup.md#disable-a-single-tool). ## Reference documents A skill can ship supporting files. For example, `migrating-airflow-2-to-3` carries four reference documents (`config-changes.md`, `migration-checklist.md`, `migration-patterns.md`, and `removed-methods.md`), while `debugging-dags` carries none. A skill's body links each of its files by a `skill://` URI. A client that supports MCP resources can list and open these files directly. Where a client doesn't fetch resources, the model reaches the same content through `read_skill_file`, passing the skill name and the file's skill-relative path exactly as the skill body links it, for example `reference/config-changes.md`. The migration skill's body points the model at this fallback when a `skill://` link can't be opened, so the reference content reaches the model in every client. ## Client support Prompt and resource support depends on the client and its version, not on the server. The following was tested on 2026-10-06 with VS Code 1.136.1, Cursor 3.22.12, and Claude Desktop 2.19675.1. Re-test when a client updates. | Client | Prompt (pick a skill) | Reference documents (resources) | | - | - | - | | VS Code | Works. The skill appears as a slash command (`/mcp..`) in Copilot Chat's Agent mode, and a form collects the `deployment` value. Choose **Insert as text** for that value, not **Run as Command**. | Works. The documents appear under **Add Context**, and a person attaches one for the model to read. | | Cursor | Partial. The prompt is listed in the `/` menu, but Cursor doesn't collect the required `deployment` argument, so invoking it fails. The model falls back to `load_skill`. | Not surfaced. The model falls back to `read_skill_file`. | | Claude Desktop | Not surfaced. The client reaches the server through the `mcp-remote` relay and reports "Server not found". The model falls back to `load_skill`. | Not surfaced. The model falls back to `read_skill_file`. | Because tools work in every client, `load_skill` and `read_skill_file` cover any client where the prompt or resource route doesn't work. ## Update skills Skill content is bundled into the server image, pinned to a recorded version and surfaced as an image label. Nothing is mounted or fetched at runtime. Updating a skill means releasing a new image, not editing a file in the cluster. Customers can't modify the shipped skills in place.