Proposal: optional security scan metadata field for registered MCP servers

This issue proposes adding optional security scan metadata to MCP server registry entries, so that users browsing the registry can see whether a given MCP server has been scanned by community detection tools and what the result was. The proposal is intentionally narrow and is meant to start a conversation, not lock in a design.

Background. Static security scanning of MCP server packages and skill bundles is becoming a common practice. The Agent Threat Rules project is an open detection standard for AI agent threats published under Apache-2.0 at https://github.com/Agent-Threat-Rule/agent-threat-rules with 330 community-maintained YAML rules. As of recent wild scan data, the project has scanned 96,096 skills across multiple distribution channels and identified 751 confirmed malicious skills in production ecosystems. Other community scanners exist as well, including cisco-ai-defense/skill-scanner (which uses Agent Threat Rules) and microsoft/agent-governance-toolkit. The detection rule set has 100 percent coverage of the NIST AI Risk Management Framework, mappings into OWASP Agentic Top 10 and SAFE-MCP, and is in production at Cisco AI Defense and Microsoft agent-governance-toolkit.

Concrete proposal. An optional security_scan field on registry entries that points to one or more external scan results. Two possible shapes. First, a list of objects with scanner name, scanner version, scan timestamp, summary verdict (clean, warnings, or findings), and a URL to the full machine-readable report. Second, a simpler badge-style field with a link to a scan report URL and a freshness timestamp, leaving the verdict format up to the scanner. Either shape leaves the registry as the metadata layer and keeps the actual scanner code and rule set out of tree.

Questions for the maintainers. First, does this kind of optional scan metadata fit the current registry roadmap, or is the intention to keep registry entries as pure declarative server metadata with no security signals. Second, if a security_scan field would be welcome, is there a preference for a pluggable scanner-agnostic format versus a single canonical format. Third, are there governance concerns about embedding pointers to community detection tools (false positives, vendor neutrality, scanner verification) that we should design around up front.

Happy to draft a more concrete proposal once there is direction from the maintainers. No claim of endorsement of any specific scanner is implied; the goal is a neutral mechanism that any community scanner can plug into.

Start by reviewing the registry entry model and the maintainers’ roadmap, then examine the proposal’s two possible security_scan shapes and the governance questions it raises. A useful outcome would require maintainer direction on whether security metadata belongs in registry entries and agreement on a scanner-neutral format before implementation can be scoped.