Skip to main content
Glama
astronomer

astro-airflow-mcp

Official
by astronomer

get_dag_source

Retrieve the Python source code of an Apache Airflow DAG by providing its DAG ID. Returns the DAG file content and file token for inspection and debugging.

Instructions

Get the source code for a specific Apache Airflow DAG.

Use this tool when the user asks about:

  • "Show me the code for DAG X" or "What's the source of DAG Y?"

  • "How is DAG Z implemented?" or "What does the DAG file look like?"

  • "Can I see the Python code for this workflow?"

  • "What tasks are defined in the DAG code?"

Returns the DAG source file contents including:

  • content: The actual Python source code of the DAG file

  • file_token: Unique identifier for the source file

Args: dag_id: The ID of the DAG to get source code for

Returns: JSON with DAG source code and metadata

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dag_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • MCP tool registration for 'get_dag_source' via @mcp.tool() decorator. This is where the tool is exposed to MCP clients. The decorated function calls _get_dag_source_impl().
    @mcp.tool()
    def get_dag_source(dag_id: str) -> str:
        """Get the source code for a specific Apache Airflow DAG.
    
        Use this tool when the user asks about:
        - "Show me the code for DAG X" or "What's the source of DAG Y?"
        - "How is DAG Z implemented?" or "What does the DAG file look like?"
        - "Can I see the Python code for this workflow?"
        - "What tasks are defined in the DAG code?"
    
        Returns the DAG source file contents including:
        - content: The actual Python source code of the DAG file
        - file_token: Unique identifier for the source file
    
        Args:
            dag_id: The ID of the DAG to get source code for
    
        Returns:
            JSON with DAG source code and metadata
        """
        return _get_dag_source_impl(dag_id=dag_id)
  • Internal implementation _get_dag_source_impl() that calls adapter.get_dag_source(dag_id) and returns JSON. This is the core handler logic that bridges MCP tools to the Airflow adapter.
    def _get_dag_source_impl(dag_id: str) -> str:
        """Internal implementation for getting DAG source code from Airflow.
    
        Args:
            dag_id: The ID of the DAG to get source code for
    
        Returns:
            JSON string containing the DAG source code and metadata
        """
        try:
            adapter = _get_adapter()
            source_data = adapter.get_dag_source(dag_id)
            return json.dumps(source_data, indent=2)
        except Exception as e:
            return str(e)
  • Airflow 3.x adapter implementation: calls REST API endpoint 'dagSources/{dag_id}' directly since Airflow 3 uses dag_id for source lookup.
    def get_dag_source(self, dag_id: str) -> dict[str, Any]:
        """Get source code of a DAG.
    
        Note: Airflow 3 directly uses dag_id for source lookup.
        """
        return self._call(f"dagSources/{dag_id}")
  • Airflow 2.x adapter implementation: first fetches DAG details to get the file_token, then calls 'dagSources/{file_token}' since Airflow 2 requires file_token for source lookup.
    def get_dag_source(self, dag_id: str) -> dict[str, Any]:
        """Get source code of a DAG.
    
        Note: Airflow 2 requires a file_token, so we get DAG details first.
        """
        # First, get the DAG to get its file_token
        dag_data = self.get_dag(dag_id)
        file_token = dag_data.get("file_token")
        if not file_token:
            return {"error": "DAG has no file_token", "dag_id": dag_id}
    
        # Get source using file_token
        return self._call(f"dagSources/{file_token}")
  • Abstract base class definition for get_dag_source method that all adapters must implement. Defines the interface contract.
    @abstractmethod
    def get_dag_source(self, dag_id: str) -> dict[str, Any]:
        """Get source code of a DAG."""
Behavior3/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 correctly identifies this as a read operation (no mention of side effects) and describes the return fields. However, it does not disclose authorization requirements, error handling, or constraints like DAG existence, which would be helpful.

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

Conciseness3/5

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

The description is somewhat verbose with bullet points and example queries. While helpful, it could be more concise. The front-loading of purpose is good, but the list of user queries takes up space that could be summarized more briefly.

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 output schema exists, the description adequately covers return values (content, file_token). It addresses the parameter and usage examples. With many sibling tools, the context is fairly complete, though it could mention prerequisite conditions like DAG existence.

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

Parameters4/5

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

With 0% schema description coverage, the description fully defines the sole parameter 'dag_id' as 'The ID of the DAG to get source code for'. This adds necessary clarity beyond the schema's type-only definition.

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 'get' and resource 'source code for a specific Apache Airflow DAG'. It provides explicit example queries that distinguish it from siblings like 'get_dag_details' or 'explore_dag'.

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 includes explicit 'when to use' scenarios with concrete user queries, making the tool's purpose clear. It lacks explicit 'when not to use' or alternative tool references, but the examples effectively guide usage.

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/astronomer/astro-airflow-mcp'

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