list-servers

Purpose

Enumerate all connected/configured MCP servers, extract their canonical names, and normalize their configurations into a structured inventory including authentication requirements and where auth material is sourced.

This skill is strictly for discovery and structured listing.
It does not perform vulnerability research, CVE triage, or security posture rating. Use analyze-server skill for doing inspection.

Outcomes

You will produce:

1. A complete list of all MCP servers configured in the workspace/client.
2. Their canonical names and aliases (if present).
3. A normalized configuration snapshot for each server (secrets redacted).
4. Authentication requirements for each server (type, source, and risk of exposure).
5. A clean inventory table suitable for downstream automation.

---

Step 1 — Locate MCP Configuration Sources

Search for MCP definitions in:

Common Files

• mcp.json
• ~/.claude.json
• mcp.yaml
• mcp.toml
• .mcp/
• claude_desktop_config.json
• ~/.config/*mcp*
• package.json (scripts containing mcp)
• docker-compose.yml
• Dockerfile
• README references to MCP servers

Search Heuristics

Search for keys and patterns:

• mcpServers
• servers
• command
• args
• env
• stdio
• transport
• url
• headers
• authorization
• token
• apiKey
• client_secret

If multiple config sources exist:

• Merge results
• Deduplicate by canonical name (keep a list of source locations)
• Preserve source locations for traceability

---

Step 2 — Normalize Each Server Entry

For every discovered MCP server, extract and normalize:

Required Fields

• Name (canonical key)
• Display Name (if available)
• Source file location OR Remote Server URL
• Launch type
  • command (stdio)
  • docker
  • remote_http / remote_sse (if applicable)
• Command (or image/URL)
• Args (ordered)
• Environment variable keys (values must be redacted)
• Working directory (if specified)
• Transport (if known)

Optional but High-Value Fields

• Version/provenance:
  • npm package + version (if derivable)
  • pip package + version (if derivable)
  • docker tag (and digest if present)
  • git commit SHA (if present)
• Declared permissions (filesystem/network allowlists/denylists)
• Notes about multiple sources or overrides (e.g., env var expansions)

---

Step 3 — Determine Authentication Requirements (Do Not Expose Secrets)

Your goal is to describe what auth is required and where it comes from, without printing sensitive material.

3A) Authentication Type (Primary)

Classify each server into one primary auth type:

• none — No authentication visible/required in config
• api_key — Static key (env/header/arg) likely used as API key
• bearer_token — Bearer token / access token used directly
• oauth — OAuth flow implied (client_id/client_secret, token endpoint, refresh tokens)
• basic_auth — Username/password
• mtls — Client certificate / key used for mutual TLS
• custom_header — Non-standard header-based auth that isn’t clearly bearer/api-key
• signed_request — HMAC/signature-based auth indicated (e.g., signing secret + timestamp)
• external_provider — Auth delegated to an external provider/agent (SSO/agent-managed)
• unknown — Auth likely required, but cannot be determined from available config

3B) Authentication Source

Determine where auth material is sourced (choose one or more):

• env — via environment variables
• cli_arg — passed in command-line args
• config_file — embedded in config files (even if redacted)
• headers — explicit header configuration (values redacted)
• embedded_url — user:pass@host or token in URL/query string
• external_flow — OAuth/browser/device flow or separate agent

3C) Authentication Material Location (Safe)

Record only:

• env var names (e.g., SERVICE_API_KEY)
• CLI flags (e.g., --token, --api-key)
• header names (e.g., Authorization, X-API-Key) Never record secret values.

3D) Auth Exposure Risk (Inventory-Level)

This is not a full security rating; it’s a config hygiene flag.

• low — secrets sourced from env, not displayed; no embedded creds
• medium — secrets appear to be passed via CLI args (visible in process lists)
• high — secrets embedded in URLs or hardcoded in config files

---

Step 4 — Redaction Rules (Strict)

4A) Never output secret values

Replace secret-looking values with: ***REDACTED***

4B) Redact if key name matches (case-insensitive substring)

• API_KEY
• TOKEN
• SECRET
• PASSWORD
• AUTH
• BEARER
• CLIENT_SECRET
• ACCESS_KEY
• PRIVATE_KEY
• CERT
• COOKIE

4C) Redact URL credentials and query tokens

If URL contains:

• user:pass@
• token=...
• key=... Output the URL with credentials removed and note embedded_url auth source + high risk.

---

Step 5 — Output Format

1) MCP Server Inventory Table

Name	Launch Type	Version/Tag	Config Source / URL	Transport	Auth Type	Auth Source	Auth Risk

---

2) Per-Server Configuration Snapshot (Redacted)

For each server:

Name:
Display Name (if any):
Source File(s) / Remote URL:
Launch Type:
Transport:
Command / Image / URL:
Args:
Env Keys:
Working Directory:
Version/Pin Status:
Permissions (if declared):

Authentication (Redacted)

Auth Type:
Auth Source:
Auth Material Location (keys/flags/headers only):
Auth Exposure Risk:

---

Quality Checklist

• All config sources scanned (including user/home config locations if accessible)
• Servers deduplicated; all source locations preserved
• Secrets redacted (values never shown)
• Version/pin status captured when available
• Auth type classified for every server (or unknown)
• Auth source and material location captured without leaking secrets
• Auth exposure risk flagged (low/medium/high)
• Clean structured output produced

---