Connect Devin Desktop, Cline, Zed, JetBrains and Goose to the Functionize MCP Server

This article covers Devin Desktop (formerly Windsurf), Cline, Zed, JetBrains IDEs and Goose. All of them can reach the Functionize MCP server; most connect natively, and one needs a small bridge.

Cursor, VS Code, Gemini CLI, Claude Code, Claude Desktop and ChatGPT each have their own article.

Before you start: the endpoint

Every tool below needs the same value:

https://mcp.functionize.com/mcp

Sign-in is always with the same account you use for Functionize Studio, or your organisation's SSO. There is no separate MCP account.

The config key names differ between tools. That is the main hazard when copying a snippet from elsewhere — each section below gives the correct shape.

Devin Desktop (formerly Windsurf)

Windsurf was renamed Devin Desktop in June 2026, and the old documentation URLs now redirect. If you are following an older guide, the paths in it are out of date.

Config file:

macOS and Linux	`~/.config/devin/mcp_config.json`
Windows	`%APPDATA%\devin\mcp_config.json`

You can open it from the Cascade panel: the … actions menu, top right, then Open MCP config file.

{
  "mcpServers": {
    "functionize": {
      "serverUrl": "https://mcp.functionize.com/mcp",
      "headers": {
        "X-Functionize-Team-Id": "12345"
      }
    }
  }
}

Note serverUrl, not url. Devin Desktop is the only tool in this set that uses that key. There is no type or transport field.

OAuth is handled natively — authorisation opens your provider directly in the browser.

Two things that catch people out. Cascade has a ceiling of 100 tools available at once, so if you already run several MCP servers, Functionize's tools can be crowded out without an obvious error. And on enterprise plans, admins can allowlist approved MCP servers — once any server is allowlisted, every server that is not on the list is blocked. If nothing connects and you are on an enterprise plan, ask your admin to allow https://mcp.functionize.com/mcp.

Cline

Use the interface rather than editing files — Cline does not publish the config path for the VS Code extension, and it varies by VS Code flavour.

Open the Cline panel, click the MCP Servers icon in the top toolbar, choose the Remote Servers tab, and fill in:

Server Name: functionize
Server URL: https://mcp.functionize.com/mcp
Transport Type: Streamable HTTP

If you do edit the JSON directly, through the Configure tab:

{
  "mcpServers": {
    "functionize": {
      "type": "streamableHttp",
      "url": "https://mcp.functionize.com/mcp",
      "headers": {
        "X-Functionize-Team-Id": "12345"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

"type": "streamableHttp" is not optional here. Cline defaults to legacy SSE when the type is missing, for backwards compatibility. A snippet copied from another tool — where no type key is needed — will silently connect the wrong way.

On OAuth: Cline's documentation covers static headers only and does not describe an OAuth flow, although its changelog suggests one exists. Try the native configuration first. If sign-in never happens, use the bridge described at the end of this article.

Zed

Zed calls MCP servers "context servers", and they live in your settings file rather than a dedicated one.

macOS and Linux	`~/.config/zed/settings.json`
Windows	`%APPDATA%\Zed\settings.json`

On macOS that is ~/.config/zed/, not Application Support — which surprises people. The safest route is the zed: open settings file command, or Settings → AI → MCP Servers → Add Server → Add Remote Server.

{
  "context_servers": {
    "functionize": {
      "url": "https://mcp.functionize.com/mcp"
    }
  }
}

The top-level key is context_servers, not mcpServers. There is no type or transport field.

Zed's OAuth behaviour is worth understanding: when a remote server has no Authorization header configured, Zed prompts you to authenticate using the standard MCP OAuth flow. Setting an Authorization header suppresses that prompt. Our team header is X-Functionize-Team-Id, not Authorization, so you can add it without disabling sign-in:

{
  "context_servers": {
    "functionize": {
      "url": "https://mcp.functionize.com/mcp",
      "headers": {
        "X-Functionize-Team-Id": "12345"
      }
    }
  }
}

If you see a settings-migration prompt after adding a server with only a url, update Zed — that was a known bug fixed in September 2026.

JetBrains IDEs

JetBrains ships two different MCP clients, and they behave differently. Check which you are using.

Junie — connects natively

Config file, same on macOS and Windows:

Project: .junie/mcp/mcp.json in the project root
You, everywhere: ~/.junie/mcp/mcp.json

{
  "mcpServers": {
    "functionize": {
      "url": "https://mcp.functionize.com/mcp",
      "headers": {
        "X-Functionize-Team-Id": "12345"
      }
    }
  }
}

Servers needing sign-in show as Authorization required. Open the MCP Installation Assistant, select the server, choose Authorize, and complete the login in the browser page that opens. The status changes to Active. Manage it afterwards with the /mcp command.

AI Assistant — needs the bridge

JetBrains AI Assistant does not support OAuth for MCP servers. It is an open, unresolved feature request on their own issue tracker — there is currently no way for it to start an authorization flow or store the resulting token. It therefore needs the bridge below.

Add it through Settings | Tools | AI Assistant | Model Context Protocol (MCP), using the bridged configuration from the last section of this article. Use the Settings screen rather than looking for a file — JetBrains does not document where AI Assistant stores this on either operating system.

Goose

Goose uses YAML, and calls MCP servers "extensions".

macOS and Linux	`~/.config/goose/config.yaml`
Windows	`%APPDATA%\Block\goose\config\config.yaml`

The easiest route is goose configure → Add Extension → Remote Extension (Streamable HTTP), then paste the URL. Note that this flow does not prompt for custom headers, so add those by editing the file afterwards.

extensions:
  functionize:
    type: streamable_http
    name: functionize
    enabled: true
    uri: "https://mcp.functionize.com/mcp"
    headers:
      X-Functionize-Team-Id: "12345"
    timeout: 300

Note uri, not url, and that timeout is in seconds — other tools use milliseconds for the same field. SSE is no longer supported by Goose; streamable_http is correct for our server.

OAuth is native, using a loopback callback on 127.0.0.1 with a random port. If you ever need that port fixed, set the GOOSE_OAUTH_CALLBACK_PORT environment variable.

The bridge, for anything that cannot do OAuth

If a client only speaks stdio, or cannot complete an OAuth flow, a small program called mcp-remote runs locally and presents our remote server as a local one. It needs Node.js 18 or newer.

{
  "mcpServers": {
    "functionize": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://mcp.functionize.com/mcp",
        "--transport", "http-only",
        "--header", "X-Functionize-Team-Id:12345"
      ]
    }
  }
}

Write the header with no space after the colon. Several clients have a bug where spaces inside arguments are not escaped correctly, and the header is silently dropped. This is the most common bridge failure.

--transport http-only tells the bridge not to waste a round trip probing for SSE, which our server does not use.

Tokens are cached in ~/.mcp-auth, or %USERPROFILE%\.mcp-auth on Windows. Deleting that directory forces a fresh sign-in. Note that it clears cached tokens for every bridged server, not only ours.

To test the bridge outside your editor, which gives much clearer error messages:

npx -p mcp-remote@latest mcp-remote-client https://mcp.functionize.com/mcp

Checking any of them worked

Ask the tool to list your Functionize agent sessions. If your team's sessions come back, you are connected. The list is team-wide, so on a shared team you will see colleagues' sessions too.

One caveat about team pinning

No MCP client vendor documents whether a static custom header is still sent once an OAuth token is attached. The configuration format supports it everywhere above, but if the pinned team does not take effect, confirm the connection works without the header first and then raise it with us. Use list_agent_teams to see which team a connection is actually acting as.

Search