Model Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers

• MCP provides a unified client-server protocol that standardizes tool discovery and invocation, reducing fragmentation and enabling reusable tools across AI applications and frameworks.Its adoption also reduces model and framework vendor lock-in and supports faster development through existing MCP servers.Source: §1 · p. 2
• MCP adoption has accelerated rapidly, with its official SDK exceeding 25 million weekly downloads and an estimated 86% of enterprises accessing MCP-capable workflows.Industry adoption by Microsoft, OpenAI, Google, and Cloudflare further motivates systematic examination of MCP servers as open-source software.Source: §1 · p. 2
• MCP’s autonomous tool-use model creates security risks because vulnerable servers can be manipulated into credential theft, malicious code execution, or other unauthorized actions.A file-writing tool could be used to alter .bashrc and open a backdoor port.Source: §1 · p. 3
• Real-world incidents include a malicious Postmark-MCP server that exfiltrated thousands of emails and an MCP Inspector vulnerability enabling arbitrary command execution through a malicious website.These incidents expose risks to user systems, data integrity, and software supply-chain trust.Source: §1 · p. 3
• Before this work, the health, sustainability, security posture, and maintainability of publicly available open-source MCP servers remained largely unexplored despite their importance for trustworthy adoption.The authors frame visibility into these dimensions as necessary for understanding attack surfaces and long-term operational implications.Source: §1 · p. 3
• The study analyzes 1,899 MCP servers to empirically assess ecosystem maintenance, traditional and MCP-specific vulnerabilities, and maintainability issues.The dataset contains 343 servers from the official MCP collection and 1,556 mined from GitHub repositories as of June 1, 2025.Source: §1 · pp. 3–4

Health and sustainability

• MCP servers average 5.5 commits/week versus 2.5 for traditional software and have 42.2% versus 40.3% CI adoption, with comparable contributors, greater follower reach, and slower issue resolution.Median contributor count is 2.0 in both groups; median contributor followers are 129.6 versus 37.3, while median issue resolution is 5.6 versus 4.0 days.Source: RQ-0: How healthy and sustainable are… · p. 4

Security vulnerabilities

• 7.2% of MCP servers contain eight vulnerability patterns, with credential exposure most prevalent at 3.6%, while MCP-specific scanning finds tool poisoning in 5.5%.Only three of the eight vulnerability patterns overlap with known ecosystem vulnerabilities, showing that traditional tools capture only part of the landscape.Source: RQ-0: How healthy and sustainable are… · p. 4

Maintainability issues

• 66% of MCP servers have critical or blocker-level code smells, and 14.4% have critical or blocker-level bugs across taxonomies of ten smells and nine bugs.High cognitive complexity is the most prevalent code smell, and these issues resemble patterns documented in traditional software engineering.Source: RQ-0: How healthy and sustainable are… · pp. 4–5

Dataset

• The study releases a curated dataset of 1,899 servers spanning 88 official, 255 community-maintained, and 1,556 GitHub-mined servers.The dataset is designed to support reproducible, extensible, and longitudinal ecosystem-level research.Source: RQ-0: How healthy and sustainable are… · p. 5

Analysis framework

• The study establishes normalized cross-ecosystem baselines and a hybrid framework combining general-purpose static analysis with MCP-specific vulnerability detection.The framework combines SonarQube with mcp-scan to jointly evaluate traditional and MCP-specific vulnerabilities.Source: RQ-0: How healthy and sustainable are… · p. 5

Overall findings

• 1,899 open-source MCP servers show strong health and sustainability metrics but also contain traditional and MCP-specific vulnerabilities, code smells, and recurring bug patterns.The evaluation covers health, security, and maintainability through large-scale empirical analysis.Source: RQ-0: How healthy and sustainable are… · p. 5

The Problem

• Framework-specific tool interfaces forced Alex to reimplement Stripe integrations across applications, revealing a fundamental lack of tool interoperability and standardization.The scenario spans frameworks A, B, and C, whose incompatible interfaces, invocation methods, and data handling prevented tool reuse.Source: Figure 1 · p. 6, §2 · p. 7

The Promise

• MCP standardizes how foundation models discover and invoke external capabilities through framework-independent interfaces, enabling reusable Stripe MCP servers and eliminating duplicated integration effort.Applications can directly integrate community-provided Stripe MCP servers when they leverage MCP.Source: Figure 1 · p. 6, §2 · p. 7

The Challenge

• Sensitive payment applications require MCP servers that remain sustainable, secure, and maintainable despite multiple community implementations.The scenario highlights reliable development and bug fixing, protection of customer data, and avoidance of downstream maintenance issues as selection criteria.Source: §2 · p. 7

Research Questions

• The study addresses these concerns through quantitative and qualitative analysis of MCP-server health and sustainability (RQ-0), security (RQ-1), and maintainability (RQ-2).The motivating scenario frames unanswered questions about server reliability, vulnerability prevalence and detection, and bugs or code smells.Source: §2 · pp. 7–8

3.1 Tool Landscape for FM-based AI Applications

• External tools let text-only foundation models retrieve data, invoke APIs, execute code, and control hardware, while frameworks such as LangChain, Autogen, and LlamaIndex orchestrate tool use.These frameworks help applications plan tasks and coordinate tool calls, but configuring tools correctly can be challenging.Source: §3.1.1 · p. 8, §3.1.2 · p. 8

3.1.3 Tool Workflow.

• Framework-specific tools follow application-driven workflows in which the model plans and sequences calls, such as searching for products, collecting preferences, and completing payment through an API.The application formats the user intent, retrieves available tools, embeds them in a prompt, and follows the model’s resulting execution path.Source: §3.1.3 · p. 8

3.1.4 Shortcomings of Framework-Specific Tools.

• Framework-specific schemas and tight coupling hinder tool compatibility, discoverability, reuse, and integration across LangChain, AutoGen, and LlamaIndex.The passage compares this fragmentation with early software-engineering challenges later addressed by package managers such as NPM and PyPI.Source: §3.1.4 · p. 8

3.2 Model Context Protocol(MCP)

• MCP addresses framework fragmentation with a universal protocol and client-server architecture that hosts tools in standalone MCP servers and exposes them through standardized MCP clients.A tool vendor can publish a service once as an MCP server, making it discoverable and invocable by MCP-compliant applications while reducing duplication and development overhead.Source: §3.2 · pp. 8–9, Figure 2 · p. 9

3.2.1 MCP Workflow.

• MCP clients query servers through reflection, provide tool names, descriptions, and schemas to the model, mediate parameterized calls, and obtain user approval before execution.This decoupling allows tools to be reused across applications and frameworks; servers validate inputs, execute tools, format responses, and may run locally or remotely.Source: §3.2.1 · p. 9, §3.2.2 · p. 9, §3.2.3 · p. 9

3.2.3 Reflection.

• MCP supports local StdIO and remote SSE over HTTPS communication, enabling deployments from embedded desktop applications to cloud-based servers.MCP registries such as Smithery, Glama, and Cloudflare Workers provide searchable publication and discovery of MCP servers.Source: §3.2.4 · p. 10, §3.2.6 · p. 10

3.2.7 MCP-specific vulnerabilities.

• MCP servers add a risk surface in reflected capabilities and natural-language tool descriptions beyond traditional vulnerabilities in executable code, configuration, and dependencies.Tool poisoning can redirect an otherwise legitimate tool—for example, changing a message recipient and leaking conversation content—without modifying executable logic, dependencies, or control flow.Source: §3.2.7 · p. 10, Figure 3 · p. 11

3.2.8 MCP-Scan.

• MCP-scan dynamically reads configured MCP clients, connects to their servers, reflects tool metadata at runtime, and applies pattern-matching and semantic analysis to identify risks.Unlike static analysis, it does not inspect source code, infrastructure configuration, or access-control settings; those artifacts require separate static-analysis techniques.Source: §3.2.8 · pp. 10–11

4.1 Health and Long-Term Sustainability of OSS

• No existing studies characterize MCP servers’ health or sustainability, despite their unique foundation-model integration and system-level tool-orchestration constraints.Prior work on PyPI and NPM established sustainability metrics, motivating their adaptation to MCP servers.Source: §4.1 · pp. 11–12

4.2 Security Vulnerabilities in OSS and Package Ecosystems

• Existing MCP security research demonstrates threats and exploits, but has not measured their real-world prevalence in publicly available MCP servers.Reported threats include tool poisoning, command injection, installer spoofing, configuration drift, MCE, RAC, CT, and RADE attacks.Source: §4.2 · p. 12

4.3 Maintainability of OSS

• MCP maintainability remains uncharacterized, including code smells and bugs, and has not been benchmarked against ecosystems such as PyPI, NPM, or IaC projects.The study uses static analysis to assess these issues and determine whether MCP servers require specialized tooling or share standard ecosystem maintenance profiles.Source: §4.3 · p. 13

5.1 Data Collection

• The final dataset contains 583 MCP servers after combining Anthropic’s listings with GitHub SDK-import mining and excluding repositories with fewer than ten stars.Anthropic’s repository contributed 88 official and 255 community integrations; mining identified 1,715 SDK-importing repositories, including 1,556 not already listed, before filtering.Source: §5.1.1 · p. 13, §5.1.2 · p. 14, §5.1.3 · p. 15

5.1.4 Mining and storing repository metrics

• The study selects 14 repository metrics—eight for development activity and six for community engagement—from CHAOSS and prior literature to characterize sustainability.Raw metadata, commit histories, GitHub Actions histories, and contributor logs are collected through the GitHub REST API and transformed into age-independent, standardized measures.Source: §5.1.4 · p. 15

5.2 Hybrid Analysis of MCP Servers

• The hybrid analysis combines SonarQube for implementation-level vulnerabilities, bugs, and code smells with MCP-scan for architecture-specific risks such as tool poisoning.SonarQube statically examines source code, while MCP-scan dynamically analyzes runtime-exposed tool interfaces.Source: §5.2 · p. 17, §5.2.1 · p. 17

5.2.2 Dynamic Analysis using mcp-scan

• MCP-scan was applied to a representative sample of 83 repositories, but internal tool errors initially limited successful scans to 60 and a patched release increased this to 73.The sample used Cochran’s formula with a 95% confidence level and 10% margin of error; servers were installed, configured with credentials, and scanned at runtime.Source: §5.2.2 · pp. 17–18

5.3 Clustering the Issues

• The LLM-Jury clusters deduplicated SonarQube issues into higher-level vulnerability, code-smell, and bug patterns using two workers and one judge.Claude-3.7-sonnet and GPT-4o independently label issues, while Gemini-2.5-pro selects the final pattern label using normalized taxonomy prompts.Source: §5.3.1 · p. 19, §5.3.2 · p. 19

5.3.2 Applying LLM Jury

• LLM-Jury clustering achieved perfect vulnerability agreement and near-perfect code-smell and bug agreement against human consensus, with Fleiss’ κ values of 1.0 and 0.9.The validation used 25 randomly sampled issues from each category, totaling 75 issues rated by two authors and the LLM-Jury.Source: §5.3.2 · p. 20

5.3.4 Evaluating the Consistency of the Issue Patterns Identified by LLM-Jury

• Across five shuffled-order trials, clustering achieved 100% membership consistency and 0.75 average naming similarity, indicating stable issue grouping and standardized labels.The study reused the first run’s names for subsequent analysis.Source: §5.3.3 · p. 20, §5.3.4 · p. 20

5.4 Finding Comparable Baselines

• The literature review conducted 135 Google Scholar searches and selected 40 prior studies to establish comparative baselines for metrics, vulnerabilities, code smells, and bugs.Studies were filtered for peer review, empirical open-source focus, and domain relevance; extracting the comparison data required approximately 60 person-hours.Source: §5.4 · p. 21

6.1 RQ-0: How healthy and sustainable are MCP servers?

• MCP servers demonstrate higher or equal median values in 9 of 14 development and community metrics than OSS and ML baselines, indicating promising sustainability.They report 5.5 commits/week versus 2.5 for general OSS, and 42.2% CI adoption versus 40.3% for general OSS and 37.2% for ML.Source: §6.1 · p. 23, Table 5 · p. 23
• Age-normalized MCP growth exceeds OSS baselines, averaging approximately 79 stars and 18 forks per year versus 34.7 stars and 7.5 forks.Raw star and fork counts are lower because MCP servers are substantially newer, but their normalized trajectory is faster.Source: Table 5 · p. 23, §6.1 · p. 24
• Mined MCP servers are more active and larger than community servers, receiving 101.4% more commits and containing 56% more lines of code than official servers.Median commits are 44.3, 42.0, and 22.0 for mined, official, and community servers; median LoC are 1,445.5, 929, and 548, respectively.Source: §6.1 · p. 24

6.2 RQ-1: To what extent do MCP servers contain security vulnerabilities?

• MCP vulnerability patterns are broader and more distinctive than those in other ecosystems: only three of eight detected patterns overlap with other domains.Credential exposure is most common, while access-control, resource-management, and transport-security issues are also prevalent but not prominent in the compared ecosystems.Source: §6.2 · pp. 25, 26, 29, Table 6 · p. 26
• 7.2% of MCP server repositories contain at least one security vulnerability, while 5.5% exhibit potential tool poisoning detected by mcp-scan.The study detects 277 vulnerabilities across 42 servers; tool poisoning was found despite substantial setup difficulty and limited scan coverage.Source: §6.2 · pp. 26–27
• Vulnerable repositories are larger, more complex, less maintained, and often single-contributor projects, whereas official servers show no SonarQube-detected vulnerabilities.Vulnerable repositories have median 4,529 LOC, 755 cyclomatic complexity, 144,135 Halstead volume, and 226.5 days since last commit; official servers have median vulnerability count zero.Source: §6.2 · pp. 28–29, Figure 5 · p. 28, Table 8 · p. 29

6.2.1 Prevalence of code smells in MCP server repositories.

• 59.7% of MCP servers exhibit high cognitive complexity, nearly three times more frequently than code duplication-redundancy.Recurring additional smells include duplication, function-structure issues, and variable declaration or usage problems that hinder debugging, testing, and reasoning about program state.Source: RQ-2: To what extent do MCP servers… · p. 31, §6.2.1 · p. 32
• Mined MCP servers contain 66% more code smells than official and community servers, with median counts of 5 versus 3.The difference is statistically significant, while official and community servers do not differ significantly; larger mined-server size may partly explain the pattern.Source: §6.2.1 · pp. 32–34, Figure 8 · p. 34

6.2.2 Prevalence of bugs in MCP server repositories.

• MCP servers contain nine distinct bug categories affecting 14.4% of servers, and all categories have been studied previously in Java, Python, or JavaScript ecosystems.The three most prevalent categories are Array Manipulation Issues, Parameter Mismatches, and Type/Structure Issues; established debugging practices can therefore be reused with adaptation.Source: §6.2.2 · pp. 34–36
• Mined servers contain 67% more bugs than community servers, whereas bug prevalence does not significantly differ across programming languages.The integration-type difference is significant, with mined versus community comparisons showing p−value=0.026 and d=−0.557; language differences are non-significant at H=4.9, p=0.178.Source: §6.2.2 · pp. 35–36, Figure 9 · p. 36

RQ-2: To what extent do MCP servers contain maintainability issues?

• 66% of MCP servers contain at least one critical or blocker-level code smell, while 14.4% contain at least one statically detected bug.The study characterizes maintainability using SonarQube-detected critical and blocker-level smells and bugs, alongside higher-level pattern analysis.Source: RQ-2: To what extent do MCP servers… · p. 30, §6.2.2 · p. 36

7.1 Implication for Researchers

• Researchers should expand vulnerability taxonomies and develop MCP-specific analysis tools for threats that general-purpose scanners and early MCP tools may miss.Current taxonomies largely omit tool poisoning, credential exposure, and transport-security issues, while existing MCP-specific tools mainly target tool poisoning with limited reliability and coverage.Source: §7.1 · p. 37

7.2 Implication for Practitioners

• MCP developers should combine proactive secret-management and security testing with traditional software-engineering practices and FM-assisted tools for code smells, bugs, and technical debt.Recommended measures include SAST, automated secret detection, peer-reviewed changes, environment-based credentials, AI-assisted pre-commit and IDE analysis, and automated refactoring.Source: §7.2 · pp. 37–38
• MCP users should audit third-party servers before deployment, using staged static and dynamic scanning to limit downstream compromise while managing runtime and credential exposure.The proposed workflow scans all candidates statically, applies dynamic mcp-scan to shortlisted or high-risk servers, schedules rescans, and uses sandboxed environments where appropriate.Source: §7.2 · p. 38
• A hybrid pipeline is domain-agnostic yet sector-aware because static analysis examines executable-code vulnerabilities while dynamic analysis inspects protocol-specific threats in reflective metadata across financial, healthcare, and software-development deployments.Examples include detecting exposed credentials and poisoned payment tools, PHI-access coercion, and compromised CI/CD operations.Source: §7.2 · pp. 38–39

7.3 Implication for Ecosystem Maintainers

• MCP registries should establish standardized governance, automated pre-publication and post-deployment scanning, and revocation workflows to prevent insecure servers from propagating.Existing registry checks often miss credential exposure and tool poisoning; proposed controls include submission checklists, permission disclosures, security-guideline conformance, continuous monitoring, and automated revocation.Source: §7.3 · p. 39

8.1 External validity

• The open-source dataset and SDK-import mining may miss MCP servers, while the 10-star filter may not reliably indicate repository quality or relevance.The dataset combined Anthropic’s curated list with GitHub mining and yielded 1,899 servers; the 10-star threshold was a practical compromise in a nascent ecosystem.Source: §8.1 · pp. 39–40, §8.2 · p. 40

8.2 Construct validity

• SonarQube bugs and code smells are treated as maintainability indicators despite imperfect correspondence with actual faults, while cross-ecosystem metrics indicate general health rather than absolute comparability.The sustainability metrics were drawn from prior literature but were not exhaustive, and median values were unavailable for some domains.Source: §8.1 · p. 40, §8.2 · pp. 40–41

8.1 External validity

• SonarQube and mcp-scan may miss vulnerabilities, especially deeper runtime or code-level flaws, but together provide the best available coverage.mcp-scan analyzes tool descriptions through the reflection protocol and does not perform fuzzing, runtime monitoring, or execution-path exploration; its prevalence estimate used 83 randomly selected servers with 95% confidence and a 10% margin of error.Source: §8.1 · pp. 39–40

8.2 Construct validity

• LLM-Jury clustering could hallucinate, misclassify, or inherit bias, but CWE grounding, manual verification of 75 issues, and repeated-run consistency supported stable issue patterns.The authors report near-perfect agreement with human experts and high consistency of cluster membership across runs.Source: §8.2 · p. 41

8.3 Internal validity

• Baseline comparisons are constrained because MCP is young and prior studies use different populations, metrics, vulnerability sources, and analysis methods.For RQ-0, the authors aggregated heterogeneous OSS baselines, normalized time-dependent measures, and emphasized relative positioning; RQ-1 comparisons contrasted community-reported PyPI and NPM databases with SonarQube and MCP-specific tooling.Source: §8.3 · p. 41
• The Java-based bug taxonomy used for RQ-2 is an unavoidable compromise for Python, JavaScript, and TypeScript servers, while language-specific patterns and future evidence can improve comparisons.The study separately examined language-specific research on observed patterns, and the authors expect baseline relevance and precision to improve as MCP matures.Source: §8.3 · pp. 41–42

Study Scope

• The study analyzes 1,899 MCP servers using SonarQube and mcp-scan to assess sustainability, security, and maintainability.This is presented as the first large-scale empirical study of MCP servers.Source: §9 · p. 42

Sustainability and Maintainability

• 66% of MCP servers exhibit code smells and 14.4% contain bugs, while sustainability metrics are higher or equal to traditional systems in 9 of 14 measures.These rates suggest established sustainability assessment and maintainability improvement techniques remain applicable to MCP.Source: §9 · p. 42

Security

• 7.2% of MCP servers contain eight vulnerability patterns, only three overlapping common ecosystem issues, while 5.5% exhibit MCP-specific tool poisoning.These results indicate that MCP security requires dedicated vulnerability detection beyond traditional analysis.Source: §9 · p. 42

Implications

• MCP adoption calls for domain-specific security tooling, automated registry auditing, longitudinal vulnerability-patch tracking, and robust ecosystem governance.These measures aim to support the safe and reliable evolution of FM-based software systems.Source: §9 · p. 42

• The authors disclaim Huawei’s responsibility for the paper’s opinions, findings, conclusions, and recommendations, and disclose using Grammarly, ChatGPT, and Gemini to correct grammatical and writing issues.Source: Disclaimer · p. 42

A.1.1 Worker Prompt.

• The Worker Prompt asks an LLM to organize SonarQube vulnerabilities into security clusters based on shared causes, remediation, or security concerns.The task emphasizes meaningful grouping rather than isolated vulnerability labels.Source: §A.1.1 · p. 49
• Worker clustering criteria include root-cause similarity, remediation approach, security domain, and alignment with OWASP Top 10 or CWE taxonomies.These criteria are intended to connect vulnerabilities with related weaknesses and recognized security categories.Source: §A.1.1 · p. 49
• Worker clusters must contain at least 2–3 vulnerabilities and use clear, descriptive, professional, actionable labels while avoiding overly broad, granular, unrelated, or redundant groupings.The prompt also requires consistent naming and appropriate granularity.Source: §A.1.1 · pp. 49–50

# OUTPUT FORMAT

• The output format requires a table listing each violated rule, quality impact, count, and cluster label, followed by a 1–2 sentence summary for each cluster.The prompt also provides a placeholder for the input vulnerability data.Source: # OUTPUT FORMAT · p. 50

A.1.2 Judge Prompt.

• The Judge Prompt compares Model A and Model B cluster assignments against the original SonarQube vulnerability dataset and selects the most appropriate label for each vulnerability.The dataset includes vulnerability names, Quality Impact types, and counts.Source: §A.1.2 · p. 50
• Judge evaluation weights semantic accuracy at 40%, consistency at 30%, clarity at 20%, and remediation alignment at 10%.Consistency includes alignment with OWASP, CWE, or widely recognized security taxonomies, while remediation alignment concerns grouping shared root causes.Source: §A.1.2 · p. 50

# OUTPUT FORMAT

• The Judge output records Model A and Model B labels, the final label, and reasoning for each vulnerability, then reports cluster totals, model agreement, newly created labels, and final cluster definitions.This format supports both row-level adjudication and aggregate reporting.Source: # OUTPUT FORMAT · pp. 50–51

• The analysis assesses the consistency of vulnerability clusters generated by the LLM-Jury.Source: Table 13 · p. 52
• The consistency evaluation spans five independent LLM-Jury runs.Source: Table 13 · p. 52
• The evaluated outputs are vulnerability clusters produced by the LLM-Jury.Source: Table 13 · p. 52