Feature: MCP server registry scanning — complementary to skill scanning

Problem

SkillSpector scans agent skills — it answers "is this SKILL.md safe to install?". But skills frequently invoke MCP servers, and those servers have their own attack surface. There's currently no way to assess whether the MCP servers referenced by a skill are trustworthy.

Proposal

Add a skillspector scan --mcp-registry module that scans MCP server registries (Glama, Smithery, MCP Registry) for:

• Unverified publishers: Servers published by unverified/anonymous accounts
• Excessive tool permissions: Servers requesting unnecessary tool access beyond their stated functionality
• Missing security disclosure: No SECURITY.md, no vulnerability reporting contact
• Supply-chain risks: Outdated dependencies, known CVEs in server packages
• Description-behavior mismatch: Server description doesn't match actual tool implementations

Why This Fits SkillSpector

SkillSpector already has MCP-specific detection in two categories:

• MCP Least Privilege (LP1-LP4): Underdeclared capabilities, wildcard permissions, etc.
• MCP Tool Poisoning (TP1-TP4): Hidden instructions, Unicode deception, parameter injection

These check what's in the skill manifest. The proposed --mcp-registry mode would extend this to check what's published in registries — providing a complete MCP security posture:

1. SkillSpector: "Is this skill safe to install?"
2. Registry scanning: "Is this MCP server safe to connect to?"

Together they cover the full MCP security surface.

Reference Implementation

A reference implementation exists in MCTS (github.com/Perseus-Computing-LLC/MCTS) which scans MCP server registries for: unverified publishers, excessive tool grants, dependency audit gaps, and description-behavior analysis. The detection patterns and scoring methodology could be adapted for SkillSpector.

Scope Suggestion

A new CLI flag --mcp-registry that:

1. Accepts a registry URL or server name
2. Fetches server metadata and tool manifests
3. Runs existing LP/TP pattern checks against published manifests
4. Adds registry-specific checks (publisher verification, dep analysis)
5. Reports a risk score

This could integrate with the existing analyzer pipeline — the registry data is just another input source for the same detection engine.

Start by reviewing the existing CLI entry point and MCP least-privilege/tool-poisoning analyzer pipeline mentioned in the issue. Then map how registry metadata and tool manifests could flow through those components. Done would require a registry URL or server-name input, registry-specific checks, and a reported risk score, but the issue names no files or tests.