How MCP fits together

What it does: MCP lets the Deputy call tools in another program. MCP (Model Context Protocol) is a standard way for an AI to call TOOLS that live in a separate program. New to MCP? Start with this article. Instead of teaching the model every vendor API, you point it at a 'server' that already speaks that API, and the model calls the server's tools by name — the same shape SubnetSlinger uses for its own built-in tools.

The three roles:

• SERVER — a small program that EXPOSES tools (e.g. a Cisco MCP server exposes get_config, run_show_command).
• CLIENT — the piece that OPENS a connection to one server and forwards tool calls to it.
• HOST — the app the human uses; it runs the model and one client per server. The Deputy is a host.

Transport (how host and server talk):

• stdio — the host launches the server as a child process and exchanges JSON-RPC over stdin/stdout. This is what the Deputy uses: you give it a command + args, it spawns them. Everything stays on your machine.
• streamable-HTTP — the server runs as a network service and the host connects over HTTP. Used for shared/remote servers.

Two separate logins to keep straight:

1. Host → model: the Deputy authenticates to the AI provider you picked (Anthropic, an OpenAI-compatible endpoint, or Google Gemini) with YOUR API key (set it once, from the Vault) — or needs no key at all on local Ollama.

2. Server → device/API: the server authenticates to the switch / controller / SaaS with ITS OWN token (Bearer, X-API-Key, OAuth, or SSH creds) — usually via an env var or a config/testbed file the server reads.

Read-only guard: the Deputy blocks state-changing MCP tools in code. Each connected server has a 'writes' checkbox, OFF by default — flip it only when you deliberately want that server to make changes. The Posse forces every MCP tool read-only regardless.

Connecting: on connect the Deputy shows a plain-words summary of what the server exposes ('Exposes N tools the Deputy can call: …'). Many stdio servers need a runtime installed (Python, Node, uv, Docker) — if it isn't on your PATH the Deputy names it for those (Python, Node.js/npx, uv/uvx, Docker) and asks you to reconnect; for anything else it says the command isn't on your PATH.

SubnetSlinger can work in BOTH directions — the trick is to keep them separate:

Deputy as HOST (client): the Deputy reaches OUT to drive your own tool servers (Cisco / pyATS / NetBox). This works identically on Windows and Linux; it's the MCP servers screen on the rail (right after Deputy) — the same panel also appears inside the Deputy's setup, and both show the same live connections.

SubnetSlinger as SERVER: a separate, read-only small program lets ANOTHER AI app (Claude Desktop, Cursor, or a larger automation / runbook agent) reach IN and call SubnetSlinger's own tools; every call is logged to mcp.log. On Windows, point your MCP client at subnetslinger-mcp.exe (installed with the app); on Linux, at the subnetslinger-mcp file in the folder you unpacked. On Windows and Linux 1.3 the server has no on/off switch and no Pro check. On macOS, point it at /Applications/SubnetSlinger.app/Contents/MacOS/SubnetSlingerMac with the argument --mcp; it's off by default and needs Pro (turn it on at the bottom of the MCP servers screen). You'd use this when your team already works inside one AI assistant or automation and wants network diagnostics to be one more tool it can call, instead of running SubnetSlinger's own Deputy.

See 'MCP servers you can connect (catalog)' for the Deputy's picker list.