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.
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.
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.
Status: Live
Docs: /docs - OpenAPI: /openapi.json - Terms: /terms - Privacy: /privacy
Free SDK shims: client shim - server shim
Support: support@textforagents.com