yungle-mcp@0.3.2

Patch Changes

• #15 3390cb6 Thanks @heindewilde! - Docs links point to docs.yungle.co.

• Updated dependencies [3390cb6]:

  • yungle-client@0.3.2

yungle-mcp@0.3.1

Patch Changes

• #13 61c9f2e Thanks @heindewilde! - create_transfer is listed only for a credential with transfers:write. A read-only key used to get it too, and the API refuses to create a transfer without that scope, so the tool could only fail.

yungle-client@0.3.2

Patch Changes

• #15 3390cb6 Thanks @heindewilde! - A dropped connection is now retried for GET, DELETE and POST (with the same Idempotency-Key), as the README always said; before, the network error was thrown straight away. A caller's own abort is never retried. Docs links point to docs.yungle.co.

yungle-cli@0.3.1

Patch Changes

• #15 3390cb6 Thanks @heindewilde! - Uploads send one part per request instead of the whole file in one, so a large file on a slow connection is no longer cut off by the server's 30-minute request limit. Help and docs links point to docs.yungle.co.

Browser extension 0.1.4

Store packages for Chrome (and Edge/Brave) and Firefox, plus the source zip for AMO review.

yungle-mcp@0.3.0

Minor Changes

• dd711cd Thanks @heindewilde! - For agents and scripts that move big files. yungle-client gains uploadFile (and client.uploadFile): a zero-dependency resumable tus upload from any Blob — in Node, fs.openAsBlob(path) — retried after drops and renewing its token as it runs. The MCP server's local uploads use it, so share_local_files now survives a dropped connection, takes folders (keeping their structure), and reports progress. create_transfer returns one keyless upload command per file (npx -y yungle-cli put <file> --target …), so an assistant with a shell can move files its connection cannot carry, and finalize_transfer turns the draft into a link. The new yungle put runs those commands. Downloads (yungle get/pull, the MCP download_files, Python download) now verify each file against the server's CRC-32 and delete a damaged copy.

• cca8096 Thanks @heindewilde! - Getting files out. yungle-client adds transferDownloadLinks, collectionDownloadLinks and resolveLink (signed, resumable download URLs for your own transfers and collections, or for a link someone shared). yungle get now takes collection links too and keeps folder structure; the new yungle pull --collection <id> downloads your own collection and, run again, fetches only what is new. The MCP server gains get_download_links (every credential, hosted included) and, when running locally, download_files, which saves into a new subfolder of a folder you name. JSON errors from yungle get now carry the server's code (guests_only, password_required, …), and a cancelled prompt exits 130 as documented.

• 15812fd Thanks @heindewilde! - Upload requests. yungle-client adds listRequests, createRequest, getRequest and setRequestStatus (public pages that let other people upload into one of your collections), the request.submitted webhook type, and crc32 on transfer and collection files. yungle requests lists them; yungle requests new --collection <id> --title … makes one and prints its link; pause, resume, close and show manage them. The MCP server can read them (list_upload_requests, get_upload_request) but not create them: a public upload page is a door into someone's storage, and a model can be steered.

• f1686e3 Thanks @heindewilde! - Files from URLs. createTransfer, addTransferFiles and addCollectionFiles accept imports: [{ url, name?, path? }] — Yungle fetches each file itself, so a presigned S3 link or a CDN URL of any size moves without passing through you — and getImport / waitForImports follow them. yungle send and yungle push take --from-url <url> (repeatable) and wait for the fetch before sending. The MCP server gains share_from_urls and get_import_status, which is what lets the hosted connector move big files at all. Also fixed: a repeated --to kept only the last address; every one is now kept.

Patch Changes

• Updated dependencies [dd711cd, cca8096, 2c570b8, 147515a, 15812fd, ca44e4f, f1686e3]:
  • yungle-client@0.3.0

yungle-client@0.3.1

Patch Changes

• 394eecd Thanks @heindewilde! - getReferral(): your invite code and link, and the free months it has earned (GET /me/referral).

yungle-client@0.3.0

Minor Changes

• dd711cd Thanks @heindewilde! - For agents and scripts that move big files. yungle-client gains uploadFile (and client.uploadFile): a zero-dependency resumable tus upload from any Blob — in Node, fs.openAsBlob(path) — retried after drops and renewing its token as it runs. The MCP server's local uploads use it, so share_local_files now survives a dropped connection, takes folders (keeping their structure), and reports progress. create_transfer returns one keyless upload command per file (npx -y yungle-cli put <file> --target …), so an assistant with a shell can move files its connection cannot carry, and finalize_transfer turns the draft into a link. The new yungle put runs those commands. Downloads (yungle get/pull, the MCP download_files, Python download) now verify each file against the server's CRC-32 and delete a damaged copy.

• cca8096 Thanks @heindewilde! - Getting files out. yungle-client adds transferDownloadLinks, collectionDownloadLinks and resolveLink (signed, resumable download URLs for your own transfers and collections, or for a link someone shared). yungle get now takes collection links too and keeps folder structure; the new yungle pull --collection <id> downloads your own collection and, run again, fetches only what is new. The MCP server gains get_download_links (every credential, hosted included) and, when running locally, download_files, which saves into a new subfolder of a folder you name. JSON errors from yungle get now carry the server's code (guests_only, password_required, …), and a cancelled prompt exits 130 as documented.

• 2c570b8 Thanks @heindewilde! - End-to-end encrypted transfers: createTransfer({ e2ee: true }), sealTransferFile() for each file's sealed name and thumbnail, sealed e2eeMeta on finalizeTransfer, and an e2ee flag on transfers so a client never offers a link without its key.

• #7 147515a Thanks @heindewilde! - Errors now carry docs, a link to the explanation of their code, and retryAfterSeconds also reads the Retry-After header when the body states no wait. Before this, the monthly-allowance 429 (which sends Retry-After: 3600 and no details.retryAfterSeconds) was retried after half a second instead of an hour. parseRetryAfter is exported. Timestamps the API always sends (createdAt, updatedAt, a transfer's expiresAt) are no longer typed as nullable, and pulled webhook events have a named type, PulledWebhookEvent.

• 15812fd Thanks @heindewilde! - Upload requests. yungle-client adds listRequests, createRequest, getRequest and setRequestStatus (public pages that let other people upload into one of your collections), the request.submitted webhook type, and crc32 on transfer and collection files. yungle requests lists them; yungle requests new --collection <id> --title … makes one and prints its link; pause, resume, close and show manage them. The MCP server can read them (list_upload_requests, get_upload_request) but not create them: a public upload page is a door into someone's storage, and a model can be steered.

• ca44e4f Thanks @heindewilde! - Uploads can now run longer than two hours. Upload tokens last two hours and every tus request presents one, so a long upload used to fail at its first request after that, and could never resume after a drop past the two-hour mark. yungle-client adds createTokenKeeper, renewUploadToken and client.renewUploadToken() (backed by POST /api/uploads/token), and types the new uploadTokenExpiresAt. yungle send, push and watch renew automatically and save each renewed token, so a run killed after hours still resumes.

• f1686e3 Thanks @heindewilde! - Files from URLs. createTransfer, addTransferFiles and addCollectionFiles accept imports: [{ url, name?, path? }] — Yungle fetches each file itself, so a presigned S3 link or a CDN URL of any size moves without passing through you — and getImport / waitForImports follow them. yungle send and yungle push take --from-url <url> (repeatable) and wait for the fetch before sending. The MCP server gains share_from_urls and get_import_status, which is what lets the hosted connector move big files at all. Also fixed: a repeated --to kept only the last address; every one is now kept.

yungle-cli@0.3.0

Minor Changes

• dd711cd Thanks @heindewilde! - For agents and scripts that move big files. yungle-client gains uploadFile (and client.uploadFile): a zero-dependency resumable tus upload from any Blob — in Node, fs.openAsBlob(path) — retried after drops and renewing its token as it runs. The MCP server's local uploads use it, so share_local_files now survives a dropped connection, takes folders (keeping their structure), and reports progress. create_transfer returns one keyless upload command per file (npx -y yungle-cli put <file> --target …), so an assistant with a shell can move files its connection cannot carry, and finalize_transfer turns the draft into a link. The new yungle put runs those commands. Downloads (yungle get/pull, the MCP download_files, Python download) now verify each file against the server's CRC-32 and delete a damaged copy.

• cca8096 Thanks @heindewilde! - Getting files out. yungle-client adds transferDownloadLinks, collectionDownloadLinks and resolveLink (signed, resumable download URLs for your own transfers and collections, or for a link someone shared). yungle get now takes collection links too and keeps folder structure; the new yungle pull --collection <id> downloads your own collection and, run again, fetches only what is new. The MCP server gains get_download_links (every credential, hosted included) and, when running locally, download_files, which saves into a new subfolder of a folder you name. JSON errors from yungle get now carry the server's code (guests_only, password_required, …), and a cancelled prompt exits 130 as documented.

• 15812fd Thanks @heindewilde! - Upload requests. yungle-client adds listRequests, createRequest, getRequest and setRequestStatus (public pages that let other people upload into one of your collections), the request.submitted webhook type, and crc32 on transfer and collection files. yungle requests lists them; yungle requests new --collection <id> --title … makes one and prints its link; pause, resume, close and show manage them. The MCP server can read them (list_upload_requests, get_upload_request) but not create them: a public upload page is a door into someone's storage, and a model can be steered.

• ca44e4f Thanks @heindewilde! - Uploads can now run longer than two hours. Upload tokens last two hours and every tus request presents one, so a long upload used to fail at its first request after that, and could never resume after a drop past the two-hour mark. yungle-client adds createTokenKeeper, renewUploadToken and client.renewUploadToken() (backed by POST /api/uploads/token), and types the new uploadTokenExpiresAt. yungle send, push and watch renew automatically and save each renewed token, so a run killed after hours still resumes.

• f1686e3 Thanks @heindewilde! - Files from URLs. createTransfer, addTransferFiles and addCollectionFiles accept imports: [{ url, name?, path? }] — Yungle fetches each file itself, so a presigned S3 link or a CDN URL of any size moves without passing through you — and getImport / waitForImports follow them. yungle send and yungle push take --from-url <url> (repeatable) and wait for the fetch before sending. The MCP server gains share_from_urls and get_import_status, which is what lets the hosted connector move big files at all. Also fixed: a repeated --to kept only the last address; every one is now kept.

Browser extension 0.1.3

Store packages for Chrome (and Edge/Brave) and Firefox, plus the source zip for AMO review.