drivethrough-cli 0.1.2 → 0.1.3

package/dist/main.mjs

@@ -24021,23 +24021,27 @@ function registerTools(server, ctx) {
   server.registerTool(
     "create_upload",
     {
-      title: "Create upload URL",
-      description: `Mint a short-lived signed URL the USER can upload one local file to \u2014 the route for large binary assets (photos, PDFs, audio, video) when you have no local filesystem and the file isn't hosted anywhere. The bytes never pass through the conversation: if the file is already in YOUR runtime (e.g. a chat attachment mounted in your sandbox) and you can make HTTP requests, PUT the bytes to the signed URL yourself; otherwise relay the returned upload command to the user and wait for them to run it. Either way, then reference the file in deploy_site as {path, upload_id} (mode "patch" adds it to a live site) \u2014 never base64-encode it instead. Choosing a route for a binary asset: already on the public web \u2192 deploy_site {path, source_url}; local file + this server runs on the user's machine \u2192 deploy the directory; local file + chat-only connection \u2192 this tool. Tiny pasted assets (\u22641 MB, e.g. a favicon) may still go inline as base64 content. Each link takes exactly one file, is capped at 25 MB, and expires in 15 minutes. Upload ids are single-use: the deploy that references one consumes it (the bundle keeps the bytes; the staged copy is removed and its quota refunded) \u2014 to rename or duplicate the file later, use deploy_site {path, from_path}. An upload no deploy references within 24 hours is deleted, so deploy soon after the user confirms. Pass size_bytes when the user told you the file size \u2014 quota errors then surface here instead of failing the user's upload.`,
+      title: "Create upload link",
+      description: "Mint a short-lived upload link the USER opens in their browser to add local files (photos, PDFs, audio, video) \u2014 the route for binary assets when you cannot reach the bytes and they aren't hosted anywhere. Two-step: (1) relay the returned upload_url as a clickable link \u2014 it opens a drag-and-drop page (no sign-in needed) that takes up to 20 files, 25 MB each, and expires in 30 minutes. (2) When the user says they're done, call this tool again with the returned `session` \u2014 it lists what they uploaded ({upload_id, filename, size_bytes}); ship each with deploy_site files: [{path, upload_id}] (mode \"patch\" adds them to a live site). Never base64-encode a file instead \u2014 but if the bytes are already in YOUR runtime (e.g. a chat attachment mounted in your sandbox) AND you can make HTTP requests, you may PUT them straight to the returned put_url (one file per request, its filename as the last path segment) without involving the user. Choosing a route for a binary asset: already on the public web \u2192 deploy_site {path, source_url}; this server runs on the user's machine \u2192 deploy the directory; file only in the chat or on the user's machine \u2192 this tool. Tiny pasted assets (\u22641 MB, e.g. a favicon) may still go inline as base64 content. Upload ids are single-use: the deploy that references one consumes it (the bundle keeps the bytes; the staged copy is removed and its quota refunded) \u2014 to rename or duplicate the file later, use deploy_site {path, from_path}. An upload no deploy references within 24 hours is deleted, so deploy soon after the user confirms. Pass size_bytes when the user told you a file's size \u2014 quota errors then surface here instead of failing their upload.",
       annotations: { readOnlyHint: false, destructiveHint: false, idempotentHint: false, openWorldHint: false },
       inputSchema: {
-        site: external_exports.string().describe("Site name or id the upload belongs to"),
-        filename: external_exports.string().optional().describe(`The file's name, e.g. "dog.jpg" \u2014 its extension names the stored object`),
-        size_bytes: external_exports.number().int().optional().describe("Expected file size in bytes, if known \u2014 checked against the 25 MB cap and storage quota now")
+        site: external_exports.string().describe("Site name or id the uploads belong to"),
+        session: external_exports.string().optional().describe(
+          "A session id this tool returned earlier: list that session's uploaded files instead of minting a new link. Call this after the user says they're done uploading."
+        ),
+        size_bytes: external_exports.number().int().optional().describe(
+          "Expected size in bytes of the largest file, if known \u2014 checked against the 25 MB cap and storage quota at mint time"
+        )
       }
     },
-    async ({ site, filename, size_bytes }) => {
+    async ({ site, session, size_bytes }) => {
       try {
+        if (session !== void 0) {
+          return ok(await ctx.api.request("GET", `${sitePath(site)}/uploads/${encodeURIComponent(session)}`));
+        }
         return ok(
           await ctx.api.request("POST", `${sitePath(site)}/uploads`, {
-            body: {
-              ...filename !== void 0 ? { filename } : {},
-              ...size_bytes !== void 0 ? { size_bytes } : {}
-            }
+            body: { ...size_bytes !== void 0 ? { size_bytes } : {} }
           })
         );
       } catch (error2) {
@@ -24644,7 +24648,7 @@ var init_tools = __esm({
 Work token-efficiently \u2014 generated output is your scarcest resource:
 - LOCATE, don't read: to find where text lives on a deployed site, call get_site with \`find\` \u2014 it returns byte-exact matching lines. Use \`manifest_only\` to see what files exist. Read full contents (\`paths\`) only when you genuinely need them; a bare get_site inlines every text file.
 - EDIT, don't resend: change existing files with edit_site (exact find/replace). Never re-emit a whole file to change a small part. Use deploy_site mode "patch" for new files or wholesale rewrites \u2014 unchanged files carry forward automatically.
-- REFERENCE, don't inline: never base64-encode a file \u2014 not by hand, not in code, and never as a data: URI in HTML. To ship an image or other binary asset, pick the route by where the bytes live: already at a public URL \u2192 deploy_site {path, source_url}, fetched server-side; a local file (the user's, or a chat attachment already in your runtime) \u2192 create_upload mints a signed URL the bytes get PUT to, then deploy_site {path, upload_id}. (Agents with a local filesystem deploy the directory instead \u2014 binaries ride along.) To move or duplicate an ALREADY-DEPLOYED file, {path, from_path} copies it server-side \u2014 never re-upload unchanged bytes, and once an upload_id exists, reference it rather than inlining the same bytes again. Inline base64 content is capped at 1 MB and exists only for tiny pasted assets like a favicon.
+- REFERENCE, don't inline: never base64-encode a file \u2014 not by hand, not in code, and never as a data: URI in HTML. To ship an image or other binary asset, pick the route by where the bytes live: already at a public URL \u2192 deploy_site {path, source_url}, fetched server-side; a local file (the user's, or a chat attachment already in your runtime) \u2192 create_upload returns a link the user opens in their browser to drag files in; when they say done, call create_upload {session} for the upload_ids, then deploy_site {path, upload_id}. (Agents with a local filesystem deploy the directory instead \u2014 binaries ride along.) To move or duplicate an ALREADY-DEPLOYED file, {path, from_path} copies it server-side \u2014 never re-upload unchanged bytes, and once an upload_id exists, reference it rather than inlining the same bytes again. Inline base64 content is capped at 1 MB and exists only for tiny pasted assets like a favicon.
 - MERGE, don't replace: to change a few fields of a database row, write_db update with \`merge\` (null deletes a field). No need to fetch the row first.
 - UNDO by version, never by inverse edits: every deploy is a numbered version the platform keeps. When the user wants a change undone, call revert_site \u2014 it restores the exact bytes of any prior version in one call and proves it. Reconstructing old content from memory with edit_site is how sites end up in a state that is neither old nor new.
 - LOOK at what shipped: you have no browser, but preview_site returns a real rendered screenshot of any version \u2014 your only way to see visual results. Use it after layout/style/animation work, or to eyeball an old version before reverting.
@@ -27757,7 +27761,8 @@ continue in a later session:
   Already at a public URL \u2192 deploy_site \`{path, source_url}\` (fetched
   server-side). Local file and you have the filesystem \u2192 deploy the directory
   (binaries ride along). Local file but chat-only (remote MCP) \u2192
-  \`create_upload\` mints a signed URL the user uploads the file to, then
+  \`create_upload\` returns a browser drag-and-drop link for the user; once
+  they're done, \`create_upload {session}\` lists the upload_ids, then
   deploy_site \`{path, upload_id}\`. To rename or duplicate an already-deployed
   file, deploy_site \`{path, from_path}\` copies it server-side (with
   \`delete_paths\`, a move). Never hand-generate base64 \u2014 inline base64 is

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "drivethrough-cli",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Agent-first hosting CLI. Say what you want. Stay in the car.",
   "type": "module",
   "license": "MIT",