Skip to content

From a tool call to a hosted environment

Try it here. Connect your agent.

Use the catalog playground for a quick experiment. Use a dedicated environment when an agent needs a controlled set of MCP services and isolated session state.

Available in the playground

Website preview

Public, synthetic mock data served through the website. Inspect tools, edit JSON, run calls, and reset your temporary session.

Requires a configured control plane

GKE environment

A dedicated namespace with selected providers, private MCP services, an authenticated gateway, and a bounded environment lifetime.

For operators

Deployment guide

Existing manifests, image and gateway configuration, resource limits, session behavior, and cleanup instructions.

How the GKE endpoint works

The existing design keeps provider pods private. A single authenticated gateway checks project ownership and environment readiness before forwarding a tool call.

01 · MCP client

Your agent or the environment console sends a tool request.

02 · Gateway

Authenticates the caller and resolves a ready environment.

03 · GKE service

A ClusterIP service routes to the selected provider pod.

04 · Mock session

The tool reads or updates isolated synthetic state and returns a result.

Provider manifests request 250m CPU and 512Mi memory, with limits of 1 CPU and 2Gi memory per pod. The current design uses one replica per provider and temporary session storage; pod replacement discards session changes. Durable sessions require storage and session routing beyond this configuration.

GKE hosting covers the configured provider set. Catalog availability does not mean that every service already has a GKE deployment. Repository manifests include placeholder image digests, so an operator must complete the deployment guide before provisioning. This page does not create a cluster or claim a running deployment.

GKE services and networking ↗

GKE setup guide

For operators with access to the Blobfish deployment repository. Use the existing cluster and GitOps workflow; each provider gets a private Service, rather than its own public load balancer.

  1. Configure the cluster control plane. Register the provider cluster with Argo CD and complete infra/gitops/README.md. Configure the existing platform and twin-environment release pipelines, restricted Argo projects, and convergence notifications.
  2. Publish deployable images. Replace placeholder image digests in infra/gitops/overlays/prod/kustomization.yaml and the twin-environment release configuration with real, digest-pinned runtime images and a source commit. A catalog entry alone is not a container deployment.
  3. Wire the gateway. Set BLOBFISH_TWIN_CONTROL_PLANE_URL, BLOBFISH_TWIN_GATEWAY_BASE_URL, and BLOBFISH_TWIN_GATEWAY_CA_PEM_BASE64 in routing configuration. Keep pipeline and gateway credentials in secret stores.
  4. Deploy bounded provider workloads. The existing infra/gitops/base/mcp-service template uses one replica, a ClusterIP Service, NetworkPolicy, a non-root runtime, and limited temporary storage. Generated workloads use the admitted MCP runtime under gVisor. Add services through the release process so they are available to environment setup.
  5. Create and connect. Select the cluster plane in environment setup (API field plane: "cluster"). The gateway exposes a provider only after its environment is unexpired and Argo CD reports synced, healthy workloads.
  6. Bound cost and clean up. Keep the six-hour lease cap and expiry sweep enabled. Delete disposable environment workloads when finished; preserve generated world artifacts and world buckets.

Hosting a new cluster is an operator deployment action. Browsing this catalog or testing a preview does not create or update cloud infrastructure.

Connect to a hosted MCP

  1. Open environment setup and select Cluster plane (GitOps) when available. Choose supported providers and a bounded lifetime.
  2. Wait for the environment console to report that the provider is ready. Copy its actual MCP URL; the template below needs your environment ID and service.
  3. Connect a Streamable HTTP client with your Blobfish API key in X-API-Key. Initialize, keep the returned Mcp-Session-Id, acknowledge initialization, and list the tools.
  4. Call a tool with JSON arguments and inspect its returned content. Keep the session ID to observe state changes across calls.

Endpoint template

https://blobfish.ai/api/v1/twin/environments/{envId}/mcps/{service}/mcp

Initialize request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "my-mcp-client",
      "version": "1.0.0"
    }
  }
}

Send Content-Type: application/json and Accept: application/json, text/event-stream. After initialization, send MCP-Protocol-Version: 2025-11-25 and the session header. This is the compatibility flow supported by the existing gateway.

After notifications/initialized, use tools/list to discover input schemas and tools/call with params.name and params.arguments. Output schemas are optional; actual tool results remain inspectable.

Delete the temporary environment when finished or let its lease expire. Current policy permits a maximum six-hour lifetime. Generated world artifacts are retained separately.