- 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.
- Added authentication service and GitHub OAuth integration.
- Introduced new authentication methods and structures in the model.
- Updated the API to handle authentication during the publishing process.
- Created handlers for starting and checking the status of the OAuth flow.
- Enhanced the publish handler to validate authentication credentials.
- Updated configuration to include GitHub OAuth settings.
- Added tests for the OAuth flow and publishing with authentication.
- Updated documentation to reflect changes in the API and authentication process.
