Generates MCP client installation snippets and publication checklists for npm packages, helping users publish and install MCP servers distributed through npm.
Generates MCP client installation snippets and publication checklists for PyPI packages, helping users publish and install MCP servers distributed through PyPI.
Read-only MCP server for discovering, comparing, and auditing public servers from the official Model Context Protocol Registry.
Serveur MCP en lecture seule pour decouvrir, comparer et auditer les serveurs publics du registre officiel Model Context Protocol.
MCP Registry Navigator helps agents and developers answer practical questions before installing or publishing an MCP server:
Which MCP server fits a task best?
What package registry, transport, and install command does it use?
Is a server.json file ready for registry publication?
What checklist should be followed before publishing a PyPI, npm, or OCI MCP server?
The server does not edit user files. It returns structured reports, generated configuration snippets, and review checklists that callers can inspect and apply manually.
Related MCP server: MCP Registry Server
MCP Registry Navigator aide les agents et les developpeurs a prendre de bonnes decisions avant d'installer ou de publier un serveur MCP :
Quel serveur MCP convient le mieux a une tache donnee ?
Quel registre de package, transport et commande d'installation utilise-t-il ?
Un fichier server.json est-il pret pour une publication dans le registre ?
Quelle checklist suivre avant de publier un serveur MCP via PyPI, npm ou OCI ?
Le serveur ne modifie aucun fichier utilisateur. Il retourne des rapports structures, des snippets de configuration et des checklists que l'appelant peut relire puis appliquer manuellement.
Search latest servers from https://registry.modelcontextprotocol.io.
Fetch a specific server by registry name and version.
Compare server package types, transports, and descriptions.
Validate server.json metadata before publication.
Generate MCP client install snippets for PyPI, npm, and OCI packages.
Prepare publication checklists for PyPI, npm, and OCI registry flows.
Expose MCP tools, resources, and prompts through the official Python SDK v2.
Use a local TTL JSON cache and deterministic test fixtures.
search_servers
get_server
compare_servers
validate_server_json
generate_install_config
prepare_publish_checklist
registry://servers/{name}
registry://latest
registry://cache/status
choose_mcp_server
audit_mcp_metadata
prepare_mcp_release
Python 3.12 or newer.
uv for local Python dependency management.
Node.js 22.19.0 or newer only when using the MCP Inspector.
From a local checkout:
uv sync
uv run mcp-registry-navigator --versionDepuis un clone local :
uv sync
uv run mcp-registry-navigator --versionRun over stdio, the default transport for local MCP clients:
uv run mcp-registry-navigatorLancer le serveur en stdio, le transport par defaut pour les clients MCP locaux :
uv run mcp-registry-navigatorRun as Streamable HTTP for local testing:
uv run mcp-registry-navigator --transport streamable-http --host 127.0.0.1 --port 8000Lancer le serveur en Streamable HTTP pour les tests locaux :
uv run mcp-registry-navigator --transport streamable-http --host 127.0.0.1 --port 8000Run the MCP Inspector:
npm install
npm run inspectLancer le MCP Inspector :
npm install
npm run inspectThis repository includes .node-version and package.json so local inspection
uses @modelcontextprotocol/inspector v2 instead of the deprecated v1 launcher
used by some mcp dev environments.
Ce depot inclut .node-version et package.json afin que l'inspection locale
utilise @modelcontextprotocol/inspector v2 au lieu de l'ancien lanceur v1
utilise par certains environnements mcp dev.
For a local checkout:
{
"mcpServers": {
"mcp-registry-navigator": {
"command": "uv",
"args": [
"--directory",
"/path/to/mcp-registry-navigator",
"run",
"mcp-registry-navigator"
]
}
}
}After publishing to PyPI, the command can be simplified:
{
"mcpServers": {
"mcp-registry-navigator": {
"command": "uvx",
"args": ["mcp-registry-navigator"]
}
}
}uv run python -m pytest -q
uv run ruff check .
uv run mypy
uv build
npm run inspectThe test suite uses fake registry responses for deterministic offline coverage. The MCP integration tests use the SDK in-memory client and do not open ports.
La suite de tests utilise de fausses reponses du registre pour rester deterministe et fonctionner hors ligne. Les tests d'integration MCP utilisent le client en memoire du SDK et n'ouvrent pas de port reseau.
The default cache file is:
~/.cache/mcp-registry-navigator/registry-cache.jsonSet XDG_CACHE_HOME to change the cache root. Use NullCache in tests or
embedding code when no disk writes are desired.
Le fichier de cache par defaut est :
~/.cache/mcp-registry-navigator/registry-cache.jsonDefinissez XDG_CACHE_HOME pour changer la racine du cache. Utilisez
NullCache dans les tests ou dans du code embarque si aucune ecriture disque ne
doit etre effectuee.
This project is currently alpha software. APIs and generated recommendations may change while the MCP Registry and Python SDK continue to evolve.
Ce projet est actuellement en phase alpha. Les APIs et les recommandations generees peuvent changer pendant que le registre MCP et le SDK Python evoluent.
Before publishing to PyPI, add [project.urls] in pyproject.toml with the
real GitHub repository URL and issue tracker.
Avant une publication sur PyPI, ajoutez [project.urls] dans pyproject.toml
avec l'URL reelle du depot GitHub et le lien vers le suivi des issues.
If later publishing this server to the official MCP Registry as a PyPI package, add the registry verification marker to this README:
<!-- mcp-name: io.github.YOUR_GITHUB_USERNAME/mcp-registry-navigator -->Si ce serveur est ensuite publie dans le registre MCP officiel comme package PyPI, ajoutez le marqueur de verification ci-dessus dans ce README.
MIT. See LICENSE.
Compare package types, transports, and summaries for MCP servers.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and open-world behavior; the description does not contradict these. It adds the specific aspects compared (package types, transports, summaries), but offers no detail on output shape, behavior with unknown names, or duplicate inputs. With annotations lowering the bar, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
An eleven-word single sentence with zero waste. The verb and resource are front-loaded, and every word contributes meaning. Appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity (one parameter, no nested objects), an output schema exists so return values need no explanation, and annotations cover the safety/open-world profile. The description identifies the comparison dimensions and domain. The only minor gap is not explicitly framing it as a multi-server side-by-side comparison distinct from get_server, but nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema gives only 'names: array of strings, min 2, max 5'. The description adds crucial domain context that 'names' refers to MCP server names, which the bare schema omits. However, it does not specify whether names must be exact identifiers, case sensitivity, or ordering semantics — leaving moderate ambiguity for the sole parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Compare') with a defined resource ('MCP servers') and the precise comparison dimensions (package types, transports, summaries). This clearly distinguishes it from siblings — search_servers, get_server, validate_server_json, generate_install_config, prepare_publish_checklist — none of which perform a comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'compare' implies usage for comparing multiple servers side-by-side, and the minItems=2 constraint reinforces that. However, the description offers no explicit when-to-use/when-not-to-use guidance and names no alternatives, such as directing single-server lookups to get_server. Usage context is inferred, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an MCP client configuration snippet for one server.
| Name | Required | Description | Default |
|---|---|---|---|
| server_json | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, which the description does not contradict. The description adds minimal behavioral context beyond the annotation (e.g., that it produces a snippet for one server), but does not disclose limitations, side effects, or dependencies. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It delivers the core purpose immediately and is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (so return values are not needed in the description), the input parameter is completely underspecified. With no guidance on server_json structure and no usage context, the tool is not fully described for an agent to call it correctly. The description is too sparse for a tool with an unstructured object parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the server_json parameter. The schema only indicates an object with additionalProperties, so an agent has no idea what fields or structure to provide. The description does nothing to clarify parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('generate'), a specific output ('MCP client configuration snippet'), and a scope ('for one server'). It is distinct from sibling tools like search_servers or validate_server_json, which focus on retrieval or validation, not generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or when to prefer another tool such as prepare_publish_checklist. Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one MCP Registry server metadata record.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Registry server name, such as io.github.user/server. | |
| version | No | Exact version or latest. | latest |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is consistent with that. The phrase 'metadata record' adds a small nuance that it returns metadata, not the actual server, but it does not disclose any additional behavior such as error handling, version resolution, or pagination. Given annotations cover the safety profile, the description adds minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The purpose is front-loaded and every word contributes. It is appropriately minimal without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-with-optional-version tool, the description, combined with schema and output schema, is complete. The absence of explicit error-handling context is acceptable given this is a read-only operation with openWorldHint and the output schema defines the return structure. A minor gap is the lack of mention of 'version' behavior, but that is documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both 'name' and 'version' are documented in the input schema. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('one MCP Registry server metadata record'). It distinguishes from siblings like search_servers (which presumably returns multiple) and compare_servers (which compares), making the tool's specific role obvious even without examining the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that search_servers might be better for finding servers or that this tool is for retrieving a known server by name. The agent must infer usage context from the schema and sibling names, but the description itself offers no direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a publication readiness checklist for a server.json file.
| Name | Required | Description | Default |
|---|---|---|---|
| server_json | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the non-mutating nature. The description adds the fact that it returns a checklist, but no further behavioral details (e.g., what happens with invalid input). It is consistent with annotations and provides minimal added context, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that states the purpose without any fluff. Every word adds value, and the sentence is front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical usage context, such as when to call this tool versus validate_server_json or other siblings. It does not mention what constitutes 'publication readiness' or how the output might be used. Although an output schema exists, the description itself leaves the agent without enough context to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only parameter 'server_json' has no schema description or enum. The description merely says 'for a server.json file' but does not explain the expected format, structure, or any constraints. It does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and resource ('publication readiness checklist') for a specific target ('server.json file'). It is unambiguous, but it does not explicitly differentiate from siblings like validate_server_json or generate_install_config, so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its siblings. The description does not mention alternatives, exclusions, or prerequisites, leaving the agent to infer appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search latest public MCP Registry server metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Substring to search in server names. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not burdened with conveying safety or completeness. The phrase 'latest' adds a slight behavioral nuance (implying freshness), but it does not describe how the limit parameter interacts with results, whether results are ordered, or any pagination behavior. It neither contradicts nor meaningfully expands on the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no redundant words. It front-loads the core action and target. While it is short, it does not waste space; however, the brevity comes at the cost of necessary detail, making it less effective than a longer but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (which covers return fields), the description lacks essential context for correct invocation. It does not clarify how results are limited (despite the 'limit' parameter), how the query matching works, or when to prefer this tool over get_server. The description is minimal and does not help an agent make an informed decision among the listed siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for 'query' ('Substring to search in server names') but no description for 'limit'. Since schema description coverage is 50%, the tool description should compensate for the missing parameter semantics, but it does not mention either parameter at all. An agent would have to infer the meaning of 'limit' from its constraints alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a verb ('search') and a resource ('latest public MCP Registry server metadata'). It distinguishes the tool from siblings like get_server (which retrieves a single server) by focusing on searching, but does not explicitly clarify what 'metadata' includes or how search results are ordered. It is clear enough for a basic understanding, but leaves some ambiguity about the extent of the search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_server, compare_servers, or validate_server_json. It does not mention any exclusions or conditions that would help an agent decide between them. The absence of usage context is a significant gap given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate MCP Registry server.json metadata without publishing it.
| Name | Required | Description | Default |
|---|---|---|---|
| server_json | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint:true, so the description adds the specific 'validate' behavior but does not go beyond the annotation's safety profile. It reinforces that this is a read-only operation but adds no new behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler words. The verb 'Validate' is front-loaded, and the scope is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool and the presence of an output schema (which handles return details), the description covers the essential purpose and the non-publishing aspect. No additional information is strictly needed for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that the server_json parameter refers to 'server.json metadata', adding meaning beyond the generic 'Server Json' in the schema. However, it does not explain the object vs. string distinction or expected format beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Validate', the resource 'MCP Registry server.json metadata', and adds the scope 'without publishing it'. This distinguishes it from a publish action and clearly separates it from sibling tools like search_servers or prepare_publish_checklist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without publishing it' provides clear context that this tool is for pre-publish validation, implying when it should be used. However, it does not explicitly name alternatives or exclusions, though the context makes usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0compare_serversgenerate_install_configget_serverprepare_publish_checklistsearch_serversvalidate_server_jsonScored across 6 tools
Each tool performs a distinct operation: search, fetch, compare, validate, generate config, and checklist. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun snake_case pattern (search_servers, get_server, compare_servers, validate_server_json, generate_install_config, prepare_publish_checklist), making them predictable and easy to parse.
With 6 tools, the set is well-scoped for a registry navigator and pre-publish helper. Each tool covers a necessary step in browsing, validating, and preparing server configurations without excess.
The tool surface covers search, retrieval, comparison, validation, config generation, and publication readiness. A direct publish tool is missing, but that may be intentionally outside the 'navigator' scope, so the gap is minor.
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
The MCP server that finds MCP servers. Aggregates Official Registry, Glama, and Smithery.
Search the official MCP registry: 17,000+ servers with trust grades, stars, tools, install config.
Check if your MCP server is ready to publish on the MCP Registry, Smithery, or npm.
