EasyDeploy AI

EasyDeploy AI MCP (easydeploy-ai-mcp)

A Model Context Protocol (MCP) server that exposes the [EasyDeploy](https://easydeploy.ai) public REST API as tools for Claude, Cursor, Claude Code, and other MCP clients.

PyPI package name: easydeploy-ai-mcp · Import package: easydeploy_ai_mcp

Contents

• Connect with Claude
• What you get
• Requirements
• Install
• Environment variables
• Local MCP (stdio)
• Remote MCP (HTTP)
• Documentation
• REST API reference
• Releases and API compatibility
• Development
• Security
• License

Connect with Claude

Hosted connector (claude.ai or Claude Desktop)

We host the MCP endpoint. You add it once inside Claude; after you connect and sign in, new chats can use EasyDeploy like any other enabled connector.

1. Open Claude in the browser or open Claude Desktop.
2. Open Settings, then Connectors, and choose Add custom connector.
3. Enter exactly:

• Name: EasyDeploy AI
• Remote MCP server URL: https://mcp.easydeploy.ai/mcp

1. Save the connector so EasyDeploy appears in your list of connectors.
2. Open the EasyDeploy connector entry and choose Connect, then finish sign-in in your browser. That step authorizes Claude to use your EasyDeploy account.

Connect and sign in (inside Claude): After the custom connector is set up, Claude shows an EasyDeploy card with the MCP URL and a Connect button. Use that flow to sign in. You do not paste an API key into Claude. Access stays tied to the EasyDeploy profile you authenticate in the browser.

Claude Desktop and file uploads: File uploads and some tool calls reach EasyDeploy over the network. On Desktop, Claude blocks outbound traffic unless you allow the domains it should call. Open Settings → Capabilities, turn on Allow network egress, and under the domain allowlist add this one host exactly:

api.easydeploy.ai

That is the only host uploads to the public production server go to; allow it exactly, nothing wider. A server pointed at another EasyDeploy API (one set with EDA_API_BASE) needs that API's host instead, and the start_upload runbook names the exact host to allow.

The domain allowlist UI is available on paid Claude plans.

More detail and variants (for example a URL from your own deployment) are in docs/claude-getting-started.md.

Start here: get_started

get_started returns the EasyDeploy data-science playbook, which is most useful at the start of a modeling task. Its description and the server's MCP instructions say what it returns rather than when the agent must call it, as the Claude connector directory requires. Hosts cache tool descriptions and server instructions, and many never show the instructions to the model; a tool result is fetched live on every call. So the playbook lives in the tool's result, not in its description: the name and description stay fixed, and the content is updated with each release without anyone reconnecting.

• get_started() returns the overview: the roles, the whole workflow with the tools at each step, and the hard rules.
• get_started(section=...) returns one section: prepare, split, upload, train, validate or predict. all returns every section.
• Each result carries guide_version, updated, the list of sections with a one-line summary each, and next, the section to read next.

The content ships inside the package as Markdown, one file per section, in src/easydeploy_ai_mcp/guide/. The tool is read-only and makes no API call.

You are the data scientist

EasyDeploy searches models, engineers features, tunes hyperparameters, trains, deploys and predicts. It does not clean your data, define the target, split it, or check the model on data it never saw. The agent does that, following the get_started playbook:

1. Prepare. Agree the decision and the target with you, explore the data, drop identifiers and anything not known at prediction time from the training file, and write a one-sentence target definition. Ids can stay in test and scoring files: prediction ignores columns the model wasn't trained on and returns them in the output, which makes joining results back easy. Data changes and dropped columns are confirmed with you before they are applied.
2. Split. Stratified 80/20 for classification, chronological for time series, no entity in both files, no duplicates. Balancing such as SMOTE touches the train file only.
3. Upload and train. The files go up separately, with dataset_type train and test (validation optional). The model version is created on the train dataset version only.
4. Validate on the holdout. The report's cross-validation score is measured inside the training file and its training-fit metrics are in-sample. The real estimate comes from run_batch_prediction on the test dataset version: the downloaded CSV keeps every input column, the true label included, in the original row order and adds prediction and probability_ columns. The agent computes the metrics from it and picks the decision threshold from the cost of each kind of error (best F1 only when those costs are unknown), or reports the error margin for regressors.
5. Use real outputs. Dashboards, reports and scored lists are built from real predictions, never mock values.

Getting a training file into EasyDeploy

start_upload opens an upload session and the agent picks the best byte channel the host offers. File contents never travel through the conversation or through tool arguments on any channel — the agent passes a URL or runs a curl, never the data itself.

get_upload_status reports URL_ISSUED → RECEIVING → UPLOADED → VALIDATING → READY | REJECTED → CONSUMED (plus EXPIRED). `complete_upload` requires `READY` — every byte that becomes a dataset version passes the CSV validator first, and a session still in flight, REJECTED or EXPIRED returns a 400 naming what to do. On REJECTED, the error field says which check failed. Retrying complete_upload is safe: on a session that is already CONSUMED it returns the existing dataset version, and a 409 means another call for the same session is still in progress (wait a few seconds and retry). get_upload_status only covers sessions opened by start_upload; files uploaded through the web model builder are registered in the web app and do not appear there.

New dataset or new version. Omit dataset_id on start_upload and complete_upload creates a new dataset with the name you give it. Pass an existing dataset's id and the upload becomes a new version of that dataset; complete_upload's name is then ignored and the dataset keeps its name. complete_upload returns dataset and datasetVersion once each, with the column names as a columnNames list. qa_status is informational and does not gate anything. version_type matters in one case: submit_training_job with an explicit dataset_version_id rejects a raw version. Omit dataset_version_id to train on the model version's own dataset.

Fallback when the host has no byte channel at all (no egress and no file bridge): the agent saves the training file, hands it to you as a download, and points you at the web model builder using the fallback text start_upload returns, which carries the right model-builder URL for the environment (for example [easydeploy.ai/model-builder](https://www.easydeploy.ai/model-builder)). After you upload there, tell the agent the dataset name you entered or paste the dataset URL from the page — it resolves the dataset with list_datasets and confirms the row count before continuing. That upload is already registered as a dataset, so complete_upload is not used for it. Adding the allowlist entry above (where your plan allows it) avoids the detour.

Reading a model report

get_model_report returns the report plus a structured metrics object (passed through unchanged from the API). Model search scores candidates with 10-fold cross-validation (stratified and shuffled on ROC-AUC for classifiers, shuffled on negative MSE for regressors; forward-chaining TimeSeriesSplit for a version created with time_series_mode=true), then refits the winner on all rows. There is no separate test set: accuracy, the confusion matrix, per-class precision/recall and in-sample ROC-AUC under metrics.trainingFit are training fit, and metrics.crossValidation.score is the report's out-of-sample estimate, measured inside the training file. The holdout estimate comes from scoring your own test file with run_batch_prediction, not from the report. metrics.crossValidation.strategy records which CV a run used (time_series_split for forward-chaining), and metrics.warnings flags anything to be careful quoting. The prose summary is written by an LLM and may use looser wording.

Promoting a model with aliases

An alias is a named pointer on a model, such as staging or production, that resolves to exactly one of its versions. run_prediction and run_batch_prediction take either model_version_id (an exact version) or model_id + alias (whichever version the alias points to when the call runs), never both. Scoring by alias lets the user promote a new version without changing their calls; the result's modelVersionId always names the version that actually scored, and alias echoes the alias that resolved it.

list_model_aliases shows where each alias points. set_model_alias creates or moves one. It always checks the change with a dry run first: when the new version was trained on different columns or a different target than the version the alias points to now (TRAINING_COLUMNS_CHANGED with the added and removed columns, TARGET_FEATURE_CHANGED, TRAINING_COLUMNS_UNKNOWN), it writes nothing and returns needs_confirmation: true with the warnings, so the agent can show the user what changes; it writes only when called again with confirm=true. With no warnings it writes straight after the check.

API keys have a scope: full, or predict (reads, predictions and uploads for scoring). Only a full-scope key can move an alias; a predict-only key gets 403 INSUFFICIENT_SCOPE, and the tool error says a full-scope key is needed. Alias arguments need an EasyDeploy API that has the alias routes; a self-hosted EDA_API_BASE pointing at an older backend answers with its own 400 or 404.

---

Local MCP on your computer (stdio)

Run the MCP server on your own mac