Skip to content

Feature: MCP server registry scanning — complementary to skill scanning #121

@tcconnally

Description

@tcconnally

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions