MCP Galaxy / About

Who Runs This

Quick context on who runs this site, what it actually is, and how to satisfy yourself that the containers do what the pages say.

Maintainer & Reviewer

Behind MCP Galaxy

Hans Edward Rosarion — maintainer. Network Engineer (CCNP), 8+ years across multi-vendor environments. Currently focused on optimizing network infrastructure, hardening security, and maintaining complex production systems, with AI and automation pulled into the day-to-day. MCP Galaxy is where the automation side shows up publicly. Connect on LinkedIn.

Eli Cheatham — reviewer. Network engineer Juniper-certified (JNCIA-Junos, JNCIA-Security), 7+ years across multi-vendor environments. He brings that routing, virtualization and cloud lens as a second set of eyes on the servers and the site, helping keep what gets published accurate and trustworthy. Connect on LinkedIn.

Open to talking about new contributors to MCP Galaxy, feature ideas for the existing servers, requests for new ones, or stories about which one finally surfaced the problem that had been hiding in your environment.

The Mission

What This Actually Is

MCP Galaxy is about bringing AI-driven operations to the network stack. At its core is a directory of MCP servers built specifically for networking platforms — the connectors that let an AI client reach your live infrastructure. Servers are included here only after being tested against production-grade systems to ensure the reliability of the interface they expose. These servers are read-only by default. It is important to note that the effectiveness of an MCP server also depends on the AI model being used.

The goal is to alleviate the burden of repetitive network administration and cybersecurity tasks and open up new ways of working through agentic AI. We aim to support as many vendor platforms as possible to ensure that every user finds the MCP server they need. And because putting AI to work on production networks is still new territory, sharing the knowledge to do it well — what to install, how to wire it up, where the sharp edges are — is as much the mission as the servers themselves. That now includes complete agentic workflows: automations built and run against real gear, shared as sanitized exports you can import and point at your own environment.

We welcome all serious contributors who can help us add value to this collection.

If you have a request or any questions, please feel free to reach out; we would like to hear from you!

Trust

Why Trust the Containers

Nothing here ships as a pre-built image. Every install walks you through git clone and docker build (or podman build) against a public repo you can read end-to-end before you run anything. There is no opaque image to pull and no maintainer-controlled supply chain to trust on faith. You build the image yourself, from code that is in front of you.

Read-only servers by default, read/write on request. The guarantee is structural, not behavioural. It's CI-checkable and reviewer-checkable. Read-only is not the same as harmless: audit logs and running configs can still contain sensitive operational data, but it does mean an LLM cannot change live state through these servers. Make sure to limit user account or API access per your requirements.

Read/write servers, like the Palo Alto Firewall MCP server, are loud about it. It stages every write to the candidate config, requires an explicit commit_config tool call before anything reaches production, and ships with a PANOS_ENABLE_WRITE=no kill-switch documented on the page.