{"name":"echodrop","version":"0.1.0","protocolVersion":"2024-11-05","transport":"streamable-http","auth":{"scheme":"Bearer","tokenFormat":"echodrop_pat_*","docs":"/how/mcp"},"instructions":"EchoDrop pickup workflow for AI assistants:\n\n1. Always call `inspect_pickup` first with the pickup code. This returns the\n   file list with sizes, password requirement, expiry, and remaining downloads.\n   It does not consume a download slot.\n\n2. Check sizes. The server caps inline byte delivery at ~5 MB per file\n   (configurable per instance). Bucket files into \"fits\" and \"too large\".\n\n3. If any files are too large, tell the user up front, e.g.:\n   \"This drop has N files. K can be delivered inline; the other (N-K) exceed\n   the inline limit. Options: (a) fetch the K small ones now, (b) for the\n   large ones I'll give you the source URLs to download in your browser, or\n   if you have shell access I can curl them down for you, (c) both.\"\n\n4. Call `pickup_drop` with the code, the password (if required), and\n   optionally a `fileIndices` array to fetch a subset. Each successful\n   call consumes one download slot from `maxDownloads` and generates a\n   signed receipt visible to the drop owner. One password unlock = one\n   complete transfer.\n\n5. Files that exceed the inline cap are returned as JSON entries with\n   `{ tooLarge: true, sourceUrl, sizeBytes }` rather than bytes. Do not\n   retry them through MCP — fall back to the source URL.\n\n6. If a drop is `accessMode: \"consume_once\"` (burn-after-reading), pickup\n   via MCP works the same way but the drop is destroyed after the call;\n   warn the user before proceeding.\n\n7. The recipient acts under their own EchoDrop identity (PAT). The audit\n   trail logs every `mcp_inspect` and `mcp_pickup` event."}