Mcp Marketplace

Install, configure, and manage MCP servers. Search 50+ verified servers plus npm and Smithery registries. Auto-generate configs for OpenClaw, Claude Desktop,...

Security Scan

The skill's code, instructions, and requested actions are consistent with a marketplace/installer for MCP servers, but it will read and modify local config files and run third‑party install commands — review package sources before proceeding.

Purpose & Capability

The name/description (MCP Marketplace: discover, install, manage MCP servers) match the included assets and scripts (search_registries, build_config, install_server, health_check, manage_servers, etc.). The catalog entries and templates align with the stated functionality.

Instruction Scope

Runtime instructions direct the agent to run the included Python scripts and to merge/write entries into client config files (e.g., .mcp.json, Claude Desktop config, Cursor config). They also instruct running install commands discovered via the catalog (npx/uvx/npm/pip/docker). Reading/writing those config paths and prompting users to set env vars is consistent with the purpose, but the skill will access user config files and may create state under the user's home directory (e.g., ~/.openclaw/mcp-marketplace).

Install Mechanism

There is no external install spec (instruction-only style) and the included scripts are local. The installer flows rely on package managers (npx, uvx, npm, pip, docker) to fetch MCP server packages — expected for this use case. No remote arbitrary binary download URLs were present in the reviewed files.

Credentials

The skill itself declares no required env vars or credentials and follows a pattern of using ${VAR} placeholders for server tokens. The catalog entries do list many service-specific env vars (GITHUB_TOKEN, SLACK_BOT_TOKEN, POSTGRES_CONNECTION_STRING, etc.), which is expected for integrating those services. The SKILL.md explicitly instructs not to paste tokens into chat and to set env vars locally — consistent and proportional.

Persistence & Privilege

The skill writes/reads local configuration and keeps installed-state under ~/.openclaw/mcp-marketplace and merges entries into client config files (project .mcp.json, Claude paths, Cursor config). It does not request always:true. Persisting state and editing client configs are within scope but are privileged actions — back up config files before proceeding.

Assessment

This skill appears to do what it says: discover, build config entries, and help install MCP servers. Important things to consider before installing or running it: - The skill will run local Python scripts that read and write config files (project .mcp.json, Claude/Cursor config locations) and store install state under your home directory; back up any existing configs first. - To actually install servers it will execute install commands (npx, uvx, pip, docker, etc.) which download and run third‑party packages. Only approve installs for packages you trust; unverified npm/Smithery packages carry the usual supply‑chain risks. - The skill does not collect tokens in chat and uses ${VAR} placeholders, but it will require you to set sensitive env vars (GITHUB_TOKEN, SLACK_BOT_TOKEN, DB connection strings, etc.) locally. Never paste secrets into chat; use environment variables or a secrets manager. - If you want extra assurance, inspect the unreviewed scripts referenced during install (notably install_server.py and secrets_helper.py) before running them, or run installs in an isolated environment/container. - If anything in the scripts looks unexpected to you (network endpoints, telemetry, or unexpected writes outside the described config locations), stop and ask for clarification.

MCP Server Marketplace

Help users discover, install, configure, and manage MCP servers. Supports OpenClaw, Claude Desktop, Claude Code, and Cursor.

Core Principles

1. ClawHub First — Always check for a ClawHub plugin bundle before raw server install. Bundles include skills and workflows on top of the MCP connection.
2. Never Store Secrets — Auth values are always env var references (${VAR_NAME}), never raw tokens. Never ask the user to paste their actual token in chat.
3. Verify Before Acting — Confirm server choice and auth readiness before installing.
4. Guide Completely — Don't just install. Walk through auth setup and verification.

Intent Routing

Classify the user's request into one of these intents, then follow the corresponding workflow.

DISCOVER — "What MCP servers are available for X?"

1. Run search:

   python3 {baseDir}/scripts/search_registries.py --query "<user's topic>" [--category "<category>"]
   

2. If clawHubMatch is present, mention the bundle first: "There's a [bundle name] plugin on ClawHub with [N] skills — want that instead?"
3. Present results as a numbered list with name, description, and auth requirements.
4. If any result has "source": "npm" or "source": "smithery", add a note: "This server is from [npm/Smithery] and hasn't been verified by our team. It should work but proceed with caution."
5. Offer to install any result.
6. If user asks "what else should I install?" or "recommend more servers":

   python3 {baseDir}/scripts/smart_recommend.py [--max-results 5]
   

   Present recommendations with their reasons (which installed servers they complement). Offer to install any.

INSTALL — "Install the X MCP server"

This is the most complex flow. Follow all steps in order.

Step 1 — Search:

python3 {baseDir}/scripts/search_registries.py --query "<server name>"

Step 2 — ClawHub bundle offer: If clawHubMatch is present, offer the bundle:

I found a [bundle displayName] plugin on ClawHub that includes the MCP connection plus [skillCount] additional skills. Would you like the full bundle, or just the raw MCP connection?

If user wants the bundle, guide them to install via ClawHub (clawhub install <bundleId>). Then record the install and stop.

Step 3 — Confirm server: If multiple results, present a numbered list and ask user to pick. If one result, confirm: "I'll set up [displayName] — sound good?"

Step 3.5 — Compatibility check (if non-default client): If the user specified a client or you detected a non-OpenClaw client, check compatibility:

python3 {baseDir}/scripts/check_compatibility.py --server-id "<id>" --client "<client>"

If compatible is false, warn the user and suggest alternatives. If there are warnings, mention them but proceed.

Step 4 — Build config:

python3 {baseDir}/scripts/build_config.py --server-id "<id>" [--client "<client>"]

The --client flag is optional. If omitted, the script auto-detects the client (OpenClaw, Claude Desktop, Claude Code, or Cursor). The output includes mergeTarget (the config file path) and client (the detected client name).

Step 5 — Auth guidance (if server has requiredEnv): Follow the Auth Guidance Pattern below. Wait for user to confirm they have their token ready before proceeding.

Step 6 — Check prerequisites and install:

python3 {baseDir}/scripts/install_server.py --server-id "<id>"

This script checks prerequisites and returns the install command — it does NOT run it.

• If prerequisitesMet is false, show the prerequisites.suggestion and help the user install the prerequisite first.
• If prerequisitesMet is true, run the installCommand.command directly using the Bash tool. For example, if the output says "command": "npx -y @github/mcp-server --help", run that command to verify the package resolves.
• If installCommand.command is null (HTTP servers), skip — no install needed.
• If the install command fails, try the installCommand.fallbackCommand if present, or consult {baseDir}/references/troubleshooting.md.

Step 7 — Write config: Present the configEntry from step 4 and explain it needs to be added to the config file at mergeTarget (the path returned by build_config.py). If the config file exists, merge the new server entry into the existing mcpServers object. If it doesn't exist, create it:

{
  "mcpServers": {
    <configEntry content here>
  }
}

Step 8 — Record state:

python3 {baseDir}/scripts/manage_servers.py --action record --server-id "<id>" --package "<package>" --transport "<transport>" --install-method "<method>" --source "<source>"

Use --source curated, --source npm, or --source smithery based on where the server was found.

Step 8.5 — Health check (optional):

python3 {baseDir}/scripts/health_check.py --server-id "<id>"

If status is "healthy", include the tool count in the summary. If "unhealthy" or "error", troubleshoot before declaring success — consult {baseDir}/references/troubleshooting.md.

Step 9 — Summary: Tell the user what was installed, what tools are now available (from health check if run), and remind them to restart their client to pick up the new server.

BULK INSTALL — "Install the dev toolkit" / "Set up servers for data work"

1. If user mentions a specific bundle, resolve it. If they describe a use case, match to the closest bundle:

   python3 {baseDir}/scripts/bulk_install.py --bundle "<bundle-name>"
   

   Available bundles: standard-dev, data-engineering, web-frontend, devops, productivity, ai-ml.

2. If unsure which bundle, list them all:

   python3 {baseDir}/scripts/bulk_install.py --bundle __list__
   

   Present the options and let the user choose.

3. Present the install plan: show which servers will be installed and which are already configured.

4. For each server in toInstall, follow the INSTALL workflow (Steps 3-9). Process them one at a time, confirming auth requirements for each.

5. After all servers are installed, present a summary: "Installed X servers, Y were already configured."

DETECT — "Scan for MCP servers" / "What MCP servers do I already have installed?"

1. Run detection:

   python3 {baseDir}/scripts/detect_servers.py --verbose
   

2. If unconfigured has entries: "I found [count] MCP server packages on your system that aren't configured yet: [list them]. Want me to set up any of them?"
3. If alreadyConfigured has entries: mention them as already active.
4. If nothing detected: "No known MCP server packages found. Want me to search for servers to install?"
5. For each server the user wants to configure, follow the INSTALL workflow starting at Step 4 (Build config) — the package is already installed.

RECOMMEND — "Set up MCP for this project" / "What servers should I use?"

1. Scan the project:

   python3 {baseDir}/scripts/recommend_servers.py [--project-dir "<path>"]
   

   If the user specifies a project type: python3 {baseDir}/scripts/recommend_servers.py --template "<type>" Available templates: python-web, node-fullstack, data-science, mobile, devops, static-site.

2. If detected is true:

   • Present the detected template: "This looks like a [displayName] project (matched [files/patterns])."
   • List recommended servers first, then optional servers.
   • Mark any that are already configured.
   • Offer to install the recommended set (routes to BULK INSTALL logic).

3. If detected is false:

   • List available templates and ask the user to pick one.
   • Or suggest running DISCOVER for a broader search.

CONFIGURE — "Set the API key for X" / "Connect X to my database"

1. Identify the server from the user's request.
2. Run build_config.py --server-id "<id>" with any custom env/args the user provides:

   python3 {baseDir}/scripts/build_config.py --server-id "<id>" --custom-env '{"KEY": "${KEY}"}'
   

3. Follow the Auth Guidance Pattern for any new env vars.
4. Update the .mcp.json config entry.

STATUS — "Show my installed MCP servers"

1. Run:

   python3 {baseDir}/scripts/manage_servers.py --action list
   

2. Present as a formatted table: server name, package, transport, install method, installed date, config present.
3. If any server has "configPresent": false, warn: "This server is recorded but its config entry was not found. It may need to be re-configured."
4. If the user asks about a specific server:

   python3 {baseDir}/scripts/manage_servers.py --action status --server-id "<id>"
   

5. If no servers installed, suggest running a discovery search.

REMOVE — "Remove the X server"

1. Confirm: "Remove [displayName]? This will remove the state record. You should also remove its entry from .mcp.json."
2. Run:

   python3 {baseDir}/scripts/manage_servers.py --action remove --server-id "<id>"
   

3. Remind user to remove the corresponding entry from .mcp.json and restart OpenClaw.

UPDATE — "Update my MCP servers"

1. Run version check:

   python3 {baseDir}/scripts/version_check.py
   

   For a specific server: python3 {baseDir}/scripts/version_check.py --server-id "<id>"

2. Present results:

   • Servers with updateAvailable: true: show current vs latest version and the updateCommand.
   • Servers with note (npx/uvx/http): explain they auto-resolve or are managed remotely.
   • Docker servers: suggest docker pull to refresh the image.

3. If the user wants to update, run the updateCommand for each server via the Bash tool.

4. After updating, optionally run a health check to verify the updated server works.

HEALTH CHECK — "Is my X server working?" / "Test the GitHub MCP"

1. Identify the server from the user's request.
2. Run:

   python3 {baseDir}/scripts/health_check.py --server-id "<id>"
   

3. If status is "healthy":
   • Present the tool count and list a few tool names.
   • "Your [displayName] server is healthy with [toolCount] tools available."
4. If status is "unhealthy" or "error":
   • Show the error message.
   • Consult {baseDir}/references/troubleshooting.md for the specific error.
   • Update server status: python3 {baseDir}/scripts/manage_servers.py --action update-status --server-id "<id>" --status error
   • Guide the user through the fix, then re-run the health check to confirm.

TROUBLESHOOT — "X server isn't working" / "Why can't I use the GitHub tools?"

1. Identify the server.
2. Run health check:

   python3 {baseDir}/scripts/health_check.py --server-id "<id>"
   

3. Based on the error, consult {baseDir}/references/troubleshooting.md.
4. Guide the user through the fix step by step.
5. Re-run health check to confirm resolution.
6. If resolved, update status: python3 {baseDir}/scripts/manage_servers.py --action update-status --server-id "<id>" --status active

CONTRIBUTE — "Add my server to the marketplace" / "Contribute a server config"

1. Gather server details from the user:

   • ID: lowercase, hyphenated (e.g., my-server)
   • Display Name: human-readable name
   • Description: what the server does
   • Package: npm/pip package name or Docker image
   • Transport: stdio or http
   • Install Method: npx, npm, uvx, pip, http, or docker
   • Categories: from the Categories list below
   • Required Env Vars: any tokens/keys needed
   • Tags: search keywords

2. Generate and validate the entry:

   python3 {baseDir}/scripts/contribute_server.py --id "<id>" --display-name "<name>" --description "<desc>" --package "<pkg>" --transport "<transport>" --install-method "<method>" --categories "<cat1,cat2>" --tags "<tag1,tag2>" --required-env "<VAR1,VAR2>"
   

3. If valid is true: present the serverEntry JSON and the prBody template. Guide the user to submit a PR to the marketplace repository.

4. If valid is false: show the validationErrors and help the user fix them, then re-run.

Auth Guidance Pattern

When a server requires environment variables:

1. List each required variable with its purpose (from authGuidance.instructions).
2. Provide the generation URL if available: "You can create one at [URL]".
3. Show the export command: export VAR_NAME=<your-value-here>
4. Remind about persistence: "Add this to ~/.zshrc (or ~/.bashrc) so it persists across sessions."
5. NEVER ask the user to paste their actual token in the chat. Guide them to set it in their shell.
6. NEVER store raw token values in config — only ${VAR_NAME} references.
7. Offer secrets manager (if available): Before telling the user to add export to .zshrc, check for a secrets manager:

   python3 {baseDir}/scripts/secrets_helper.py --action detect
   

   If managers are found, offer the option: "I detected [manager name] on your system. Want to store this token there instead of in your shell profile? It's more secure." If yes, generate the store command:

   python3 {baseDir}/scripts/secrets_helper.py --action store-command --manager "<manager>" --service "<server-name>" --env-var "<VAR_NAME>"
   

   Present the storeCommand for the user to run, then show the shellIntegration line to add to ~/.zshrc.

OAuth Servers

When authGuidance.authType is "oauth":

1. Present the setup steps from authGuidance.oauthSetupSteps as a numbered list.
2. Mention the provider: "This server uses [provider] OAuth for authentication."
3. Link to reference doc: "For detailed OAuth setup instructions, see the OAuth patterns guide."
4. Guide through env vars: After OAuth setup, the user still needs to set the required env vars (e.g., GOOGLE_APPLICATION_CREDENTIALS).
5. Do NOT ask the user to paste credentials in the chat — guide them to set env vars in their shell.

Error Recovery

• Install fails with missing prerequisites: Read {baseDir}/references/troubleshooting.md for the specific error and guide the user.
• Server not found in catalog: The search falls back to npm and Smithery registries automatically. If still not found, suggest checking https://github.com/modelcontextprotocol/servers for the official list or https://smithery.ai for community servers.
• Config generation fails: Show a manual config example from {baseDir}/references/transport-patterns.md and walk through it.
• Server starts but tools don't appear: Run python3 {baseDir}/scripts/health_check.py --server-id "<id>" to diagnose. Consult {baseDir}/references/troubleshooting.md.
• Health check times out: The server may need env vars, a database connection, or more time. Try increasing the timeout with --timeout 30.
• Config not found for a client: Check the mergeTarget path from build_config.py. See {baseDir}/references/troubleshooting.md for client-specific config paths.

Categories

Available category filters for discovery: developer-tools, database, communication, productivity, cloud-infra, ai-ml, data, cms-content, finance, observability, search, auth, storage, version-control, browser.