PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Mohammed Mehedi Hasan, Hao Li, Emad Fallahzadeh, Gopi Krishnan Rajbahadur, Bram Adams, Ahmed E. Hassan

arXiv:2506.13538v5cs.SEcs.ET

TL;DR

MCP's expanding ecosystem lacks empirical evidence about server health, security, and maintainability despite risks associated with autonomous tool use. The paper studies 1,899 open-source MCP servers using health metrics and a hybrid SonarQube–mcp-scan analysis pipeline. It finds strong sustainability signals alongside traditional and MCP-specific vulnerabilities and maintainability issues, supporting both MCP-specific detection and established maintainability practices.

  • Problem

    The publicly available MCP ecosystem remains empirically unexplored across health, sustainability, security, and maintainability dimensions despite risks from autonomous tool use.

  • Method

    The study evaluates 1,899 MCP servers using health metrics and a hybrid pipeline combining SonarQube with the MCP-specific scanner mcp-scan.

  • Results

    MCP servers show strong sustainability signals, while 7.2% contain general vulnerabilities, 5.5% exhibit tool poisoning, 66% have code smells, and 14.4% contain bugs.

  • Takeaways & Limitations

    MCP-specific vulnerability detection is needed, while established sustainability assessment and maintainability-improvement techniques remain applicable.

  • Takeaways & Limitations

    The study's baseline choices reflect the best available options at the time, and comparison relevance and precision may improve as the ecosystem matures.

Abstract

from arXiv · show

Although Foundation Models (FMs), such as GPT-4, are increasingly used in domains like finance and software engineering, reliance on textual interfaces limits these models' real-world interaction. To address this, FM providers introduced a tool called -- triggering a proliferation of frameworks with distinct tool interfaces. In late 2024, Anthropic introduced the Model Context Protocol (MCP) to standardize this tool ecosystem. MCP is rapidly emerging as a de facto industry standard. Despite its adoption, MCP's AI-driven, non-deterministic control flow introduces new risks to sustainability, security, and maintainability, warranting closer examination. Towards this end, we present the first large-scale empirical study of MCP. Using state-of-the-art health metrics and a hybrid analysis pipeline that combines a general-purpose static analysis tool with an MCP-specific scanner, we evaluate 1,899 open-source MCP servers to assess their health, security, and maintainability. Despite MCP servers demonstrating strong health metrics, we identify eight distinct vulnerabilities -- only three of which overlap with traditional software vulnerabilities. Additionally, 7.2% of servers contain general vulnerabilities, and 5.5% exhibit MCP-specific tool poisoning. Regarding maintainability, while 66% exhibit code smells, 14.4% contain ten bug patterns overlapping prior research. These findings highlight the need for MCP-specific vulnerability detection techniques while reaffirming the value of traditional analysis and refactoring practices. Furthermore, we advocate for stronger governance across the MCP ecosystem by incorporating MCP-specific vulnerabilities into standardized vulnerability databases, enabling automated security scanning within MCP registries, and promoting responsible development practices to ensure the long-term safety and sustainability of the MCP ecosystem.

1 Introduction

MCP standardizes fragmented AI tool interfaces, but its growing ecosystem raises unresolved concerns about security, sustainability, and maintainability. This study addresses those concerns through a large-scale empirical examination of publicly available MCP servers.

  • Framework-specific tool interfaces fragment AI tool workflows, limiting interoperability, scalability, and consistent security practices.
  • MCP provides a unified client-server protocol for discovering and invoking tools across diverse servers.It is presented as an open standard intended to enhance interoperability in AI tool usage.
  • MCP servers can expose security risks because Foundation Models autonomously decide when and which tools to use.Reported examples include credential theft, malicious code execution, and manipulation of file-writing tools to create backdoors.
  • Real-world incidents include hidden email exfiltration by a malicious server and arbitrary command execution through MCP Inspector.These incidents motivate empirical examination of MCP server health, security, maintainability, and supply-chain trust.
  • The study examines three open questions concerning ecosystem maintenance, traditional and MCP-specific vulnerability prevalence, and maintainability issues across 1,899 MCP servers.The dataset combines 343 servers from the official MCP collection with 1,556 servers mined from GitHub repositories.

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

MCP servers show strong health and sustainability indicators, but the ecosystem still contains substantial security and maintainability concerns. The study combines comparative ecosystem baselines with large-scale analysis to characterize these dimensions.

  • 5.5 commits/week versus 2.5 commits/week for traditional software indicates stronger development activity.
  • 42.2% CI adoption versus 40.3% for traditional software shows slightly stronger continuous-integration adoption.
  • 7.2% of MCP servers contain eight distinct vulnerability patterns, with credential exposure the most prevalent at 3.6%.Only three vulnerability patterns overlap with known ecosystem vulnerabilities.
  • 5.5% of MCP servers suffer from MCP-specific tool poisoning, demonstrating the need to combine traditional and MCP-specific detection.
  • 66% of MCP servers have critical or blocker-level code smells, while 14.4% have critical or blocker-level bugs.High cognitive complexity is the most prevalent code smell.
  • The dataset contains 1,899 open-source MCP servers spanning official, community-maintained, and GitHub-mined sources.The study establishes normalized baselines against PyPI, NPM, and Infrastructure-as-Code ecosystems.

2 A Motivational Example

The motivating example follows an AI engineer building a shopping assistant whose search, recommendation, and payment requirements expose framework-specific tool incompatibility. MCP addresses this interoperability problem by standardizing tool discovery and invocation, while introducing new sustainability, security, and maintenance questions.

  • Alex’s shopping assistant needs dedicated search, language-model recommendation, and Stripe payment capabilities.Tools connect the model to existing APIs or data sources.
  • Framework-specific tool interfaces force repeated Stripe-tool implementations when applications move between incompatible frameworks.The example shows reuse failing across frameworks B and C.
  • MCP standardizes how foundation models discover and invoke external capabilities without hard coupling to an application framework.Open-source Stripe MCP servers can therefore integrate into MCP-enabled applications.
  • The motivating scenario treats sustainability, security, and downstream maintenance as requirements for sensitive payment processing.The example specifically highlights regular development, bug fixing, protection of customer data, and maintenance quality.
  • The study frames unanswered questions about server health, security verification, and maintainability as adoption concerns for critical AI applications.

3 Background

MCP is a client-server protocol that decouples tools from AI frameworks and enables standardized discovery and invocation. Its reflective metadata exchange improves reuse but also creates a distinct attack surface in tool descriptions and schemas.

  • Model Context Protocol: MCP servers host tools independently, while MCP clients let compliant AI applications discover and invoke them through standardized interfaces.
  • Model Context Protocol: A single MCP server can expose services through defined interaction methods, making tools discoverable and invocable across MCP-compliant applications.This plug-and-play model reduces code duplication and supports tool reuse with MCP-aware models.
  • MCP workflow: The MCP client retrieves tool schemas, mediates model-guided calls, and obtains user approval for tool execution.
  • MCP workflow: Reflection dynamically exposes tool names, descriptions, required parameters, and data types without prior client hard-coding.
  • MCP workflow: MCP supports local StdIO and remote SSE over HTTPS communication, covering embedded desktop and cloud deployments.
  • Security: MCP-specific vulnerabilities reside in reflected metadata and natural-language descriptions that guide model behavior at runtime.Traditional vulnerabilities instead arise in executable code, dependencies, configuration, or logic and can be targeted by general analysis.
  • Security: Tool poisoning can redirect an approved message by embedding malicious instructions in a tool description.The example changes the intended recipient and requests prior chat content for validation.
  • Security analysis: MCP-scan dynamically connects to configured live servers, retrieves tool metadata through reflection, and analyzes names, descriptions, and parameter schemas.

4 Related Work

Prior research has established health, security, and maintainability concerns in open-source ecosystems, but MCP servers remain insufficiently characterized. This study addresses gaps in empirical evidence about MCP-specific vulnerabilities and maintenance profiles.

  • Health and sustainability: Existing health predictors vary by project type and maturity, while MCP server health and sustainability had not been characterized.MCP servers resemble reusable OSS components but also involve foundation-model integration and system-level tool orchestration.
  • Security vulnerabilities: MCP security research has identified threats including tool poisoning, command injection, installer spoofing, and configuration drift.Demonstrated exploits also include malicious code execution, remote access control, credential theft, and retrieval-agent deception.
  • Security vulnerabilities: No empirical investigation had quantified how frequently MCP vulnerabilities occur in publicly available servers.Prior work primarily examined controlled examples and proof-of-concept attacks rather than ecosystem-wide prevalence.
  • Maintainability: MCP maintainability research lacks insight into code smells and bugs, despite established links between maintainability issues, fault-proneness, and project outcomes.Prior work has associated high cognitive complexity with low maintainability and higher bug severity with more maintainability issues.
  • Maintainability: Comparisons with PyPI, NPM, and Infrastructure-as-Code projects are needed to determine whether MCP servers require specialized tooling or share standard maintenance profiles.The study analyzes MCP servers with static analysis tools to assess code-smell and bug prevalence.

5 Methodology

The study builds an MCP-server dataset from Anthropic’s repository and GitHub mining, then evaluates health, security, and maintainability using complementary analyses and literature baselines. An LLM-based jury clusters findings into interpretable patterns, while manual validation and consistency trials assess those patterns.

  • Dataset construction: The dataset combines Anthropic-listed servers with additional GitHub repositories identified through MCP SDK imports.The methodology starts from official and community integrations, then searches source code for language-specific SDK import patterns.
  • Dataset construction: 88 official and 255 community integrations were listed by Anthropic on Mar 19, 2025.Repository names and GitHub URLs were recorded for each identified repository.
  • Dataset construction: 1,715 repositories imported MCP server SDKs, with 1,556 remaining as mined MCP servers after removing 159 already documented by Anthropic.The mining cut-off date was Mar 20, 2025.
  • Dataset construction: 583 MCP servers remained after excluding repositories with fewer than ten GitHub stars.The filter targeted toy projects using an established popularity threshold.
  • Health and sustainability: 14 health and sustainability metrics capture development activity through 8 metrics and community engagement through 6 metrics.Seven metrics come from CHAOSS and seven from prior literature; age-normalized metrics support time-invariant comparisons.
  • Health and sustainability: Repository metadata, commit histories, GitHub Actions histories, and contributor logs were collected automatically through the GitHub REST API.Raw and processed data were stored in Elasticsearch for traceability, aggregation, and later cross-RQ retrieval.
  • Security and maintainability analysis: The security and maintainability assessment combines general-purpose static analysis with MCP-specific scanning.Static analysis identifies implementation-level vulnerabilities, bugs, and code smells, while mcp-scan targets risks such as tool poisoning and MCP rug pulls.
  • Security and maintainability analysis: mcp-scan successfully processed 60 of 83 repositories initially and 13 additional repositories after a patched release, reaching 73.The remaining initial failures were attributed to internal tool errors, and the summarized results were added to the replication package.

6 Results

MCP servers show strong development and sustainability indicators, but they also contain both conventional and MCP-specific security vulnerabilities that existing tools may incompletely detect.

  • RQ-0: Ecosystem health: MCP servers exceed or match OSS and ML baselines on 9 of 14 development and community metrics, including 5.5 versus 2.5 median weekly commits.CI adoption is 42.2%, compared with 40.3% for General OSS and 37.2% for ML.
  • RQ-0: Ecosystem health: MCP servers exhibit higher median build success, shorter build times, and faster broken-build resolution than the comparison baselines.These build characteristics are associated with more frequent releases in prior research.
  • RQ-0: Ecosystem health: Age-normalized stars and forks indicate exceptionally fast MCP growth despite lower raw counts than older OSS baselines.The MCP protocol was introduced only six months before the comparison, whereas baseline projects were substantially older.
  • RQ-0: Ecosystem health: Mined MCP servers receive 101.4% more commits than community servers, with median totals of 44.3, 42.0, and 22.0 for mined, official, and community servers.Mined servers are also 56% larger than the official server, with median sizes of 1,445.5, 929, and 548 LoC across mined, official, and community types.
  • RQ-1: Security: Credential exposure is the most common detected vulnerability, while transport security, access control, and resource-management issues form a broader MCP-specific landscape.Only some identified patterns overlap with vulnerabilities commonly reported in PyPI, NPM, and IaC ecosystems.

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

MCP servers exhibit widespread maintainability issues, including prevalent code smells, high cognitive complexity, and statically detected bugs, although many patterns overlap prior software-engineering research.

  • Code-smell prevalence: 66% of MCP servers contain at least one critical or blocker-level code smell, totaling 17,832 detected smells across 385 servers.Median critical-smell counts range from 2 to 4 in common languages, while median blocker-smell counts are zero.
  • Code-smell prevalence: 59.7% of MCP servers exhibit high cognitive complexity, nearly three times the prevalence of the second most common smell, code duplication-redundancy.Prior work associates cognitive complexity above a threshold of 15 with greater comprehension time and reduced understandability.
  • Code-smell prevalence: Recurring maintainability issues include code duplication, function-structure problems, and variable declaration and usage issues.Duplicated logic can cause change misalignment when independently evolving segments diverge.
  • Integration-type differences: 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 for mined versus official and mined versus community servers, but not for official versus community servers.
  • Language differences: JavaScript MCP servers have 50% fewer code smells than Python and TypeScript servers, with a median count of 2 versus 4.The language-group differences are statistically significant.
  • Bug prevalence: 14.4% of MCP servers contain statically detected bugs, comprising nine categories and 523 bugs across 84 projects.The three most frequent patterns do not appear in the Java baseline, while all identified categories overlap known bugs from Java, Python, or JavaScript research.
  • Bug prevalence: Mined servers contain 67% more bugs than community servers, whereas bug percentages do not vary across programming languages.The mined-versus-community difference is significant with a large effect; other integration-type pairs are not significant.

7 Implications

The study argues that MCP security and maintainability require both established software-engineering practices and MCP-specific analysis, supported by stronger governance from registries and standards bodies.

  • Researchers: Security researchers should add MCP-specific threats such as tool poisoning, credential exposure, and transport security issues to vulnerability taxonomies.Only one of the 13 observed CWEs appears in the current MITRE Top 25.
  • Researchers: MCP-specific vulnerability tools should complement general-purpose scanners because MCP exposes threats embedded in reflective tool metadata as well as executable-code vulnerabilities.The proposed hybrid approach combines traditional static analysis with MCP-specific dynamic analysis.
  • Practitioners: Developers should integrate security scanning into CI, protect credentials, and apply established refactoring and debugging practices alongside ML- and LLM-based techniques.The paper identifies exposed API keys, service-account secrets, and access tokens as immediate risks, while MCP code smells and bugs resemble patterns from traditional ecosystems.
  • Practitioners: Users should audit third-party MCP servers before deployment because vulnerabilities and tool poisoning can propagate into downstream applications and compromise host environments.Dynamic scans may require live servers, valid client configurations, and service credentials, creating deployment and runtime overhead.
  • Cross-sector application: The hybrid scanning strategy generalizes across sectors because MCP servers mediate access between foundation models and sensitive external resources.The paper illustrates this division across healthcare, software development, and financial services.
  • Ecosystem governance: Registries should establish governance through developer guidelines, automated vulnerability and sustainability scanning, monitoring, and revocation workflows.Without pre-publication scanning and post-deployment monitoring, centralized registries can propagate insecure MCP servers.

8 Threats to Validity

The study identifies several validity constraints involving dataset coverage, measurement choices, sampling, baseline comparability, and the evolving MCP ecosystem. The authors mitigate some constraints through diverse sourcing, statistical sampling, established standards, manual checks, and robustness analyses.

  • External validity: MCP servers may not represent the entire population, although the dataset combines Anthropic’s curated list with GitHub-mined servers.This diverse sourcing was intended to reduce the threat to external validity.
  • Construct validity: SonarQube and mcp-scan do not provide exhaustive vulnerability coverage, and mcp-scan focuses on tool-description structure and semantics rather than source code or runtime behavior.SonarQube covers categories in MITRE CWE Top 25, OWASP Top 10, and PCI DSS, while mcp-scan was the most recognized maintained option available during the study.
  • Construct validity: Code smells and SonarQube-reported bugs are treated as maintainability indicators, although reported bugs may not always be actual faults and code smells vary in defect correlation.The study reports both categories to characterize maintainability concerns.
  • External validity: SDK-import-based mining may miss repositories that use MCP through third-party SDKs, despite identifying 1,899 servers with the selected search patterns.The authors regard the search patterns as sufficient at the time of the study.
  • External validity: MCP-specific vulnerability prevalence is estimated from 83 randomly selected servers rather than all 583 servers because dynamic scanning requires installation, credentials, and live interaction.The sample was selected using Cochran’s formula with finite population correction, a 95% confidence level, and a 10% margin of error.
  • Internal validity: Comparisons rely on incomplete or methodologically mismatched baselines, including Java-derived bug taxonomies and aggregated metrics from heterogeneous studies.The authors state that cross-ecosystem metrics indicate general ecosystem health rather than provide absolute comparisons, and that baseline relevance should improve as MCP matures.
  • Construct validity: LLM-Jury clustering could introduce hallucination, bias, or misclassification, but the authors used CWE grounding, manual verification of 75 issues, and repeated-run consistency checks.The reported near-perfect expert agreement and stable cluster membership support the robustness of the resulting patterns.
  • Internal validity: Baseline choices reflect the best available options at the study time because MCP is rapidly evolving and domain-specific empirical evidence remains limited.The authors expect comparison relevance and precision to improve as the ecosystem matures.

9 Conclusion

The paper presents the first large-scale study of MCP servers using combined general-purpose and MCP-specific analysis. It finds strong sustainability signals and familiar maintainability concerns, but a distinct security profile requiring dedicated tooling and governance.

  • Conclusion: 1,899 MCP servers were evaluated for sustainability, security, and maintainability using SonarQube alongside mcp-scan.The hybrid approach combines general-purpose static analysis with MCP-specific vulnerability detection.
  • Conclusion: 9 of 14 development and community metrics had median values higher than or equal to comparison values, indicating generally strong sustainability signals.The study also finds code smells and bugs at rates comparable to traditional open-source systems.
  • Conclusion: 66% of MCP servers exhibited code smells and 14.4% contained bugs, supporting continued use of established maintainability assessment and improvement techniques.These rates were reported as comparable to traditional open-source systems.
  • Conclusion: 7.2% of MCP servers contained eight vulnerability patterns, only three overlapping with common issues in Python or Infrastructure-as-Code ecosystems.This security profile differs notably from the ecosystems used for comparison.
  • Conclusion: 5.5% of MCP servers exhibited tool poisoning, an emerging MCP-specific threat.The finding underscores a security risk not fully represented by traditional vulnerability categories.
  • Conclusion: The findings motivate domain-specific security tooling, automated auditing, vulnerability-patch tracking, and stronger governance for MCP infrastructure.The authors frame these measures as important for the safe and reliable evolution of FM-based software systems.

Disclaimer

The disclaimer states that the opinions, findings, conclusions, and recommendations belong to the authors and that AI tools were used for grammatical and writing corrections.

  • Disclaimer: The authors state that the material’s opinions, findings, conclusions, and recommendations do not reflect Huawei’s views.They also report using Grammarly, ChatGPT, and Gemini to correct grammar and writing.
  • Disclaimer: AI tools were used to fix grammatical and writing issues in the study.The named tools are Grammarly, ChatGPT, and Gemini.

A.1 Prompts used by the LLM-Jury

The appendix defines prompts for clustering SonarQube vulnerabilities and judging competing cluster assignments. It specifies grouping criteria, output formats, and evaluation dimensions.

  • A.1.1 Worker Prompt: The worker prompt asks the model to organize SonarQube vulnerabilities into meaningful security clusters.Grouping should reflect shared root causes, remediation approaches, security domains, or industry taxonomies.
  • A.1.1 Worker Prompt: Clusters must use clear, descriptive, actionable labels at appropriate granularity and contain at least two or three vulnerabilities.The prompt prohibits overly broad, overly granular, mixed-domain, redundant, or overlapping clusters.
  • # OUTPUT FORMAT: The worker output requires a table containing each violated rule, quality impact, count, and cluster label.A short description must follow for every cluster.
  • # OUTPUT FORMAT: The worker prompt leaves the vulnerability dataset to be supplied as input data.The appendix labels this section “Your vulnerability data here.”
  • A.1.2 Judge Prompt: The judge prompt evaluates Model A and Model B cluster assignments and selects the most appropriate final label for each vulnerability.The judge receives the original dataset, both model outputs, and must provide a brief reason for each choice.
  • A.1.2 Judge Prompt: Judging weights semantic accuracy at 40%, consistency at 30%, clarity at 20%, and remediation alignment at 10%.Consistency also considers alignment with OWASP, CWE, or widely recognized security taxonomies.
  • # OUTPUT FORMAT: The judge output table records both model labels, the final label, and the reasoning for each vulnerability.The requested summary also reports total vulnerabilities, unique clusters, agreements with each model, and newly created labels.
  • # OUTPUT FORMAT: The appendix concludes with final cluster definitions, requiring a brief description for each cluster label.These definitions summarize the semantic scope assigned to the finalized clusters.

A.2 Evaluating the Consistency of the Issue Patterns Identified by LLM-Jury

Table 13 examines the consistency of vulnerability clusters produced by the LLM-Jury across five independent runs.

  • Table 13 reports consistency for vulnerability clusters produced by the LLM-Jury.
  • The evaluation concerns clusters generated by the LLM-Jury.
  • The consistency assessment spans five independent runs.
Loading 2506.13538v5…