easydeploy-ai-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Upload from share link

upload_from_url

Fetch file bytes from a shareable URL into an EasyDeploy upload session server-side when sandbox egress is blocked; pass a URL, not file contents.

Instructions

Hand EasyDeploy a URL to fetch an upload session's bytes from, server-side.

Use this when the sandbox has no network egress (the gateway curl failed with a connection error) but the training file already lives at a shareable URL, or when a host handed you a file download link.

Accepted sources:

Google Sheets and Google Drive share links set to anyone with the link (Sheets are exported as CSV).
OpenAI file links from a host file parameter.
Any other host on the EasyDeploy source allowlist.

EasyDeploy fetches the bytes itself, up to 256 MB. The file never passes through the model, the conversation, or this tool's arguments — pass a URL, never file contents. Private, loopback, and metadata addresses are rejected, as is any host off the allowlist; the error explains which rule refused the URL.

Returns the session in RECEIVING. A 409 means the session already received bytes or expired — call start_upload again for a fresh one. If no channel works at all, the fallback string in the start_upload result carries the web model-builder URL for this environment (for example https://www.easydeploy.ai/model-builder).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`source_url`	Yes
`upload_request_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Oct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial context beyond annotations: the 256 MB cap, that bytes never pass through the model/conversation, SSRF protections (private, loopback, metadata addresses rejected), the allowlist rule, the RECEIVING end state, and 409 semantics. These are behavioral traits the openWorldHint/destructiveHint flags cannot convey.

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?

Front-loaded with the core action, then organized into accepted sources, limits, and return/error behavior. Efficient and scannable, though the final paragraph about start_upload's fallback string drifts slightly into another tool's territory.

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?

Given an output schema exists, the description need not restate return values, yet it still covers the RECEIVING state, the 409 failure mode, size limits, and security rejections. Nothing an agent needs to invoke this correctly is missing.

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 coverage is 0%, so the description must carry the load. It defines source_url thoroughly (accepted sources, URL-never-contents rule), but upload_request_id is only implied as coming from start_upload rather than defined explicitly. Strong compensation overall, one identifiable gap.

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 plus the mechanism: 'Hand EasyDeploy a URL to fetch an upload session's bytes from, server-side.' It also distinguishes itself from siblings by referencing start_upload's session and the fallback path, so an agent can tell it apart from complete_upload or plain start_upload.

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?

Gives explicit triggering conditions: 'when the sandbox has no network egress (the gateway curl failed with a connection error)' or 'when a host handed you a file download link.' It also names the recovery alternative (409 → call start_upload again) and the ultimate fallback channel, covering when-not and what-to-do-instead.

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