Host-assisted uploads (large notes, byte-perfect)

When you ask a chat agent to publish or send a large note (a long document, or one with an inline image), repeating the content through the language model is slow and error-prone: huge tool-call arguments can stall the provider, chunked re-transmission can glue sections together, and one wrong character in transcribed base64 corrupts an image. WebF1 Pad solves this with host-assisted upload: the pad itself performs the upload, by reference.

The flow

1. A tool in the chat (from any MCP server) advertises an upload endpoint. Its result carries an uploadUrl (optionally with uploadToken, maxBytes and expiresAt). The composer shows an Upload: host chip while one is live.
2. The model calls the built-in pad_upload_content tool with the URL and a reference to the content: "active-note", an exact open note title, or a file path inside your configured notes directory. The content is never part of the tool call.
3. The pad resolves the reference from its own store and performs the HTTP PUT itself. The bytes go straight from the pad to the server; the language model never reproduces a single one.
4. The tool result reports the HTTP status, the byte count and the sha256 checksum, which the agent can pass back to the server’s complete-upload call for end-to-end integrity verification.

A 10 MB note and a 170-byte note cost the model the same effort: every generation in the content path stays tiny.

Safety rails

• Provenance: the URL must have been advertised by a tool result in this conversation. Arbitrary model-supplied URLs are rejected before any network activity, so the pad can never become a model-driven proxy.
• HTTPS only, with plain HTTP allowed for localhost/127.0.0.1 so dev servers work.
• PUT only, this tool is not a general HTTP client.
• Tokens stay inside the app: when a tool result carries an uploadToken, the pad captures it and injects it into the request headers itself. The token never appears in the model’s context or in a URL.
• Confirmation: before the first upload to each host in a conversation, the pad shows a dialog asking you to Allow or Deny. Denying is reported to the model, the conversation continues.
• No content echo: the upload result carries the status, byte count and checksum only, the uploaded content never returns to the model.

Notes

• If a token expires (servers issue short-lived ones by design), the agent simply re-runs the server’s create step to get a fresh one.
• Retrying after a lost response is safe: if the server reports the upload already happened, the tool treats it as success.
• The feature is generic: any MCP server that advertises uploadUrl in a tool result benefits, nothing is special-cased for particular servers.