Find MCP Server JA (Discovery and Installation of MCP Servers)

This skill provides end-to-end support for finding public MCP servers that meet your needs, comparing candidates, installing them, and performing basic post-installation tests.

When to Use

When asked "Is there an MCP server that integrates with X?" or "Find MCP tools for X"
When you want to add new external integrations to an agent
When you want to operate existing services or systems from an AI agent

Main Commands

Place

script/

in the same directory as

SKILL.md

, and first use the bundled CLI to search for candidates. When executing, either move to the skill directory or resolve

script/mcp-server-search.js

using its relative path from

SKILL.md

. Do not assume the current working directory.

```
node script/mcp-server-search.js [search term] --limit 30
```
: Searches the Official MCP Registry, Smithery REST API, and GitHub REST API in parallel and returns unified JSON
```
npx add-mcp [npm package name]
```
: Adds an npm package-type MCP server
```
npx add-mcp "[execution command argument1 ...]"
```
: Adds a stdio-type MCP server. The quoted execution command must contain one or more half-width spaces
```
npx add-mcp [HTTP URL]
```
: Adds directly from a URL

Do not use

npx add-mcp find

; it will add the found candidates directly to the workspace.

Workflow

1. Requirement Confirmation

Confirm the following two points:

Integration target. Examples: PostgreSQL, GitHub, Slack, Notion
Desired operations. Examples: Querying, PR creation, Issue creation, message sending

2. Candidate Search

First, use the bundled CLI.

bash

node script/mcp-server-search.js github --limit 30

From the same JSON output, directly check at least the following:

```
sources.registry.ok
```
```
sources.smithery.ok
```
```
sources.github.ok
```
```
merged[]
```
```
normalized[]
```

Search Rules:

You can only state that all 3 sources have been confirmed if
```
sources.registry.ok
```
,
```
sources.smithery.ok
```
, and
```
sources.github.ok
```
are all
```
true
```
in the JSON from that execution
The basis for 3-source confirmation should only be the JSON from one execution of the bundled CLI that you ultimately adopt. If you re-run the search to narrow down results, only the final execution result can be cited as confirmed
Do not combine README checks, separate API executions, or GitHub searches and treat them as "3-source confirmed"
If any source is
```
false
```
or unconfirmed, explicitly state this fact and treat subsequent steps as supplementary research
If the search term is too broad, you can refine it while maintaining 3-source confirmation. In this case, leave the final search term and reason in the explanation for the user
For broad technical terms like
```
postgres
```
,
```
git
```
, or
```
filesystem
```
, after the initial noisy execution, perform one precision pass using
```
[term] mcp
```
or
```
[term] mcp server
```
, and use that result as the basis for final 3-source confirmation
If an intermediate broad run fails, has too much noise, or cannot be used as a basis, separate that execution from the explanation and only use the successful final run as the basis
For searches of proper nouns, or searches where no matching candidates are found even after successful 3-source confirmation, you may add one supplementary check focusing on exact matches of product names or vendor names. This confirmation is not part of 3-source confirmation and should be explicitly stated as supplementary evidence
If the Registry and GitHub are empty or irrelevant, and remaining Smithery candidates cannot be linked to the target name or required functions after supplementary checks, do not force weak matches into candidates; judge as no-fit and proceed to alternative solutions
For targets that likely have official organizations, such as Slack, GitHub, Supabase, Vercel, if no official candidates are found even after successful 3-source confirmation, perform additional vendor checks using primary sources
If product names or vendor names are ambiguous, use official domain checks and GitHub exact-match searches before general web searches for supplementary confirmation. General web searches should only be treated as weak supplementary evidence
Only use actual acquired data for candidate names, tools, star counts, update dates, installation methods, etc.; mark unconfirmed items as unconfirmed
For hosted candidates without a public repo or clear repo provenance, treat them as hosted or conditional candidates only if you can confirm the operator and functions through primary sources like official docs
In environments where necessary searches or confirmations cannot be executed, do not provide temporary candidates or comparison tables; report unconfirmed items and stop

3. Candidate Prioritization

If there is an official candidate that meets requirements, prioritize it. If you do not adopt an official candidate, explicitly state what is lacking for the current requirements.

For official determination, confirm at least the following:

The owner of the GitHub repository matches the official organization or vendor of the target service
The
```
homepage
```
or
```
repositoryUrl
```
points to an official domain or official GitHub account
Primary information exists in the README, description, publisher information, official docs, official blog, etc.

Supplementary Rules:

Do not treat candidates as official based solely on metadata like Registry, Smithery, or Registry's
```
official
```
/
```
featured
```
tags
Hosted MCP endpoints guided by vendor official docs can be treated as official candidates, but should be described separately from OSS repositories
For general searches like
```
postgres
```
or
```
git
```
, treat service-specific candidates like Neon or Supabase as separate or conditional candidates

Prioritization order:

Functionality Fit > Security and Maintainability > Popularity

Popularity/adoption is compared using GitHub
```
stargazers_count
```
, GitHub
```
updated_at
```
, Smithery
```
useCount
```
, Smithery
```
verified
```
, and weekly npm download counts

4. Quality Confirmation

Before recommending, confirm if necessary Tools/Resources are available and if the maintenance status is acceptable.

If checking the README, prioritize

https://raw.githubusercontent.com/.../README.md

If possible, temporarily start the server to check Tools/Resources
If the goal is only comparison or read-only evaluation, do not force installation just for verification; explicitly state that the comparison is based on public information and no actual machine verification was performed

5. Candidate Presentation and Installation Confirmation

Before installation confirmation, show at least the following for each candidate:

MCP server name
Overview
3 to 5 representative Tools/Resources or function categories confirmed during verification
Installation method: npm package, execution command, or HTTP URL
Popularity or adoption metrics
Whether it is an official candidate; if unofficial, state the reason

Additional Rules:

If the same candidate appears in multiple sources, only integrate it if identity can be confirmed via repository URL, repo owner/name, install target, official endpoint, etc.
If installable candidates exist, proceed directly to necessary installation confirmation in the first candidate presentation, without inserting yes/no back-and-forth
Prioritize using the
```
vscode_askQuestions
```
tool if available; if not, confirm the same items via regular chat
If the user chooses not to install, end the process at that point

Items to Confirm:

If multiple candidates are available and unspecified: Which candidate to install, project-level or global, display name
If only one candidate exists or the target is confirmed: Project-level or global, display name

Authentication methods, transport, Docker compatibility, and additional environment variables can be postponed if not necessary for confirming the install command. Only ask about them simultaneously if they are essential for finalizing the install command.

6. Installation and Testing

Add the confirmed target according to its type:

npm package:
```
npx add-mcp [npm package name]
```

stdio command with arguments:

npx add-mcp "[execution command argument1 argument2 ...]"

HTTP URL:
```
npx add-mcp [HTTP URL]
```

If installation via

add-mcp

is not possible, check if manual editing of MCP JSON is feasible, obtain permission before editing, and if not, present alternatives such as custom MCP server development.

Reflect the scope and display name in the command. Examples:

bash

npx add-mcp -a vscode -n my-github github-mcp-server
npx add-mcp -a vscode -g -n my-github github-mcp-server

After installation, be sure to do the following:

Connect and start the MCP server
Guide the user on necessary environment variables or authentication information
Execute a safe read-only or ping-type tool. For remote MCP servers requiring authentication that return
```
401 Unauthorized
```
, treat this as successful reachability with incomplete authentication

Confirm installation using both

npx add-mcp list -a vscode

and

npx add-mcp list -a vscode -g

Report test results and usability

Search Tips

Category	Search Term Examples	Common Use Cases
Database	`postgres` , `sqlite` , `mysql`	Querying, aggregation, writing
Development Tools	`github` , `gitlab` , `git`	Code search, PRs, Issues
Communication	`slack` , `discord`	Messaging, channels
Files & OS	`filesystem` , `bash` , `cli`	Local files, command execution
Information Search	`brave` , `google` , `wikipedia`	Web search, latest information

When No Candidates Are Found

Inform the user that existing MCP servers cannot meet the requirements
Propose alternatives such as agent standard functions
Propose support for custom MCP server development in Python or TypeScript

find-mcp-server-ja

NPX Install

Tags

SKILL.md Content (Chinese)