analyze-server

Purpose

Conduct a security-focused audit of one or more MCP servers.

It does not perform discovery — only security analysis. Use list-servers skill to adequately find the server that is needed for inspection.

Outcomes

For each MCP server analyzed, you will produce:

1. Configuration risk analysis
2. Permission & blast radius assessment
3. Supply-chain integrity evaluation
4. GitHub issue & advisory recon
5. Dependency vulnerability review
6. Risk rating with justification
7. Remediation plan

Operating Principles

• Treat MCP servers as privileged software.
• Default to zero trust.
• Separate facts from inferences.
• Provide evidence-backed conclusions.
• Focus on high-signal risks.

Step 1 — Configuration Risk Review

Evaluate:

A) Permission Scope

• Filesystem access breadth
• Network egress openness
• Tool execution capability
• Shell access
• Container isolation (if any)

Flag:

• Full disk access
• Unrestricted network
• Arbitrary command execution

---

B) Secrets Handling

Check for:

• Hardcoded tokens
• .env committed
• Plaintext credentials
• Debug logging of env vars

If detected → mark Critical

---

C) Version Pinning & Provenance

Assess:

• Docker using latest
• npm with no lockfile
• pip without hashes
• git branch refs (e.g., main)
• No digest pin

Unpinned privileged server = High risk

---

Step 2 — GitHub & Web Recon (Required)

For each server:

2A) Identify Canonical Repository

Determine:

• Official GitHub repo
• Package registry page
• Docker source

If unclear:

• Search by server name + runtime + “MCP”

---

2B) Recent Issue Analysis (Last 90 Days)

Search for:

• security
• RCE
• auth bypass
• token leak
• SSRF
• path traversal
• sandbox escape
• crash
• data loss

Capture:

• Title
• Status
• Recency
• Maintainer response
• Fix availability

---

2C) Vulnerability Advisory Review

Check:

1. GitHub Security Advisories (GHSA)
2. CVE/NVD
3. OSV.dev
4. npm/PyPI advisories
5. Docker base image CVEs (if relevant)

Document:

• Advisory ID
• Affected versions
• Fixed version
• Severity (CVSS if available)
• Exploit type

---

Step 3 — Dependency Risk Analysis

If lockfiles exist:

• Identify top dependencies
• Check each for recent advisories
• Flag abandoned packages

Look for:

• Prototype pollution
• Deserialization issues
• Command injection
• Path traversal
• SSRF

---

Step 4 — Maintenance & Trust Signals

Evaluate:

• Release cadence
• Issue response time
• Open vs closed issue ratio
• Security policy presence
• Signed releases

Low activity + high privilege = elevated risk.

---

Step 5 — Risk Rating Framework

Critical

• Active RCE
• Secret exposure
• Known exploited vulnerability
• No fix available

High

• Serious vulnerability unpatched
• Wide permissions + weak validation
• Unpinned floating dependencies

Medium

• No known CVEs but weak hardening
• Slow maintenance

Low

• Pinned versions
• Narrow permissions
• No recent advisories

Always justify rating with evidence.

---

Step 6 — Remediation Plan

Provide:

Immediate

• Patch/upgrade version
• Pin dependencies
• Rotate exposed secrets
• Restrict permissions

Short-Term

• Add dependency scanning to CI
• Add secret scanning
• Containerize with least privilege

Long-Term

• Formal threat model
• Periodic security review
• Supply chain verification (SLSA, signed images)

---

Output Format

For each server:

Server: {Name}

Configuration Risks:
Permission Analysis:
Secrets Posture:
Supply Chain Risks:
Recent GitHub Issues:
Advisories/CVEs:
Dependency Risks:
Maintenance Signals:

Risk Rating:
Evidence:

Recommended Actions:

---

Completion Checklist

• Config risk reviewed
• Permissions analyzed
• GitHub issues reviewed (last 90 days)
• Advisories checked
• Dependencies examined
• Risk rating assigned
• Remediation provided

---