File upload support (multipart) in custom tool builder

[tashage]

Problem

Is your feature request related to a problem? Please describe.
The custom tool builder supports multipart/form-data as a Request Body encoding, but every Input Parameter type available (string, number, integer, boolean, array, object) sends its value as text. There's no way to make a parameter carry an actual file. This means any API endpoint that requires a genuine file upload — not just a text field — can't be built as a working tool, even though the encoding option implies it should be possible.

Steps to reproduce

1. Built a tool for Etsy's uploadListingImage endpoint (POST /shops/{shop_id}/listings/{listing_id}/images), which requires a real multipart file upload.
2. Set Method to POST, Encoding to multipart/form-data, and added an image parameter (type: string) intended to hold a public image URL.
3. Called the tool with a real, public image URL as the image value.
4. Etsy rejected the request: 400 Bad Request — "Either a valid image file or a listing_image_id must be provided."

The request went out as a text field containing a URL string, not as an actual file attachment, so Etsy correctly didn't recognize it as an upload.

Proposed Solution

Describe the solution you'd like
A parameter type (e.g. "file" or "file from URL") available when Encoding is set to multipart/form-data, where the value provided is a public URL that the connector fetches server-side and attaches to the request as a real file part — rather than passing the URL through as plain text.

Alternatives Considered

Describe alternatives you've considered
No workaround exists within the current builder — every parameter type sends as text regardless of encoding. The only current option is uploading files manually outside the tool.

Area

Connectors (REST, SOAP, GraphQL, Database, MCP Bridge)

Additional Context

Additional context
This isn't Etsy-specific — any API requiring real file uploads (images, documents, etc.) would hit the same wall. A single "file from URL" parameter type would unblock all of them.

[keysersoft]

Confirmed, and your diagnosis is exactly right — thank you for the reproduction, it saved me the digging.

The gap is in packages/backend/src/connectors/engines/rest.engine.ts. When bodyEncoding is form-data the engine builds the body like this:

const form = new FormData();
for (const [k, v] of spreadFormEntries(mapped)) {
  appendFormParam((key, val) => form.append(key, val), k, v);
}

appendFormParam coerces every value to a primitive before appending, so there is no path where a part carries a filename, a content type or bytes. The encoding option is real — the boundary and headers are set correctly — but every part is a text field, exactly as you observed. Etsy's 400 is the correct response to what we actually sent.

So this is not a misconfiguration on your side and there is no adapter-level workaround. Marking it as a genuine gap.

On the proposed shape. "Give a URL, we fetch it server-side and attach it" is the right ergonomics — an MCP client has no way to hand us bytes — but it needs to be built carefully, because it turns a tool parameter into a server-side request to an arbitrary address. That is a textbook SSRF vector, and this repo already has the guard for it: assertSafeOutboundUrl in common/ssrf.util.ts, the same one that stops a connector reaching 169.254.169.254 or a private host. Any fetch-from-URL parameter has to go through it, and on Cloud that means public hosts only. Worth saying up front so nobody implements the convenient version first.

The other details that will need deciding: a size ceiling, whether the fetched content type is trusted or re-sniffed, and whether the filename comes from the URL or from a second parameter (several APIs, Etsy included, care about the filename).

I am not going to promise a date. But the analysis above is the whole of it, and if anyone wants to pick this up it is a well-scoped piece of work — comment here and I will help scope the PR.