kubbiai

Cross-vendor MCP handoff

Your MCP server returns a claim URL. Another vendor's MCP-enabled agent claims the payload. Neither side exposes a bucket. The trust boundary between organizations is real, and the payload is sensitive.

How it works

Producer (your MCP server or agent):

  1. Call kubbi_send (or kubbi_send_files for bundles) with the payload, TTL, and burn policy.
  2. Return the claim URL as the MCP tool result.

Consumer (another vendor's agent):

  1. Receive the claim URL via the MCP tool call result.
  2. Call kubbi_inspect to preview metadata without consuming.
  3. Call kubbi_claim to retrieve the payload. The kubbi burns after the configured max_retrievals.

No API keys cross organizations. No buckets exposed. The two MCP servers communicate by passing URLs.

Examples

Research agent → third-party summarisation service

Company A's autonomous research agent drops findings (~80 KB JSON) into a kubbi with max_retrievals: 1 and a 30-minute TTL. The claim URL goes out as the MCP tool result. Company B's summariser claims the kubbi when it runs. Neither company's system ever holds the other's data directly.

Partner org → onboarding agent

Partner organisation's ops team creates a kubbi containing API keys, tenant config, and a private certificate (1 hour TTL, single-read). The claim URL goes via a standard channel to the customer onboarding AI agent. Secrets are burned immediately after claim.

Related