Feature Engineering MCP Server

An MCP (Model Context Protocol) server that exposes the existing ahutosh173/automated-feature-engineering LangGraph agent as reusable tools.

The original agent takes a CSV, a fraud/modus-operandi objective, schema metadata, ID column and label column, then:

1. analyzes the modeling objective,

2. proposes candidate features,

3. generates pandas feature-engineering code,

4. executes that code, and

5. writes an Excel feature file.

This project adds an MCP interface on top of that workflow.

Architecture

                 MCP Host / LLM Client
                         |
                         | MCP
                         v
              +-----------------------+
              | Feature Engineering   |
              | MCP Server            |
              +-----------+-----------+
                          |
              +-----------+-----------+
              |                       |
              v                       v
       Dataset profiling      Existing LangGraph
                              Feature Engineering Agent
                                      |
                       +--------------+--------------+
                       |              |              |
                    Analyze MO   Propose features  Generate code
                                                       |
                                                       v
                                                Execute features
                                                       |
                                                       v
                                                 Excel output

Related MCP server: skillsmcp

MCP tools

Important design decision

The MCP layer does not replace the existing agent.

It is an adapter around the existing agent so that an MCP-compatible host can discover and call the feature-engineering workflow as a tool.

The original repository is:

https://github.com/ahutosh173/automated-feature-engineering

1. Prerequisites

• Python 3.10+

• Git

• Access to the original feature-engineering agent repository

• The LLM configuration required by the original agent

The MCP Python SDK currently requires Python 3.10+.

2. Clone both repositories

Recommended layout:

projects/
├── automated-feature-engineering/
└── feature-engineering-mcp/

Clone the original repository:

git clone https://github.com/ahutosh173/automated-feature-engineering.git

Clone this repository:

git clone <YOUR-MCP-REPO-URL>

3. Create a virtual environment

From this repository:

python -m venv .venv

Windows:

.venv\Scripts\activate

Linux/macOS:

source .venv/bin/activate

Install dependencies:

pip install -r requirements.txt

Install the original agent's dependencies:

pip install -r ../automated-feature-engineering/requirements.txt

4. Configure the original agent

The original repository currently expects its own .env configuration, including HF_TOKEN.

Configure that repository exactly as described in its README.

Do not commit API keys or tokens.

5. Configure this MCP server

Copy:

cp .env.example .env

Windows PowerShell:

Copy-Item .env.example .env

Set:

FEATURE_ENGINEERING_REPO=../automated-feature-engineering

If the two repositories are somewhere else, use an absolute path.

Example:

FEATURE_ENGINEERING_REPO=C:/projects/automated-feature-engineering

6. Run the MCP server

For local stdio usage:

python server.py

The process will wait for an MCP client over stdin/stdout.

For MCP Inspector development:

mcp dev server.py

The official MCP Python SDK provides the Inspector development workflow and supports defining tools directly from typed Python functions.

7. Test without an external MCP host

Run:

pytest -q

The tests use the MCP Python client's in-memory connection and therefore test the MCP tool definitions without starting a subprocess.

Example: profile a dataset

An MCP client can call:

{
  "name": "profile_dataset",
  "arguments": {
    "csv_path": "../automated-feature-engineering/data/train.csv"
  }
}

Example response:

{
  "success": true,
  "rows": 10000,
  "columns": 25,
  "columns_info": [
    {
      "name": "amount",
      "dtype": "float64",
      "missing": 0,
      "missing_pct": 0.0,
      "unique": 9000
    }
  ]
}

Example: run the agent

{
  "name": "run_feature_engineering",
  "arguments": {
    "csv_path": "../automated-feature-engineering/data/train.csv",
    "mo_name": "Fraud Detection",
    "mo_description": "Identify fraudulent transactions based on account behavior",
    "data_schema": [
      {
        "name": "txn_id",
        "dtype": "object",
        "description": "Transaction ID"
      },
      {
        "name": "amount",
        "dtype": "float64",
        "description": "Transaction amount"
      }
    ],
    "id_column": "txn_id",
    "label_column": "fraud"
  }
}

Why MCP is useful here

Without MCP, the feature-engineering workflow is primarily a Python application.

With MCP, an MCP-compatible host can discover the feature-engineering tools and decide when to invoke them.

For example:

User:
"Analyze my fraud dataset and create account-level features."

LLM:
  -> profile_dataset
  -> run_feature_engineering
  -> inspect result
  -> explain generated features

Security note

The original agent generates Python code with an LLM and executes it using exec(). That is a high-risk operation if untrusted model output or untrusted users can reach the server.

For production:

• run the agent in an isolated container,

• use a restricted filesystem,

• validate generated code,

• restrict imports,

• restrict input/output paths,

• use resource and CPU/time limits,

• do not expose arbitrary filesystem access,

• add authentication/authorization before remote deployment.

This repository intentionally does not claim that the existing generated-code execution is production-safe.

Suggested next upgrades

1. Add a feature evaluation tool.

2. Add model-performance comparison.

3. Add feature lineage metadata.

4. Add approval/review before generated code executes.

5. Add Streamable HTTP deployment.

6. Add authentication.

7. Add LangGraph checkpoint/session IDs instead of the fixed thread ID used by the original workflow.