Claim-check for agent handoffs.

kubbi holds the payload. Your channel carries the URL.

Pair kubbi with your queue, webhook, MCP tool result, or A2A message. Every payload is encrypted with TTL. Burn-after-read and manifest preview are server-enforced when you ask for them.

Get an API key Read the docs

const client = new KubbiClient({ apiKey })
const { claimUrl } = await client.sendFiles({
  files: [
    { name: "config.json", content, contentType: "application/json" },
    { name: "data.csv",    content, contentType: "text/csv" },
    { name: "report.md",   content, contentType: "text/markdown" },
  ],
  ttlSeconds: 3600,
  maxRetrievals: 1,
})

Pair it with your channel

Your agents already pass messages. Through a queue, a webhook, an MCP tool result, an A2A message. Those channels are great for control flow. They're awkward for payloads: size limits, sensitive data sitting in logs, multi-file bundles that don't fit inline.

kubbi takes the payload off the channel. The producer stores it once and gets back a claim URL. The channel carries the URL. The consumer claims the payload when ready.

Capabilities tailored to agentic use cases

Four behaviors built for how agents actually pass payloads. All server-enforced, no setup or background plumbing on your side.

Burn-after-read

Every kubbi has a retrieval limit. Hit it and the payload is gone. Server-enforced, not a flag you remember to set.

Short TTL

Payloads expire on a clock. Set it to seconds, minutes, or hours. Defaults are short so stale data doesn't linger.

Encrypted at rest

AES-256-GCM with per-payload IV and auth tag. No setup, no Lambda, no IAM policy you maintain.

Manifest preview

Consumers see what's in a kubbi before claiming it. File names, sizes, types. Useful for verifying without burning the retrieval count.

Three calls

Send a payload, share the URL, claim it. The producer authenticates with an API key. The consumer claims with the URL alone.

first kubbi

// Producer
const { claimUrl } = await kubbi.send({
  content: payload,
  ttlSeconds: 3600,
  maxRetrievals: 1,
});
// Pass claimUrl through your queue, webhook, or MCP tool result

// Consumer
const payload = await kubbi.claim(claimUrl);

Anatomy of a handoff

From send to terminal state. The kubbi sits encrypted and awaiting claim. Consumers can inspect without retrieving. The row is wiped server-side when the kubbi ends.

Three terminal states wipe the row: expired (TTL elapsed), burned (max_retrievals reached), and deleted (producer wiped early). Ciphertext is overwritten on the storage layer before the status is updated. The encryption key is removed alongside.

TTL and retrievals Encryption and storage

How kubbi compares to other solutions

How kubbi stacks up against the most common alternatives teams reach for when they need to pass payloads between agents: S3 with presigned URLs, raw webhooks, inline queue messages, and rolling your own claim-check service.

Compared to	What kubbi adds
S3 + presigned URLs	Server-enforced burn-after-read. Multi-file bundling. Agent-shaped SDK. Defaults on.
Raw webhook with inline payload	The payload doesn't sit in your webhook logs. No size limit.
Queue with inline payload	No 256 KB cap. No sensitive data lingering in SQS.
Building it yourself	KMS, expiry enforcement, audit, manifest preview, all handled.

A team comfortable with cloud primitives could build a claim-check service in a weekend. We did it for you and added defaults that match how agents actually pass payloads.

Read the full comparison

Where kubbi best fits

Four patterns, one per primary channel. kubbi delivers the most value at cross-trust-boundary handoffs: cross-vendor agents, sensitive payloads on shared channels, packages that need atomic delivery. Each pattern doc has a concrete example flow.

Cross-vendor MCP handoff

Your MCP server returns a claim URL. Another vendor's agent claims the payload. Neither side exposes a bucket. The trust boundary between organizations is exactly where claim-check defaults pay off.

A2A payload side-channel

The A2A message carries control: typing, addressing, ordering. kubbi carries the bytes. Works across organizational boundaries because neither side has to share storage credentials.

Webhook with a thin payload

Receivers want fast notifications, not megabytes. Send the URL in the webhook body. The receiver calls back for the payload only if they need it. Data stops sitting in webhook delivery and gateway logs.

Queue claim-check

Pass an ID through SQS, Kafka, or your queue of choice. Park the payload in kubbi. The 256 KB SQS cap stops mattering. Sensitive data also stops lingering in dead-letter queues.

Use it from your stack

Two SDKs, a REST API, and an MCP server. Pick the surface that fits your runtime.

TypeScript SDK

Install with npm. KubbiClient.send() for single payloads, sendFiles() for packages. Static KubbiClient.claim and inspect for the consumer side.

Python SDK

Install with pip. Sync and async clients. Standalone claim() and inspect() functions for consumers, no API key needed.

REST API

JSON over HTTPS. Bearer auth for producers, claim URL token for consumers. Full endpoint reference with parameter tables and response shapes.

MCP server

Six native tools (kubbi_send, kubbi_send_files, kubbi_claim, kubbi_inspect, kubbi_get, kubbi_delete). Add one config; agents discover the tools at runtime.

Get Started

Free tier covers most agent workflows. Pricing tiers up when you need more.

Get an API key See pricing