This pull request introduces significant updates to the authentication
system for the MCP Registry Publisher Tool. The changes focus on
transitioning to an interface-based authentication system, implementing
GitHub OAuth device flow as the default authentication method, and
restructuring the codebase for better modularity and extensibility.
Adding an interface to the publishing CLI, so that it'll be easier to
add more auth methods as they become available.
- Added error handling for JSON encoding in ServersHandler and ServersDetailHandler.
- Updated test cases to reflect changes in handler functions and improved mock expectations.
- Refactored server initialization to include ReadHeaderTimeout for better request handling.
- Modified GitHubDeviceAuth to accept context in ValidateToken and checkOrgMembership methods.
- Improved error messages in database import functions for better debugging.
- Updated memory and mongo database list functions to accept context and improved filtering logic.
- Enhanced logging in publisher tool for better visibility during execution.
- Cleaned up code formatting and comments for better readability and maintainability.
- Give the correct URL address in the mcp.json and the main README
## Motivation and Context
Improve documentation
## How Has This Been Tested?
No Testing.
## Breaking Changes
N/A
## Types of changes
- [ ] 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
- [ ] 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
<!-- Provide a brief summary of your changes -->
Inline ServerDetail fields in PublishRequest
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Fix#55
## 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: -->
- [x] 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)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
94c19fafa4/scripts/test_publish.sh (L61-L102)
---------
Co-authored-by: Avinash Sridhar <sridharavinash@users.noreply.github.com>
I originally introduced `package_canonical` into the API schema because,
at the time, we were thinking to "pin" the version of the MCP server to
_one_ of the referenced source code packages.
We are no longer doing this (we are maintaining a separate notion of
`version` unique to the MCP server), so I don't believe
`package_canonical` is needed anymore. Does anyone see otherwise?
This change removes all mentions in READMEs and usages in code.
* Update the model to handle new changes to schema based on https://github.com/modelcontextprotocol/registry/pull/33
* Made the import script a little simpler.
* Add a new updated seed file
* update template mcp.json file for publisher
Refs #28. After some thinking, this tries for a 'best of both worlds'
approach. Simple arguments can be present essentially as the original
spec recommended. As discussed, we don't specify the args for `npx` and
friends directly, so a simple package is merely...
```yaml
- name: my-api-mcp
# ...
packages:
- type: npm
name: "@c4312/my-api-mcp"
version: "0.0.1"
arguments:
# Named inputs in 'arguments' generate a `--name=<value>`
- type: named
name: "api-key"
is_required: true
is_secret: true
```
However, I think we need to be able to specify runtime args in some
cases, otherwise the registry eventually mirrors all docker configs and
options which is not a great situation to be in. So, I suggest a
`runtime_args` in the same format. Say I wanted that for npm, I could:
```yaml
- name: my-api-mcp
# ...
packages:
- type: npm
name: "@c4312/my-api-mcp"
version: "0.0.1"
runtime_arguments:
# Arguments with a pre-specified `value` don't get prompted for input
- type: positional
value: "--experimental-eventsource"
```
But Docker mounts are... complex, and ultimately we may deal with cases
that need multiple inputs in an argument like that. So for that I suggest
the third kind of "templated" input that does basic replacements and has
`properties` that follow the same general input schema:
```yaml
- name: server-filesystem
# ...
packages:
- type: docker
name: "mcp/filesystem"
version: "0.0.1"
runtime_arguments:
- type: template
description: Mount paths to access.
required: true
repated: true
template: "--mount=type=bind,src={host_path},dst={container_path}"
values:
host_path:
description: Path to access on the local machine
required: true
format: filepath
container_path:
description: Path to mount in the container. It should be rooted in `/project` directory.
required: true
format: string
default: "/project"
arguments:
- type: positional
value: "/project"
```
And then client config ends up being pretty simple, for the above case
for example a client could have this config:
```
{
"filesystem": {
"server": "@modelcontextprotocol/servers/src/filesystem@1.0.2",
"package": "docker",
"settings": {
"mount_config": [
{ "source_path": "/Users/username/Desktop", "target_path": "/project/desktop" },
{ "source_path": "/path/to/other/allowed/dir", "target_path": "//projects/other/allowed/dir,ro" },
]
}
}
}
```
Which might generate a CLI:
```
docker run \
--mount=type=bind,src=/Users/username/Desktop,dst=/project/desktop \
--mount=type=bind,src=/path/to/other/allowed/dir,dst=/project/other/allowed/dir,ro \
mcp/filesystem:1.0.2 \
/project
```
I think this does a good job of accomplishing the goals we care about:
- We get nicely defined inputs that are easy to extend, easy to process,
and easy for clients to configure.
- Versioning is enforced as we don't require the package to specify the
identifier to npx/uvx/etc.
- We _usually_ can break away from a dependency on a specific runtime.
This promise is broken a bit with `runtime_arguments`, most packages
should not need this and those that do are those inherently more
tightly coupled to a specific runtime like Docker (e.g. they would be
pretty uncommon for Node or Python.)
- We don't have a suple complex template system with loops and fallbacks
and conditionals, like we would if we tried to have a single template
string for a command.
