Connect Cline to Willder

An autonomous coding agent extension for VS Code.

Transport: Streamable HTTP through a pinned mcp-remote@0.14.3 stdio bridge · Auth: Authorization: Bearer <capability token>, read from the bridge's environment · Endpoint: https://willder.ai/api/mcp

Half of this row is verified, and the two halves are different claims. The server's half passes: on 2026-10-05, against deployed commit 2eed3f05, npx tsx scripts/mcp-client-probe.ts --client=cline --transport-only reached https://willder.ai/api/mcp using the pinned mcp-remote@0.14.3 command, argv and env block on this page, over stdio, and the initialisation sequence, tools/list and one scoped memory_query all answered, with an absent token and a wrong token both refused. The client's half is unrun. Nobody has run this client against Willder, so nothing here claims it works. Why: Cline is an IDE extension, and its MCP Servers panel is only visible in the IDE. That needs a person's run recorded in manual-runs.json, naming who ran it, when, and on which commit — see the index.

Get a token

Issue a capability token from Access → Tokens for the narrowest scope you need. The value is shown once. These clients do not document environment interpolation inside headers, which is why the bridge is used: the bridge reads the token from its own env block, so the token lives in one place instead of being pasted into a header string.

export WILLDER_TOKEN='<your capability token>'

Config

In the VS Code extension: the Cline panel → MCP Servers → Configure → Configure MCP Servers, which opens the extension's own cline_mcp_settings.json. In the Cline CLI: ~/.cline/data/settings/cline_mcp_settings.json (CLINE_MCP_SETTINGS_PATH overrides the location).

{
  "mcpServers": {
    "willder": {
      "command": "npx",
      "args": ["-y", "mcp-remote@0.14.3", "https://willder.ai/api/mcp", "--header", "Authorization:${AUTH_HEADER}"],
      "env": { "AUTH_HEADER": "Bearer <your capability token>" }
    }
  }
}

Direct HTTP also works if you are willing to put the token in the file:

{ "mcpServers": { "willder": {
  "type": "streamableHttp",
  "url": "https://willder.ai/api/mcp",
  "headers": { "Authorization": "Bearer <your capability token>" }
} } }

Why a bridge

mcp-remote@0.14.3 is a stdio MCP server that forwards to a remote Streamable HTTP endpoint. It is pinned to an exact version so an upstream change cannot silently alter how these clients connect, and it is the only extra component — there is no Willder-specific binary to install.

There is deliberately no space after Authorization: in the --header argument: several clients do not escape spaces inside args, and mcp-remote expands ${AUTH_HEADER} from the process environment itself, so the token never appears in the command line.

Verify the connection

cline config mcp --json

and check the MCP Servers panel for willder with its tools listed.

Notes

Set type explicitly if you use the direct form. Omitting it means legacy SSE, and Willder's endpoint does not serve the legacy SSE handshake — a client that tries it will open a stream and then hang or error rather than connect.

See the index for the other clients and mcp/README.md for the tool surface and the token rules.