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>
This commit is contained in:
parent
999cf9ecf4
commit
28220b0be6
1 changed files with 24 additions and 1 deletions
|
|
@ -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?
|
||||
|
|
|
|||
Loading…
Reference in a new issue