Skip to main content
Glama
README.md
# mcp-netassist

**Network & proxy diagnostics as an [MCP](https://modelcontextprotocol.io) server.**

Works with any MCP client — Claude Code, Claude Desktop, Cursor, Reasonix, CodeWhale, DeepSeek Harness. Point your agent at it and ask "is GitHub reachable?", "why is my proxy not working?", "what should I change?" — instead of guessing.

Built for the China-network reality: flaky GitHub, proxies that are half-configured, hosts files that fight the proxy, and TUN mode that silently overrides the system proxy.

> Windows-only for now: the checks call PowerShell. The protocol layer is portable; a POSIX backend is the obvious next step.

## Tools

| Tool | Answers |
|---|---|
| `net_github_status` | Is github.com reachable right now? DNS, TCP 443, HTTPS status + latency |
| `net_proxy_status` | What proxy is the system using? Registry settings + env vars, including a disabled-but-leftover value |
| `net_proxy_probe` | Which local proxy ports are alive? (defaults: 10808, 10809, 7890, 7897, 8888, 1080) |
| `net_diag` | Full chain for any host: DNS → TCP → HTTP status |
| `net_hosts_check` | Which GitHub entries are pinned in the hosts file? |
| `net_doctor` | The whole preflight, with **concrete suggestions about what to change** |

`net_doctor` is the point of this server. Other tools tell you *what is wrong*; it tells you what to do about it:

```
✔ System proxy: 127.0.0.1:10808
✔ Proxy port 10808 responding
✔ GitHub reachable (HTTP 200, 312 ms)
⚠ TUN-style adapter detected: clash
   Under TUN mode the system proxy setting is usually ignored — the two can fight each other.
✔ hosts file clean (no GitHub entries)

Suggested fix:
- Under TUN mode, clear the Windows system proxy (or exclude github.com) so traffic is not double-handled.
```

## Setup

**Claude Desktop / Cursor / any JSON-configured client:**

```json
{
  "mcpServers": {
    "netassist": {
      "command": "npx",
      "args": ["-y", "github:Edge-Echo/mcp-netassist"]
    }
  }
}
```

The built `lib/` ships in the repository, so the GitHub form needs no build step.

**From npm** (once the first release is published):

```json
{
  "mcpServers": {
    "netassist": {
      "command": "npx",
      "args": ["-y", "mcp-netassist"]
    }
  }
}
```

**Claude Code:**

```sh
claude mcp add netassist -- npx -y github:Edge-Echo/mcp-netassist
```

**DeepSeek Harness** (same diagnostics as a native plugin, plus `net_doctor` as an agent tool):

```sh
dsh plugin --profile web add dsh-netassist
```

**From a checkout:**

```json
{
  "mcpServers": {
    "netassist": { "command": "node", "args": ["/path/to/mcp-netassist/lib/server.js"] }
  }
}
```

**In a container:**

```sh
docker build -t mcp-netassist .
docker run -i --rm mcp-netassist
```

> The image is also what directory listings use for introspection checks. Inside a Linux
> container the server starts and answers `initialize` / `tools/list` normally; the tools
> themselves need Windows PowerShell, and say so when it is missing.

## Design notes

- **Read-only.** No tool writes config, changes the proxy, or edits the hosts file. It reports and suggests; you decide.
- **Injection-safe.** Every user input crosses the PowerShell boundary as Base64, never as interpolated text.
- **No hidden state.** Each call runs its own checks; nothing is cached between calls, so results are always current.
- **Two dependencies** (`@modelcontextprotocol/sdk`, `zod`), no native modules.

## Related

Part of the **[dsh-toolkit family](https://github.com/Edge-Echo/dsh-netassist)** — the same diagnostics also ship as a DeepSeek Harness plugin (`dsh-netassist`), which adds `net_doctor` as an agent tool.

## License

MIT

TDQS

A4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a distinct focus: GitHub-specific reachability, system proxy configuration, proxy port probing, generic host diagnostics, hosts file scanning, and a comprehensive preflight. While github_status and diag overlap in concept, their scopes are clearly separated (GitHub vs any host). No two tools are ambiguous.

Naming Consistency4/5

All tools share a consistent 'net_' prefix and snake_case naming, but the second part varies between domain-action patterns (github_status, proxy_status, hosts_check) and simpler names (diag, doctor). The naming is readable and predictable, with only minor inconsistency in verbosity.

Tool Count5/5

With 6 tools, the server covers a focused set of network diagnostics without bloat. Each tool serves a specific diagnostic purpose, and the count feels well-scoped for a troubleshooting utility.

Completeness5/5

The tool set covers the full diagnostic lifecycle: system proxy state, local proxy ports, general host reachability, GitHub-specific checks, hosts file conflicts, and a comprehensive doctor that aggregates findings. No obvious dead ends or missing operations for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues