easydeploy-ai-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Start file upload

start_upload

Opens an upload session for a file and returns ways to send its bytes, enabling datasets to be created or versioned without passing file bytes through chat.

Instructions

Open an upload session for one file and return the ways to send its bytes.

One session carries one file. Train and test files (and an optional validation file) are separate uploads, each with its own start_upload. File bytes never travel through tool arguments or the conversation on any channel:

A. Host file parameter (preferred where available). Hosts that support openai/fileParams (Codex, ChatGPT) hydrate file from a sandbox path. EasyDeploy then fetches the bytes server-side and the session goes straight to RECEIVING, with no network needed from the sandbox. Poll get_upload_status until READY, then call complete_upload.

B. Gateway PUT (default). Called without file, this returns curl_command, the HTTP PUT that sends the file to EasyDeploy's upload gateway. It runs in the shell where the file is, with FILE_PATH replaced by the file's path. Max ~6 MB; it carries a single-use upload token, never the API key. If the sandbox blocks network egress, next_steps names the exact API host the user can allow.

C. Fetch from a share link. If the sandbox cannot reach the network but the file sits at a shareable URL, upload_from_url with the returned upload_request_id has EasyDeploy fetch it.

The returned next_steps is the ordered runbook with the ids filled in, including the web model-builder fallback for hosts with no byte channel at all. The model-builder URL for this environment comes from the API in the fallback string of this result (for example https://www.easydeploy.ai/model-builder).

dataset_id: omit it to create a new dataset when complete_upload runs. Pass an existing dataset's id to add a new version to that dataset instead; complete_upload's name is then ignored and the dataset keeps its current name. The output carries dataset_id only when you passed one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`file`	No
`filename`	Yes
`dataset_id`	No
`project_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.0Oct 2, 2026

addedInput schema / properties / file

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "description": "A file handed over by the MCP host (OpenAI Apps SDK file-parameter shape).\n\nHosts that support ``openai/fileParams`` replace this argument with a\nshort-lived ``download_url`` plus a ``file_id``. The model never sees or\nwrites the file's bytes; EasyDeploy fetches them server-side.",
+      "properties": {
+        "download_url": {
+          "type": "string"
+        },
+        "file_id": {
+          "type": "string"
+        },
+        "file_name": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "mime_type": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "required": [
+        "download_url",
+        "file_id"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

First observedv0.1.0May 29, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare the mutation and open-world profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false). The description goes well beyond them by disclosing the single-use upload token, that the API key is never carried, a ~6 MB size cap, the RECEIVING->READY lifecycle, and egress-fallback behavior — meaningfully richer than the annotations alone.

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

Conciseness4/5

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

Long, but front-loaded and organized into A/B/C channels plus a bolded dataset_id paragraph, so an agent can scan it. A few asides (e.g. the model-builder URL example) could be trimmed, but nearly every sentence carries decision-relevant information.

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

Completeness5/5

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

An output schema exists so return values needn't be detailed, yet the description still explains next_steps, upload_request_id and dataset_id echo. Given the multi-channel upload complexity and 0% param coverage, it is complete enough for correct invocation.

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?

Schema description coverage is 0%, so the description carries the burden and largely does: it explains `file` (host hydration shape, bytes fetched server-side), `dataset_id` (omit for new dataset, pass for new version, name ignored, echoed only when passed). `filename` and `project_id` are left implicit, but the two hard parameters are well covered.

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?

States a specific verb and resource ('Open an upload session for one file and return the ways to send its bytes') and immediately scopes it to one file per session, distinguishing it from the sibling upload_from_url, complete_upload and get_upload_status it references.

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

Usage Guidelines5/5

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

Lays out three numbered channels (A host file param, B gateway PUT, C share link) with explicit conditions for choosing each, including network-egress caveats, and names the exact follow-up sequence (poll get_upload_status, then complete_upload). It even explains the dataset_id create-vs-new-version fork.

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