Jenkins MCP ready on private worker but cloud agent chat says live tool discovery failed

Support Help
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

I’m trying to use the Jenkins MCP server from cloud agent chat, with a self-hosted / private worker that can reach our internal Jenkins.

What I want
From an agent chat session, call Jenkins MCP tools (e.g. get build status, trigger a job).

My setup

  • Jenkins MCP plugin at http://10.1.10.60:8080/mcp-server/mcp (private LAN, not public internet).
  • ~/.cursor/mcp.json uses npx mcp-remote with --allow-http and Basic auth in a custom header.
  • Cloud agent runs on my private worker (usePrivateWorker: true, worker name e.g. jenkins-agent).

What works on the worker

  • mcp-remote is running.
  • agent mcp list shows jenkins: ready.
  • agent mcp list-tools jenkins lists all tools.
  • Direct HTTP to Jenkins MCP (initialize, tools/list, whoAmI) works from the same machine.

What fails in chat

  • GetDynamicTools for namespace jenkins shows namespaceStatus: error — “failed during live tool discovery”.
  • CallDynamicTool says MCP server does not exist: jenkins.

So the worker MCP looks healthy, but chat doesn’t seem to use that connection for tool calls.

Question
For private workers + MCP servers on internal IPs, should chat MCP tools run through the worker’s mcp-remote process? If yes, is this a known bug or missing piece? What’s the recommended setup today?

Thanks.

Steps to Reproduce

Run local mcp server from cloud agent

Operating System

Linux

Version Information

CLI Version 2026.09.18-9a7762b

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

found a similar issue Local MCP Servers are not availble on Remote Control sessions

thanks

6

Hey @Chandrahaas, thanks for the detailed report.

What you are seeing is how MCP is routed for self-hosted machines today: MCP servers configured with a URL (HTTP / Streamable HTTP) are connected from Cursor’s backend, not from your worker, so a private address like http://10.1.10.60:8080 is unreachable from there and shows up as “failed during live tool discovery”. MCP servers configured with a command (stdio) are started on your worker machine and share its network. Your jenkins entry in the Cloud Agents MCP settings is currently the URL type, which is why the agent can never reach it.

The ~/.cursor/mcp.json on the worker is used by the local CLI (agent mcp list), which is why that side looks healthy, but cloud agent sessions get their MCP set from the Cloud Agents MCP settings.

To get this working:

  1. Open cursor.com/agents and go to the MCP Servers settings.
  2. Delete (or edit) the existing jenkins server that points at http://10.1.10.60:8080/mcp-server/mcp.
  3. Add a Custom MCP and choose the Command (stdio) type instead of URL.
  4. Fill it in like this:
{
  "command": "npx",
  "args": ["-y", "mcp-remote", "http://10.1.10.60:8080/mcp-server/mcp", "--allow-http", "--header", "Authorization:${AUTH_HEADER}"],
  "env": { "AUTH_HEADER": "Basic <your base64 user:token>" }
}

(Passing the header value through AUTH_HEADER avoids problems with the space in Basic ...; mcp-remote expands it itself.)

  1. Save, make sure the server is enabled for your Cloud Agents, and make sure npx is on the PATH of the shell that runs agent worker.
  2. Start a new agent on your worker (existing sessions keep the old MCP set) and try whoAmI again.
8

Hey @Colin thanks for the response
yeah it worked when I re-registerd the mcp server form cloud