RTRGRD's desktop terminal can act as a local MCP server. Pair an AI agent you already use, Claude Code, Codex, Cursor, Claude Desktop, any MCP client, and it reads the SSH sessions you choose to share: in your terminal, through your credentials, on your machine. The agent never holds a device password or key.
Nothing is visible to the agent until you share a session, and you can revoke with one click.
Copy a one-time pairing secret from RTRGRD into your MCP client. The server listens only on your own computer, on 127.0.0.1.
The client then appears in RTRGRD's MCP panel, holding nothing, until you approve it.
Pick what it can see: one tab, a group, or all open sessions. Change your mind and revoke with one click.
Ask your question in the client you already work in. Every call is logged in RTRGRD with the decision and the reason.
Most agent toolkits give the model an SSH library and a credentials file and hope for the best. RTRGRD gives the agent your already-open sessions behind a read gate, a sanitizer, consent per share, and a log, and keeps the credentials with you.
The agent reads LLDP, interface state, neighbor tables and logs across all three, then tells you which layer failed and what to change. From live state, not from a screenshot somebody pasted into a chat.
Your client searches the vendor documentation on the web while reading your live device, so the answer is written against your actual output instead of a generic example.
Share a site or a tier and ask across it: compare NTP and logging settings across the campus core, or find which devices still run the old image. One read, run on every device you shared, returned as a diff.
Capture state before the window and again after, and let the agent tell you what moved. Nobody has to paste terminal output into a chat box to get a second opinion.
Bring the document you wrote and let the agent compare it to live VLANs, uplinks and routing adjacencies, then flag the gaps. The drift you find this way is the drift you were going to find at 2 a.m. otherwise.
A new engineer gets the explanation from live state plus RTRGRD's vendor knowledge, and every claim traces back to a read they can go and look at themselves.
Your automation gets a deterministic, logged, read-oriented way to see the network, instead of a raw SSH library and a credentials file sitting next to it on disk.
The reverse direction works too. RTRGRD's own AI can call external MCP servers you approve and attach their results as evidence to a question, quoted and treated as untrusted input.
The server is designed to be read-only. The tool surface below is the whole surface. Anything outside it is refused by design, and the refusal is logged with its reason.
| include,
| count
Device output passes RTRGRD's sanitizer before it reaches the agent. It removes credential shapes it recognizes: password hashes, keys, SNMP communities, certificates.
Operational data still flows. Hostnames, interfaces and addresses reach the agent, because that is what it needs in order to reason about your network. Treat the sanitizer as one layer of the design, not as a claim about every string a device can print.
Every call is logged in RTRGRD with the decision and the reason, so a refusal is as visible as a read. A risk acknowledgement is shown the first time you turn the server on.
The documentation recommends connecting shared sessions with a read-only device account as a second safeguard. Your device's own authorization model is the layer that does not depend on ours.
RTRGRD MCP ships as a labelled beta in the Apex tiers. Features may be limited, changed, or disabled remotely while it is in beta.
MCP server and MCP connectors, with the read gate, the sanitizer, consent per share, and the call log.
Everything in Apex, alongside fleet-scale Python automation with dry-run and per-device rollback.
Where this goes. The MCP server is read-only by design, and agent-driven changes are not part of the product. If that ever changes, it will come with device checkpoints, per-change approval and its own announcement.
You are responsible for authorization on the devices you connect, and for the agent you pair with RTRGRD. A paired client operates with whatever access you have granted it. We recommend connecting shared sessions with a read-only device account as a second safeguard.
The MCP server and MCP connectors are off by default, are available only to qualifying subscription tiers, and are disabled while Privacy Mode is on. RTRGRD does not control any client program you pair, any external MCP server you connect, or any AI provider used by either.
The full terms are in Privacy Policy section 4.4 and Terms of Service section 12.5. Read them before you turn this on.
RTRGRD MCP is in beta in the Apex tiers. Join the waitlist and we will tell you when your seat is ready.
Join the WaitlistAI output is guidance, not authority. Review it before you act on it (Terms section 7).