registry

Problem The parameter on only matches against (via ILIKE substring match). It does not search the 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 Returns only servers where contains "weather". A server named with description "Weather data and forecasts" is not returned. Expected behavior Search should match against both AND fields, with name matches ranked first for relevance. Proposed implementation 1. Add filter field to 2. Add ILIKE condition on the column in 3. Update the API handler to pass the search term to both filters 4. Name matches should appear before description matches (relevance ranking) Files affected — add to — add ILIKE condition for description in — pass search term to both name and description filters — add tests for description search — 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.

An optional, OAuth server configuration could help here as well specifically for those MCP authorizations servers that do not support Dynamic Client Registration. Described in the spec, Clients could hardcode the ClientId for the authorization server. The metadata in the registry can help guide consumers a ClientId is expected for the specific MCP server as well as where to acquire it, usually link to service provider developer portals. For reference see issue - https://github.com/microsoft/vscode/issues/247759 and also briefly touched on DCR topic and clientId acquisition in the blog The shape of this could be inspired from OAS and/or PRM Created for tracking from PR comment - https://github.com/modelcontextprotocol/registry/pull/3/files/e9ad7352dd35f905e6216b94cf760d6bd124d8a0#r2077901936

One potential benefit of a centralized registry is that we could have submitters list out all the possible tools their server may ever invoke, fingerprint them, and store those fingerpoints for MCP client consumption. A third party vendor could scan and approve these fingerprints as devoid of security risks, like tool poisoning attacks. MCP clients could then use the fingerprints to avoid tool poisoning attacks that get surfaced due to hidden dynamic tool calls or supply chain attacks.