MCP Galaxy / About

Who Runs This

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

Maintainer

Behind MCP Galaxy

Hans Edward Rosarion. 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.

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. Connect on LinkedIn.

The Directory

What This Actually Is

This is a collection of MCP servers specifically for the network stack. 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 allow new workflows through AI and automation for engineers. We aim to support as many vendor platforms as possible to ensure that every user finds the MCP server they need. Since MCP is a relatively new technology, one of our goals is also to share relevant knowledge on the subject, enabling everyone to explore and take full advantage of AI capabilities.

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.