{"product": "P186", "name": "Binary Transfer Lane for MCP", "version": "1.0.0", "provider": "TextForAgents LLC", "one_liner": "Your agent's file has no way through MCP. This is the lane: one signed, hash-bound transfer per tool call, with a delivery receipt the call itself can prove.", "description": "MCP defines no file content type for tool-call arguments - binary exists only as base64 inside results, through the model's context, where it truncates around 2.5 MB, burns ~850k tokens of context for a single 2.5 MB file, and can corrupt in transit. A field test of 7 official MCP services found 0 with file-upload support; the draft spec fixes are elicitation-shaped (a server asking a user for a file) and unshipped, so agent-generated files - the receipt PDF, the PR screenshot, the attachment no human picked - have no lane at all. This service is that lane, adoptable today by any client x server pair. (1) Call-bound mint - before any byte moves, the service mints a single-use, short-expiry signed upload token bound to one specific tool call: (server identity, tool name, call id, declared mime, declared size, declared SHA-256). (2) Verified arrival, signed receipt - the file moves out-of-band, never through the model or the protocol; on arrival the service verifies size + SHA-256 against the declaration and only then issues a signed delivery receipt. A hash- or size-mismatched upload gets no receipt (422) and the tool call cannot reference it. The receipt - not the file - crosses the protocol as the call's file argument; the receiving server redeems a single-use download token, re-verifies the hash, and completes the call. Upload and download tokens are single-use under concurrency; expired tokens refuse before any byte is stored. (3) Shims, not spec waits - a client shim and a server shim (free downloadable artifacts) let a pair adopt the lane without waiting for any SEP. Proven in the lab: byte-identical delivery at 2.5 MB, 10 MB, and 100 MB; the same shim pair completing transfers for two different server pairs; every replay, forgery, expiry, and mismatch probe refused. Stated plainly: transfers above 1 GB are refused at mint; delivered objects are deleted on delivery and undelivered objects at expiry - this is a transfer lane, not storage; willingness to pay for the lane itself is unmeasured.", "pricing": {"transfer_le_10mb_usd": 0.02, "transfer_le_100mb_usd": 0.1, "transfer_le_1gb_usd": 0.49, "above_1gb": "refused at mint", "server_operator_lane_usd_per_month": 9.0, "lane_allowance": {"transfers": 500, "bytes": 53687091200, "beyond_allowance": "metered at the per-transfer tiers"}, "trial": "one free transfer per operator, ever"}, "how_to_start": "POST /register {operator} -> api_key (shown once). Send it as Authorization: Bearer <token> or X-Api-Key. Your first transfer is free (one-time trial). POST /transfers mints the call-bound upload token; PUT the bytes to /upload/<id> with X-Upload-Token; verify the signed receipt via POST /verify-receipt; redeem once via GET /download/<id> with X-Download-Token. Paid mints answer 402 with an x402 challenge; pay it and resend with the X-PAYMENT header.", "endpoints": {"POST /register": "self-serve registration (unauthenticated); returns your api token once", "POST /transfers": "mint a call-bound single-use upload token ($0.02 <=10MB / $0.10 <=100MB / $0.49 <=1GB; first transfer per operator free, ever; server-lane allowance covers first)", "PUT /upload/<transfer_id>": "upload the declared bytes with header X-Upload-Token; size+SHA-256 verified on arrival; mismatch -> 422, no receipt", "POST /verify-receipt": "verify a signed delivery receipt against its call_id (wrong call_id -> 403)", "GET /download/<transfer_id>": "single-use redemption with header X-Download-Token; object deleted on delivery", "POST /subscribe": "buy the server-operator lane ($9/mo, stated allowance enforced in code)", "GET /account": "your account, trial state, lane periods and transfers (auth)", "GET /health": "service health"}, "support": "support@textforagents.com"}