Connect an MCP client to ssid.ai over Streamable HTTP

Short answer: ssid.ai’s MCP server now runs over Streamable HTTP at https://ssid.ai/mcp/http. Point any MCP client that supports that transport at the URL and you get the same four tools as the ssid-mcp npm package, no install step required.

Why this exists

Until now, using ssid’s MCP tools meant adding npx -y ssid-mcp to your client config, which spawns a local process talking stdio. That’s fine for Claude Desktop or a CLI agent running on your own machine, but it doesn’t work for a client that has no shell to spawn a process in, or for a hosted agent that would rather make an outbound HTTP call than manage a child process. Streamable HTTP closes that gap. It’s the same MCP protocol, the same tools, just reached over a URL instead of a subprocess.

The endpoint

https://ssid.ai/mcp/http

Transport type: streamable-http. No API key, no signup, on the free tier — the same as the npm package. Add it to a client’s server config the way you’d add any remote MCP server; the exact config shape depends on the client, but it’s a URL and a transport type, not a command to run.

The four tools, unchanged

Whichever transport you connect over, you get the same tool surface:

• get_router_defaults — the manufacturer-cited factory login, gateway IP, and reset steps for a router model.
• check_router_compliance — whether that model still ships a universal default password.
• lookup_mac — resolves a MAC address to its manufacturer.
• submit_correction — proposes a fix to a router’s default login, the same correction path the site itself uses.

Nothing about the tools changed. The only difference between the npm package and this endpoint is how a client reaches them: spawn a process locally, or call a URL. An agent that needs lookup_mac mid-conversation doesn’t care which one it’s calling; it cares that the tool call returns fast and returns the right vendor.

In the official registry

The MCP registry lists ssid’s server under ai.ssid/ssid-mcp, and the Streamable HTTP endpoint is now a remote on that same entry, next to the stdio/npm listing. A client that discovers servers by querying the registry rather than a hand-maintained config file sees both transports without any extra setup on ssid’s side. That’s the main reason this is worth having beyond convenience: registry-driven discovery assumes a server is reachable over HTTP, and until now ssid’s wasn’t.

When to use which transport

Pick stdio (npx -y ssid-mcp) when:

• You’re running a local client (Claude Desktop, a terminal agent, an IDE extension) and it’s fine to spawn a Node process.
• You want the tools available even if the network is flaky, since the process runs on your machine.

Pick Streamable HTTP (https://ssid.ai/mcp/http) when:

• Your client can’t spawn a subprocess — a hosted agent, a browser-based tool, anything running somewhere you don’t control the shell.
• You’re wiring the server in through registry discovery instead of a static config file.
• You’d rather not have Node or npm as a runtime dependency at all.

Both hit the same backend and return the same data. There’s no feature gap between them, only a difference in how the connection gets made.

Trying it

If you already have ssid-mcp working over stdio, switching a client to the HTTP endpoint is a config change, not a rewrite — same tool names, same inputs, same outputs. If you’re starting fresh and your client supports Streamable HTTP, you can skip the npm step entirely and go straight to the URL.

For what lookup_mac returns or how get_router_defaults cites its sources, the MCP server page has the full tool docs and example requests. For programmatic access outside the MCP protocol, the API docs cover the plain REST endpoints behind the same data. And if you’re comparing ssid’s MCP setup against another vendor’s, our look at macadress.com’s pricing and MCP server covers a Streamable HTTP server that, unlike this one, requires a bearer key on every call.