Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-registry-finder search registry for a Slack MCP server"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Search the official MCP Registry from inside your agent session.
An MCP server that wraps the official Model Context Protocol Registry REST API as MCP tools — so a Claude Code / Claude Desktop / Cursor session can find, inspect, and get install commands for published MCP servers without you tabbing over to a browser.
github.com/bharat3645/mcp-registry-finder · MIT · built by Bharat
By mid-2026 the MCP server ecosystem is large and fragmented: the official registry alone lists thousands of published servers, and third-party directories (mcp.so, LobeHub, and others) each index tens of thousands more, with no single, consistent way to search. If you're inside an agent session and want to know "is there already an MCP server for X" or "what's the exact install command for that GitHub MCP server," today you leave the chat, open a browser, and search a directory by hand.
This is the missing meta-tool: an MCP server whose whole job is making the official registry queryable from inside the session that would actually use the result.
Related MCP server: mcp-server-mcpindex
Four tools, each doing one job:
Tool | What it does |
| Substring-search the registry by server name; returns matches with version, status, and description. |
| Full detail for one server by its reverse-DNS name — packages, required env vars, remote endpoints. |
| List servers, optionally filtered to those updated in the last N days. |
| Offline helper: turn a |
It talks to the official registry only (registry.modelcontextprotocol.io,
the registry stood up under the modelcontextprotocol/registry project) — not
the larger unofficial directories, which have no single stable API.
claude mcp add registry-finder -- npx -y mcp-registry-finderAdd to your MCP config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"registry-finder": {
"command": "npx",
"args": ["-y", "mcp-registry-finder"]
}
}
}git clone https://github.com/bharat3645/mcp-registry-finder && cd mcp-registry-finder
npm test # 40 tests, node:test, zero test-framework dependencies
npm start # runs the stdio server directlyThere is nothing to build — the package ships as plain ESM JavaScript and has
zero runtime dependencies: it uses Node's built-in global fetch (Node
≥18) and node:readline for the stdio transport.
Once installed, ask your agent things like:
"Is there an MCP server for Slack in the official registry?" "Give me the install command for the filesystem MCP server." "What's been published to the registry in the last 3 days?"
which route to search_registry, search_registry + get_server_details,
and list_recent_servers({ updatedWithinDays: 3 }) respectively.
stdin ──► readline (newline-delimited JSON-RPC) ──► server.js (protocol) ──► tools.js ──► registryClient.js ──► registry.modelcontextprotocol.io
stdout ◄── JSON-RPC responses ◄──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────src/server.js — transport-agnostic JSON-RPC message handling
(initialize, ping, tools/list, tools/call), so protocol logic is
unit-testable without spawning a process.
src/index.js — the stdio transport shim: one JSON-RPC message per line in,
one per line out, logs on stderr only, per the
stdio transport spec.
src/registryClient.js — thin fetch wrapper over the registry's /v0
endpoints, with an injectable fetchImpl for testing.
src/tools.js / src/format.js — tool schemas/handlers and pure formatting
helpers (install-command derivation, summaries).
Targets protocol versions 2025-06-18 and 2025-03-26 (negotiated at
initialize, defaulting to 2025-06-18). The registry's own transport
(Streamable HTTP for remote servers, stdio/HTTP for local packages) is
unrelated to this server's own transport, which is always stdio.
40 tests on node:test, zero test-framework dependencies (npm test).
registryClient and tools are unit-tested against real recorded
responses captured from the live registry API on 2026-07-10 (see
fixtures/) via an injected fetch, covering success, 404, non-JSON, and
network-failure paths.
format.js (install-command derivation, summaries) is pure and exhaustively
unit-tested — npm, pypi (uvx and pip variants), oci, nuget, cargo, mcpb, and
the unrecognized-type fallback.
test/protocol.test.js spawns the real server binary and drives it over
actual stdin/stdout pipes — a genuine end-to-end test of the JSON-RPC
framing, restricted to the tools that need no network (initialize, ping,
tools/list, format_install_command) so the suite never depends on
internet access being available wherever it runs.
node --check passes on every source and test file.
Read-only. The registry API also defines optional publish /
update / delete endpoints gated by bearer auth; this server doesn't
implement them — it's a finder, not a publisher.
No live-network integration test ships in this repo. The registry
client's HTTP-calling code is unit-tested against real, recorded API
responses (not live calls) so the suite is deterministic and runs offline;
the request/response shapes were hand-verified against the live registry
while building this. If the registry changes its response shape, the unit
tests won't catch that on their own — recapture the fixtures under
fixtures/ from a live GET /v0/servers call to re-verify.
Targets the stable spec, not the bleeding edge. The registry's own API
doc set references both a deployed /v0 path and a documented /v0.1
OpenAPI schema; this client targets the deployed /v0 path (verified live)
and exposes baseUrl as an override (MCP_REGISTRY_FINDER_BASE_URL) in
case that changes. Likewise, this server negotiates the current stable MCP
protocol versions (2025-06-18 / 2025-03-26), not the 2026-07-28
stateless-protocol release candidate, since that RC isn't final or widely
supported by hosts yet.
Substring search only. search_registry matches on server name, which
is what the registry's search query parameter does server-side — there's
no fuzzy or semantic matching layer on top.
MIT.
Offline helper: given a package registryType (npm, pypi, oci, nuget, cargo, mcpb) and identifier, return the runnable install/launch command. Does not contact the network.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Optional specific version. | |
| identifier | Yes | Package identifier, e.g. '@modelcontextprotocol/server-filesystem'. | |
| runtimeHint | No | Optional runtime hint (e.g. 'pip' to prefer pip over uvx for pypi). | |
| registryType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states no network contact and returns a runnable command. Side effects are absent. Could detail return format but overall sufficient.
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?
Single sentence with zero wasted words. 'Offline helper' front-loaded immediately communicates key constraint.
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 simple tool with 4 params and no output schema, description fully covers purpose and key constraint. No missing critical information.
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 coverage is high (75%) with descriptions for version, identifier, runtimeHint. Description lists registry types again, adding minimal new meaning. Baseline 3 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?
Description clearly states the tool formats an install command from registry type and identifier. It distinguishes from sibling tools (get_server_details, list_recent_servers, search_registry) which query or list servers, not format commands.
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?
Explicitly states it's an offline helper and does not contact the network, implying use when no network access is needed. Does not provide explicit when-not or alternatives, but sibling differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for one MCP server from the official registry by its reverse-DNS name (e.g. 'io.github.user/weather'), including install packages, required environment variables, and remote endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Reverse-DNS registry name, e.g. 'io.github.user/weather'. | |
| version | No | Specific version, or 'latest' (default). | latest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes what data is returned (install packages, env vars, endpoints) but does not state that the operation is read-only, mention error handling (e.g., if server not found), or specify any authentication or rate limits. The behavior is implied as a safe fetch, but lacks explicit transparency.
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, efficient sentence that front-loads the verb and resource, and includes all key details (name format, included items). No unnecessary words.
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 tool with 2 parameters and no output schema, the description sufficiently explains what the tool returns (install packages, env vars, endpoints). It is complete for its purpose, though it could mention error cases or return format.
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%, so the baseline is 3. The description adds an example for the name parameter and confirms the version default, but does not provide additional semantics beyond what the schema already documents.
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 verb 'Fetch full details' and the resource 'one MCP server from the official registry', listing included data (install packages, env vars, endpoints) and providing an example name format. This distinguishes it from sibling tools like list_recent_servers and search_registry.
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?
Usage guidance is implied but not explicit. The description indicates when to use this tool (by reverse-DNS name), but does not mention when not to use it or provide alternatives like using search_registry for discovery or list_recent_servers for a list. Sibling tools are present but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List MCP servers from the official registry, optionally filtered to those updated within the last N days. Useful for spotting newly published servers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (1-50). | |
| updatedWithinDays | No | Only include servers updated within this many days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic function and does not disclose behavioral traits like default behavior when no filter is given, data freshness, or limitations, leaving significant gaps.
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 two concise sentences, front-loaded with the main action, and free of redundant information, though it could be slightly more 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?
Given no output schema, the description lacks details about return format, pagination, or the default range of 'recent'. It is adequate for a simple list but not fully complete.
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%, so the schema already documents both parameters. The description adds marginal value by framing 'updatedWithinDays' as an optional filter, but doesn't provide meaning beyond what the schema offers.
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 tool lists MCP servers from the official registry with an optional recency filter, and distinguishes it from siblings like search_registry by focusing on 'recently updated' servers.
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 implies usage for spotting newly published servers and mentions optional filtering, but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the official Model Context Protocol registry (registry.modelcontextprotocol.io) for published MCP servers by substring match on name. Returns matching servers with version, status, and description.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (1-50). | |
| query | Yes | Substring to match against server names, e.g. 'filesystem' or 'github'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it searches and returns servers, implying a read-only operation, but does not explicitly confirm non-destructiveness or mention any side effects, authorization needs, or rate limits. Adequate for a simple search, but could be more explicit.
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 concise and well-structured: two sentences, front-loaded with the main action and target, followed by what is returned. No extraneous information.
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 tool's simplicity (2 parameters, 100% schema coverage, no output schema), the description is mostly complete. It specifies the input and output fields. However, it does not cover potential edge cases or result ordering, which could be helpful. Still, it adequately equips an agent for correct use.
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%, and the description does not add significant semantic value beyond the schema. It mentions 'substring match on name' which slightly reinforces the query parameter's role, but the schema already describes both parameters thoroughly. Baseline 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 tool's purpose: search the official MCP registry for servers by substring match on name. It specifies the action (search), the resource (registry), and the result fields (version, status, description). This distinguishes it from siblings like 'format_install_command' or 'list_recent_servers'.
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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives. It implies usage when looking for servers by name substring, but lacks 'when not to use' or references to sibling tools. The context is clear but exclusion guidance is missing.
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. Dates show when Glama detected each change.
v0.1.0format_install_commandget_server_detailslist_recent_serverssearch_registryScored across 4 tools
Each tool has a clearly distinct purpose: format_install_command converts registry types to install commands, get_server_details fetches details by name, list_recent_servers lists recent servers, and search_registry searches by substring. No overlap.
All tool names follow a consistent verb_noun pattern (format_install_command, get_server_details, list_recent_servers, search_registry). No mixing of conventions.
With 4 tools, the set is well-scoped for a registry finder server. Each tool serves a distinct need without unnecessary bloat or gaps.
The tool set covers the main workflows: searching, listing recent, getting details, and generating install commands. No obvious dead ends or missing operations for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and get install details on MCP servers, right from your agent -- a unified marketplace index.
Search the official MCP registry: 17,000+ servers with trust grades, stars, tools, install config.
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
Registry of MCP servers, agent skills and plugins: search, filter, comments, likes, publish.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bharat3645/mcp-registry-finder'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
