Clarify the docs around open/closed source and public/private MCP servers (#573)

<!-- Provide a brief summary of your changes -->

## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR adds more clarity to the docs around what's considered
open source, closed source, public and private in the context of MCP
servers.

## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->

## Breaking Changes
<!-- Will users need to update their code or configurations? -->

## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update

## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed

## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->

Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>

Author: rdimitrov

docs/guides/publishing/publish-server.md

@@ -19,6 +19,7 @@ By the end of this tutorial, you'll have:
 ## Prerequisites
 
 - An MCP server you've already built ([follow this guide if you don't have one already](https://modelcontextprotocol.io/quickstart/server))
+- Your server must be publicly accessible (closed source servers are welcome, but private/internal servers are not supported)
 
 ## Deployment Options
 

docs/reference/faq.md

@@ -47,7 +47,13 @@ See the [publisher README](../../cmd/publisher/README.md)
 
 ### Is open source required?
 
-No. While open source code is encouraged, it is not required for either locally or remotely run servers.
+No. The registry supports both open source and closed source servers, as long as they are publicly accessible.
+
+**Closed source servers are welcome** - you can publish proprietary MCP servers to the registry as long as:
+- The server itself is publicly accessible (not restricted to private networks)
+- The installation method is publicly available (e.g., npm package, Docker image on public registries)
+
+This applies to both locally-run and remote servers.
 
 ### What package registries are supported?
 
@@ -98,6 +104,22 @@ These are generally not supported on the official MCP registry, which is designe
 
 If you want to publish private servers we recommend you host your own MCP subregistry, and add them there.
 
+### What's the difference between closed source and private servers?
+
+**Closed source servers** have proprietary code but are **publicly accessible**:
+- ✅ **Supported**: Can be published to the registry
+- ✅ Source code can be proprietary/closed source
+- ✅ Installation via public package registries (npm, PyPI, Docker Hub, etc.)
+- ✅ Remote servers hosted on public URLs
+
+**Private servers** are **access-restricted** regardless of source code:
+- ❌ **Not supported**: Cannot be published to the official registry
+- ❌ Only accessible to specific users/organizations
+- ❌ Installation requires private credentials or network access
+- ❌ Remote servers on private networks or behind authentication
+
+**Example**: A commercial MCP server distributed as a paid npm package is closed source but publicly accessible, so it's welcome in the registry. A server only available on your company's internal network is private and not supported.
+
 ## Security & Trust
 
 ### How do I know a server is from the claimed organization?