Yungle
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_accountA | Answers: how much storage am I using? how much is left? what plan am I on? what can this connection do? Returns the workspace, its plan and quota, and the key's permissions. |
| list_transfersA | Answers: what have I sent recently? what is expiring soon? which deliveries has nobody picked up? who did I send that to? Returns recent transfers with size, recipients, download count, expiry date and share link. |
| get_transferA | Answers: what is in this transfer? was it delivered? has a specific recipient downloaded it? is it safe to share? Returns the files with their malware-scan verdicts, plus per-recipient delivery and download status for one transfer id. |
| get_transfer_downloadsA | Answers: did the client download it? when? how many times? Returns download events with timestamps and per-recipient status. One visit can fetch several files: events that share a sessionId belong to the same visit. |
| list_collectionsA | Answers: what collections do I have? which are empty? how big is each one? Returns collections with file counts, sizes and when each was last touched. A collection is a durable space clients are invited into, as opposed to a one-off transfer. Never includes the vault, which is unreadable to this server by design. |
| get_collectionB | Answers: what is the link for this collection? how much is in it? when does it expire? Returns one collection with its secret share link, file count, total size and expiry. |
| list_collection_filesA | Answers: what files are in this collection? what is in this folder? are the raws uploaded yet? Returns filenames, sizes and types. Omit folderId for every file; pass "root" for the top level only, or a folder id. Filenames only — never file contents. |
| list_foldersA | Answers: how is this collection organised? what folders exist? Returns the folder tree. Ordered by depth, then path (not a pre-order traversal). Each folder carries its parentId and its full path. |
| list_guestsA | Answers: who has access to this collection? who did I invite? has someone accepted? Returns the invited guests and their status. Guests are not workspace members — they can view and download this one collection and nothing else. |
| list_contactsA | Answers: what is this client's email address? who do I have saved? Returns the workspace address book. A contact grants no access on its own — it is a convenience, not a permission. |
| list_upload_requestsA | Answers: which upload links do I have out? has anyone sent files through them? Returns each public upload page that feeds a collection, with its link, status and how much has arrived. |
| get_upload_requestA | Answers: who has uploaded through this link, when, and how much? Returns the request and its submissions, newest first, with the name, email and note each uploader typed. |
| get_download_linksA | Answers: what is in this link someone sent me? how do I get these files? Turns a Yungle link (https://yungle.co/t/… or /c/…), or one of your own transfers or collections, into signed download URLs: one per file, with its folder path, plus a ZIP. The URLs need no key, support HTTP Range (resumable), and work for 24 hours — fetch them with curl or any HTTP client. Resolving someone else's link counts as one download of it, like opening it in a browser. |
| download_filesA | Save the files of a Yungle link, or of one of your own transfers or collections, into a
folder on this machine — resumably, keeping their folder structure. Files land in a new
subfolder of |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Each tool targets a distinct object or action: transfers (list/get/downloads), collections (list/get/files/folders), guests, contacts, upload requests, and the link-resolution pair. The only near-overlap, get_download_links vs download_files, is cleanly separated by output (signed URLs vs files on disk) and the descriptions make that explicit.
Every tool follows a clean snake_case verb_noun pattern (list_*, get_*, download_files). The convention is uniform and predictable across all 14 tools.
14 tools is well within the ideal 3-15 range and each one maps to a distinct resource or operation in the file-transfer domain. Nothing feels padded or redundant.
The read/inspection and download surface is thorough, covering accounts, transfers, collections, folders, guests, contacts, upload requests and link resolution. However, the surface is entirely read-only: no tools to create transfers/collections, invite guests, add contacts, or manage upload requests, so the write lifecycle is absent (possibly by design).