NVIDIA / NVIDIA/NemoClaw

[DGX Spark][Policy&Network] mcp status reports no valid endpoint for a trusted-private-host MCP server

Open
#11,376 0 comments 0 reactions 1 assignee Claimed by @Dongni-Yang View on GitHub
area: policy integration: openclaw platform: arm64 platform: dgx-spark platform: ubuntu
Dominant language
TypeScript
Stars
22.5k
Forks
3.1k
Avg merge
1d 1h
Merged PRs (30d)
715

Description

## Description

A managed MCP server registered against a trusted private (RFC1918) address via the documented `--trusted-private-host` flag adds successfully, but every subsequent tool-discovery check against that same server fails with a generic "no valid managed endpoint is available" message instead of listing its tools.

Platform scope: Reproduced on DGX Spark only this session; other platforms not tested.
Regression: Unknown - earlier versions not tested this session. A related, previously-filed issue (#8746) investigated the same symptom class on an older OpenShell version and was closed in 2026-08 without a root cause being assigned - this may be the same long-standing defect.

## Environment

```text
Device: DGX Spark
OS: Ubuntu (aarch64)
Architecture: aarch64
Node.js: v22.22.1
npm: 10.9.4
Docker: 28.3.3 (build 980b856)
OpenShell CLI: openshell 0.0.106
NemoClaw: v0.0.121
OpenClaw: 2026.7.1 (2d2ddc4)
```

## Steps to Reproduce

1. Stand up any HTTPS Streamable HTTP MCP server reachable at a private/RFC1918 address (e.g. a Docker bridge IP), advertising at least one tool.
2. Register it against a Ready sandbox using the documented trusted-private-host mechanism:
```bash
nemoclaw {sandbox} mcp add {server} --url https://{private-ip}:{port}/mcp --env {KEY} --trusted-private-host {private-ip}
```
3. Confirm the add succeeded - the command's own output reports the provider attached, the policy applied, and `"trustedPrivateTarget": {"state": "match"}`.
4. Run:
```bash
nemoclaw {sandbox} mcp status {server} --tools --json
```

## Expected Result

Tool discovery succeeds and returns the MCP server's advertised tools, since the server was just confirmed registered and trusted in step 3.

## Actual Result

Tool discovery always fails, immediately and consistently across repeated attempts, with:

```json
{
"toolDiscovery": {
"ok": false,
"count": 0,
"tools": [],
"detail": "tool discovery skipped: no valid managed endpoint is available",
"failedStage": "preflight",
"failureClass": "precondition"
}
}
```

The rest of the status output (provider attachment, credential readiness, policy presence, `trustedPrivateTarget.state`) all report healthy/matched - only tool discovery fails, with a message that gives no indication the private-host trust context is the actual problem.

## Logs

Not captured beyond the `--json` output shown above.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.