modelcontextprotocol / modelcontextprotocol/registry
feat: search should also match against server description field
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 7.3k
- Forks
- 994
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 19
Description
Problem
The ?search= parameter on /v0/servers only matches against server_name (via ILIKE substring match). It does not search the description field.
This was explicitly requested in #135 (now closed) but only the name-search portion was implemented.
Impact
AI agents and users searching for servers by what they do (e.g., "weather", "database", "GitHub integration") cannot find relevant servers unless they already know the exact server name. The description field — which contains the most useful discovery information — is completely ignored by search.
Current behavior
GET /v0/servers?search=weather
Returns only servers where server_name contains "weather". A server named io.github.example/data-tools with description "Weather data and forecasts" is not returned.
Expected behavior
Search should match against both server_name AND description fields, with name matches ranked first for relevance.
Proposed implementation
- Add
SubstringDescriptionfilter field toServerFilter - Add ILIKE condition on the
descriptioncolumn inbuildFilterConditions - Update the API handler to pass the search term to both filters
- Name matches should appear before description matches (relevance ranking)
Files affected
internal/database/database.go— addSubstringDescriptiontoServerFilterinternal/database/postgres.go— add ILIKE condition for description inbuildFilterConditionsinternal/api/handlers/v0/servers.go— pass search term to both name and description filtersinternal/api/handlers/v0/servers_test.go— add tests for description searchinternal/database/postgres_test.go— add tests for description filter
Context
This is particularly important for AI-agent workflows where the agent searches by capability keywords rather than knowing server names in advance.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with ServerFilter in internal/database/database.go and buildFilterConditions in internal/database/postgres.go, then trace how internal/api/handlers/v0/servers.go passes the search term. Add coverage in internal/api/handlers/v0/servers_test.go and internal/database/postgres_test.go. Done means /v0/servers search matches both name and description, with name matches ranked first.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, postgresql
- Domain
- backend-api-design, databases, search, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100