In your tool
plungeai-in-bolt
Connect Bolt.new to PlungeAI (Ocean Studio) over MCP — the Connectors → Custom MCP server form, the all-tools/all-projects toggle behavior, keeping the shipped app's key server-side, and a plungeai_whoami + plungeai_list_agents verify.
Connect Bolt.new to PlungeAI (Ocean Studio) over MCP — the Connectors → Custom MCP server form, the all-tools/all-projects toggle behavior, keeping the shipped app's key server-side, and a plungeai_whoami + plungeai_list_agents verify. Use when the user is in Bolt.new and says connect / install / set up PlungeAI, mentions Custom MCP server, or a deployed Bolt app 401s against PlungeAI. For another builder use its plungeai-in-<tool> skill; for an unlisted but MCP-capable client use plungeai-mcp-setup's generic client config.
Download zip (opens in a new tab) · View raw SKILL.md (opens in a new tab)
Bolt is a hosted builder: there is no local config file and no JSON entry anywhere — the connector form is the only surface, and the key lives only in its credential.
Prerequisites
- An
ozk_key: Dashboard → One API → Keys (https://dashboard.plungeai.com (opens in a new tab)) — self-service, shown once, copy it now.
Connect (once)
From the Bolt homepage chatbox: click the + icon → Connectors → Manage connectors → Custom MCP server, then fill:
| Field | Value |
|---|---|
| Name | PlungeAI |
| URL | https://mcp.plungeai.com/v1 |
| Transport type | HTTP (use SSE only if a server's docs say so — PlungeAI's is HTTP) |
| Authentication | select API key and enter the ozk_ key (or MCP OAuth — not available for PlungeAI yet) |
Bolt does not document which header the API-key field sends; the PlungeAI
server accepts both X-API-Key: ozk_YOUR_KEY and
Authorization: Bearer ozk_YOUR_KEY, so the raw key works — confirm with
plungeai_whoami (Verify below).
Verify
- Builder chat: "use plungeai_whoami to confirm my identity" → an identity card.
- Generated app (server side):
curl -H "Authorization: Bearer ozk_YOUR_KEY" https://api.plungeai.com/v1/agents→ HTTP 200 JSON. - "use plungeai_list_agents to search 'web search'" → live results from the active agent catalog.
Quirks — the toggles that bite
- Auto-enable for all projects controls whether the connector turns on automatically in each new project — existing projects enable it from the same Connectors menu.
- Adding a connector turns on all its tools by default, and the tool list is global — you can't turn tools on/off per project. Trim the tool list once, globally, if the builder gets tool-choice-noisy.
- Tools missing mid-session → Manage connectors: check the connector is enabled for this project and its tool toggles are on, then retry.
- The connector credential authenticates the BUILDER only. The shipped app
needs its own wiring: a server function holding
PLUNGEAI_API_KEYas an env var that proxies the One API. An app that "worked in preview" but 401s when deployed usually shipped without the env var set. The key must never appear in the client bundle or a browserfetch. - Long CNL workflows can exceed a builder-chat step budget — prefer async
mode (
plungeai_execute_workflowwithmode: "async"+plungeai_get_workflow_status).
Where next
- Writing the server-side proxy that calls
https://api.plungeai.com: plungeai-api-setup. - Operating the
plungeai_*tools in chat: plungeai-mcp-setup. - Picking MCP vs the One API for a given job: choose-your-plungeai-door.
- An unlisted but MCP-capable client, or the shared connect concepts (native remote vs. stdio bridge, key hygiene): plungeai-mcp-setup.
- Full guide: https://mcp.plungeai.com/docs#3-connecting-clients (opens in a new tab)