How MCP fits together

New to MCP? Read this first.

What it is: MCP (Model Context Protocol) is a standard way for an AI to call TOOLS that live in a separate program. 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 Anthropic with YOUR API key (set it once, from the Vault).

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.

SubnetSlinger plays BOTH roles: its Deputy is a HOST that drives Cisco / pyATS / NetBox, and it also SHIPS a server so Claude Desktop / Cursor can call SubnetSlinger's own tools. See 'MCP servers you can connect (catalog)' for the picker list.