mcp-optimizer cannot discover remote workloads (`thv serve` API doesn't return them)

[gkatz2]

Problem

The ToolHive API (/api/v1beta/workloads) does not return running remote workloads that are visible via thv list. This causes mcp-optimizer to not discover those servers.

Without a fix, mcp-optimizer is much less useful for reducing context window bloat because remote servers must be registered separately with MCP clients, bypassing mcp-optimizer entirely.

Environment

• ToolHive: v0.6.17
• Platform: macOS (darwin/arm64)

Steps to Reproduce

1. Start the API server:

   thv serve --port 50000

2. Run a container-based workload:

   thv run time

3. Run a remote workload:

   thv run --name cloudflare_docs https://docs.mcp.cloudflare.com/sse

4. Verify both appear in CLI:

   thv list
   # Shows both time (container) and cloudflare_docs (remote)

5. Query the API:

   curl http://127.0.0.1:50000/api/v1beta/workloads

6. Observe that the remote workload is missing from the API response

Expected Behavior

API returns both workloads:

{
  "workloads": [
    {"name": "time", "remote": null, ...},
    {"name": "cloudflare_docs", "remote": true, ...}
  ]
}

Actual Behavior

API returns only the container workload:

{
  "workloads": [
    {"name": "time", "remote": null, ...}
  ]
}

Individual query also fails:

curl http://127.0.0.1:50000/api/v1beta/workloads/cloudflare_docs
# Returns: "Workload configuration not found"

Notes

• thv list correctly shows both workloads
• The discrepancy is between the CLI and the thv serve API
• This may indicate an issue with how remote workload state is stored/retrieved by the API server

Impact

mcp-optimizer cannot discover running remote workloads, making those tools unavailable to MCP clients.

[aponcedeleonch]

Hello @gkatz2 ! Thanks for submitting the issue. However, I am not able to fully reproduce it. If I do

% thv run https://docs.mcp.cloudflare.com/sse --transport sse --name cloudflare_docs

the workload hangs forever in Starting state. Workloads in Starting state are not listed.

But then if I specify the transport of the remote MCP server, the workload starts correctly, full command:

% thv run https://docs.mcp.cloudflare.com/sse --transport sse --name cloudflare_docs

Querying the API (curl http://localhost:8080/api/v1beta/workloads | jq), I get

{
  "name": "cloudflare_docs",
  "package": "remote",
  "url": "http://127.0.0.1:20526/sse#cloudflare_docs",
  "port": 20526,
  "transport_type": "sse",
  "proxy_mode": "sse",
  "status": "running",
  "created_at": "2026-01-12T17:37:37.27355+02:00",
  "labels": {
    "toolhive": "true",
    "toolhive-basename": "cloudflare_docs",
    "toolhive-name": "cloudflare_docs",
    "toolhive-port": "20526",
    "toolhive-transport": "sse"
  },
  "group": "default",
  "remote": true
}

Nonetheless, I do see an issue in the ingestion of this workload in MCP Optimizer. I am looking into it and once I have triaged the issue I will open the issue in Optimizer's repo. Feel free to also open it yourself in case you have already done so.

Let me know if you have any question getting Cloudflare remote MCP server running

[aponcedeleonch]

Just created this other issue as a result of my investigation for this one: #3261

[gkatz2]

Thanks for the quick response and the --transport sse tip!

I did more testing and I can't reproduce the bug with a fresh setup. Here's what I found:

Clean repro attempt (v0.6.17):

# Kill all thv serve, confirm none running
pkill -f "thv serve"

# Start fresh thv serve
thv serve --port 50000 &

# Add remote workload AFTER serve is running
thv run https://docs.mcp.cloudflare.com/sse --transport sse --name repro_test

# Check API
curl -s http://127.0.0.1:50000/api/v1beta/workloads | jq '.workloads[]'
# Result: repro_test DOES appear with remote: true ✅

What I originally observed:

• I had a thv serve process that had been running for several days
• Remote workloads showed in thv list but not in the API
• Restarting thv serve fixed it immediately

Conclusion:
I can't provide reliable repro steps because a fresh thv serve works correctly.

Since restarting thv serve fixed it and I can't reproduce it fresh, feel free to close this issue. If I encounter it again, I'll gather more details before reporting.

[aponcedeleonch]

Thanks @gkatz2 ! I will proceed to close this issue. I did found an issue when mcp-optimizer tried to ingest Cloudflare MCP server and I've created an issue in that repo: StacklokLabs/mcp-optimizer#255 . I will follow-up there :)