## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR:
* Adds a Makefile with the most common project-related commands
* Updates the CI workflow to leverage that (people testing locally will
use the same commands as the CI)
* Switches to using the official Golangci-lint action instead of
downloading it via curl
* Bumps the golangci version (supersedes #144)
* Fixes any formatting/linting issues found
* Updates the README to reference the new make targets
* Runs the schema validation scripts as part of the CI
**Next:**
* If you are okay I can file a follow up PR afterwards where I can tidy
up the CI workflows a bit, it feels there's some overlap.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
Locally by running the make targets
## 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)
- [x] 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
- [ ] 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>
Co-authored-by: Adam Jones <adamj+git@anthropic.com>
Migrate golangci-lint from v1 to v2.
## Motivation and Context
The golangci-lint has been upgraded to v2 since March 2025.
The v2 of golangci-lint has simplified the linters management.
## How Has This Been Tested?
Tested locally with golangci-lint@v2.1.6
## Breaking Changes
No.
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] 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
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
---------
Co-authored-by: haokunt <haokunt@opera.com>
Co-authored-by: Avinash Sridhar <sridharavinash@users.noreply.github.com>
Co-authored-by: Adam Jones <adamj+git@anthropic.com>
Auto build image when we run `docker compose up`, Make it start more
easy for beginner.
## Motivation and Context
When I try to use `docker compose up` start the MCP server, docker
default pull `registry` image from dockerhub, because I forget build
image first.
Maybe we don't need to manually build the image, just build it
automatically when docker compose starts
## How Has This Been Tested?
Just run `docker-compose up --build` at a environment has installed
docker and docker compose.
Signed-off-by: 疯魔慕薇 <kfanjian@gmail.com>
Co-authored-by: adam jones <domdomegg+git@gmail.com>
## Summary
This PR improves the developer experience by adding clear linting
documentation and optional pre-commit hooks to catch issues before CI.
Helpful to avoid fighting Claude Code / Copilot on "please make sure
linting passes CI".
## Changes
- Updated `README.md` with:
- Go 1.23.x requirement (was "1.18 or later")
- golangci-lint v1.61.0 in prerequisites
- New Development section with linting instructions
- Updated `CLAUDE.md` with:
- Development Setup section
- Added `.githooks/pre-commit`:
- Runs golangci-lint and gofmt checks
- References README for installation instructions
- Can be bypassed with `--no-verify` when needed
## Test Plan
- [x] Verified pre-commit hook blocks commits when golangci-lint is
missing
- [x] Confirmed hook shows clear error message pointing to README
- [x] Tested that linting passes with Go 1.23.0 and golangci-lint
v1.61.0
- [x] Verified gofmt correctly identifies formatting issues
Co-authored w/ Claude Code
---------
Co-authored-by: Charles Lowell <10964656+chlowell@users.noreply.github.com>
<!-- Provide a brief summary of your changes -->
Add support for specifying database type (MongoDB or in-memory
database).
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The README states that MCP Registry supports both MongoDB and in-memory
databases, but does not provide the capability to specify which database
type to use.
5d9171bdcc/README.md (L19)
This PR addresses this limitation by adding explicit database type
configuration through the `DATABASE_TYPE` environment variable, allowing
users to choose between `mongodb` and `memory` database types in a
standardized way.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
Yes
```console
$ export MCP_REGISTRY_DATABASE_TYPE="memory"
$ ./scripts/test_endpoints.sh
Testing health endpoint: http://localhost:8080/v0/health
Status Code: 200
Response:
{
"status": "ok",
"github_client_id": ""
}
Health check successful
-------------------------------------
Testing servers endpoint: http://localhost:8080/v0/servers
Status Code: 200
Response Summary:
Total registries: 0
servers Names:
Pagination Metadata:
{}
servers Details:
{
"servers": [],
"metadata": {}
}
servers request successful
-------------------------------------
Testing ping endpoint: http://localhost:8080/v0/ping
Status Code: 200
Response:
{
"status": "ok",
"version": "dev"
}
Ping successful
-------------------------------------
All tests passed successfully!
```
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
No
## 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)
- [x] 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. -->
- [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
-->
Close#63
---------
Co-authored-by: Avinash Sridhar <sridharavinash@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
- 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
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.
Work in progress .
This commit adds the core registry service implementation with methods to:
- Retrieve all registry entries
- List entries with cursor-based pagination
- Fetch specific server details by ID
