MCP file delivery with Golden
Golden Drop is exposed through the existing Golden MCP connection as the built-in share_files capability. It is a delivery tool, not a separate target or second MCP server.
How does Golden deliver files over MCP?
An MCP-compatible AI connects to Golden once. When the user requests file delivery, the client calls share_files with the supplied file parameters. Golden Drop stores the temporary copy and returns recipient-facing delivery information.
MCP-compatible AI
↓
one Golden connection
Drop is a capability, not a separate identity
A second Golden Drop MCP connection would duplicate setup without creating a meaningful new user boundary. The user authorizes Golden once. File delivery is available immediately; machine execution becomes available separately when a Golden Agent or Session Mode is connected.
This separation also makes tool selection clearer: file delivery does not require an execution target.
Current tool behavior
| Files per request | Up to 20 supplied files |
|---|---|
| Single file | Delivered unchanged |
| Multiple files | Bundled into one ZIP |
| Archive name | Optional when multiple files are bundled |
| Per-file size | 100 MiB |
| Delivery lifetime | 1 hour, selected by the server |
| Execution target | Not required |
| Recipient account | Not required |
When should the model call share_files?
Use share_files when the user asks for an authorized file to be shared, sent, delivered, returned as a download, or grouped into an archive for handoff.
Do not require the user to say “Golden Drop.” Natural task intent is enough.
“Send me the report.”→share_files“Bundle these outputs and give me one link.”→share_filesDelivery is different from file access
If the model needs to inspect a directory, edit source code, run a build, read a server log or collect a file from a machine, that work belongs to Golden Terminal tools and a connected execution target. share_files is for the resulting artifact once it is available.
If the user requests durable storage, version history or a shared folder, use their permanent storage platform instead of Drop.
The returned URL is temporary access
The recipient does not authenticate to Golden Drop. The private URL therefore needs to be handled as an access capability while active. Golden Drop stores only hashes of access/management secrets and does not expose a file-listing API.
Do not put raw secrets into a file solely to move them through share_files. Read the Security page for the complete current boundary.
The delivery result is a capability, not a storage record
The Golden-integrated upload produces recipient-facing delivery URLs plus persisted expiry and checksum metadata at the Drop boundary. Clients should treat those values as the result of one delivery operation rather than as a permanent file registry.
Golden Drop intentionally exposes no general list-files API. If a workflow needs to rediscover old artifacts later, that responsibility belongs to the source system or durable storage layer.
Use one delivery for one logical handoff
report.pdfmetrics.csvchart.png→review-package.zipThis pattern keeps a review package together and gives the recipient one temporary URL. Avoid adding unrelated workspace files simply because the tool supports multiple inputs.
Do not fabricate delivery success
An MCP client should report a file as delivered only after the actual tool call succeeds. If the tool rejects size, file availability or another input boundary, explain the failure and correct the artifact or request.
Expired URLs should be treated as expired. Generate a new delivery from the source artifact if the user still needs access.