Paper deep dive
A Large-Scale Dataset of MCP Implementations on GitHub
Benny Toeppe, Amine Barrak, Emna Ksontini
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 7/14/2026, 5:20:40 AM
Summary
This paper presents a large-scale, evidence-based dataset of 2,297 real-world Model Context Protocol (MCP) implementations collected from GitHub. Using a multi-stage verification pipeline combining REST/GraphQL APIs and custom Python scripts, the authors classify repositories into operational roles (Client, Server, Gateway) and analyze language usage, architecture patterns, and development activity. The study highlights Python and TypeScript dominance, the prevalence of hybrid architectures, and provides a reproducible JSONL benchmark for future research on MCP ecosystems.
Entities (8)
Relation Signals (8)
Client → connectsto → Server
confidence 95% · Client: initiates connections to MCP servers and consumes their tools, resources, or prompts.
Dataset → contains → 2,297 validated projects
confidence 95% · resulting in a final dataset of 2,297 validated MCP projects.
Model Context Protocol (MCP) → defines → Client-Server Architecture
confidence 95% · It defines how an application with an embedded model discovers capabilities and invokes them through a simple client–server design
Python → dominates → MCP Development
confidence 92% · The analysis shows that Python and TypeScript dominate MCP development
TypeScript → dominates → MCP Development
confidence 92% · The analysis shows that Python and TypeScript dominate MCP development
GitHub → hosts → MCP Implementations
confidence 90% · This study presents the first large-scale, evidence-based dataset of real-world MCP implementation collected directly from GitHub.
Gateway → mediatestrafficfor → Client and Server
confidence 90% · Gateway: Mediates MCP traffic between components or external ecosystems.
Verification Pipeline → utilizes → GitHub REST API
confidence 85% · Using a hybrid pipeline that integrates the GitHub REST and GraphQL APIs with custom Python verification scripts
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The rapid emergence of the Model Context Protocol (MCP) has introduced a new standard for connecting large language models to external tools and services. Despite its rapid adoption in open-source development, systematic understanding of how MCP is implemented, structured, and maintained remains limited. This study presents the first large-scale, evidence-based dataset of real-world MCP implementation collected directly from GitHub. Using a hybrid pipeline that integrates the GitHub REST and GraphQL APIs with custom Python verification scripts, 3,238 candidate repositories were discovered, filtered, and validated through multi-stage evidence checks. Each verified project was classified by operational role (e.g., client, server, gateway) and exported in a reproducible JSONL schema. A manual review of a representative subset confirmed an overall precision of 83% at a 95% confidence level, and additionally revealed a set of repositories functioning primarily as educational samples, tutorials, or demonstration templates. A targeted exclusion rule was then applied to remove these non-operational repositories, resulting in a final dataset of 2,297 validated MCP projects. The analysis shows that Python and TypeScript dominate MCP development, with hybrid architectures emerging as the most common design pattern. By emphasizing transparent verification strategies, structured evidence tagging, and reproducible data organization, this work establishes a foundational benchmark for studying real-world MCP ecosystems and supports future research on integration, connectivity, and compatibility across the broader developer community.
Tags
Links
- Source: https://arxiv.org/abs/2607.10123v1
- Canonical: https://arxiv.org/abs/2607.10123v1
Trouble viewing inline? Open PDF directly →
Full Text
22,390 characters extracted from source content.
Expand or collapse full text
A Large-Scale Dataset of MCP Implementations on GitHub Benny Toeppe Oakland University Michigan, USA btoeppe@oakland.edu Amine Barrak Oakland University Michigan, USA aminebarrak@oakland.edu Emna Ksontini University of North Carolina Wilmington North Carolina, USA ksontinie@uncw.edu Abstract The rapid emergence of the Model Context Protocol (MCP) has introduced a new standard for connecting large language mod- els to external tools and services. Despite its rapid adoption in open-source development, systematic understanding of how MCP is implemented, structured, and maintained remains limited. This study presents the first large-scale, evidence-based dataset of real- world MCP implementation collected directly from GitHub. Using a hybrid pipeline that integrates the GitHub REST and GraphQL APIs with custom Python verification scripts, 3,238 candidate repos- itories were discovered, filtered, and validated through multi-stage evidence checks. Each verified project was classified by operational role (e.g., client, server, gateway) and exported in a reproducible JSONL schema. A manual review of a representative subset con- firmed an overall precision of 83% at a 95% confidence level, and ad- ditionally revealed a set of repositories functioning primarily as ed- ucational samples, tutorials, or demonstration templates. A targeted exclusion rule was then applied to remove these non-operational repositories, resulting in a final dataset of 2,297 validated MCP projects. The analysis shows that Python and TypeScript dominate MCP development, with hybrid architectures emerging as the most common design pattern. By emphasizing transparent verification strategies, structured evidence tagging, and reproducible data or- ganization, this work establishes a foundational benchmark for studying real-world MCP ecosystems and supports future research on integration, connectivity, and compatibility across the broader developer community. CCS Concepts • Software and its engineering→Software repositories and source code management;• Information systems→Data min- ing;• Computing methodologies→ Machine learning. Keywords Model Context Protocol (MCP), dataset, GitHub, open source soft- ware, repository mining, GraphQL, gateways ACM Reference Format: Benny Toeppe, Amine Barrak, and Emna Ksontini. 2026. A Large-Scale Dataset of MCP Implementations on GitHub. In 23rd International Conference on Mining Software Repositories (MSR ’26), April 13–14, 2026, Rio de Janeiro, Brazil. ACM, New York, NY, USA, 5 pages. https://doi.org/10.1145/3793302. 3793311 This work is licensed under a Creative Commons Attribution 4.0 International License. MSR ’26, Rio de Janeiro, Brazil © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2474-9/2026/04 https://doi.org/10.1145/3793302.3793311 1 Introduction Modern language model systems are moving from pure text gen- eration to agents that use tools and live data, enabling them to plan tasks, call external services, and work with information that changes over time rather than relying only on training data [2,7]. Early attempts to connect LLMs with external tools relied on be- spoke, ad hoc solutions such as proprietary function-calling mecha- nisms and custom API integrations [8,9]. These proved that models could call external functions but created significant and unsustain- able friction for developers, since every new tool or data source required custom integration code that tightly coupled the tool to a specific model or host application [6]. A more scalable approach is to let agents communicate with tools and data sources through a shared protocol. The Model Context Protocol is the most visible effort in this direction. It defines how an application with an embed- ded model discovers capabilities and invokes them through a simple client–server design, allowing any compliant client to discover and call any compliant server through a consistent interface [3]. However, we still lack a clear, code grounded picture of how this protocol is implemented at scale. Public documentation and vendor posts explain the protocol and its goals, but they do not show which concrete design choices developers make in repositories, how those implementations evolve over time, or what evidence links a listed project to a working client or server. Early empirical work confirms why this gap matters. Hasan et al. [4] analyze 1,899 servers and re- port protocol specific vulnerabilities and maintainability concerns using static analysis and an MCP focused scanner, which under- scores the need for datasets that let researchers connect ecosystem level claims to the actual code that developers publish. To date, the main attempts to map the ecosystem at scale rely on registry or marketplace listings rather than on repository centric verification. Lin et al. [5] introduce MCPCorpus by starting from MCP.so and then enriching entries with GitHub level signals such as stars, forks, contributors, and last commit time. This market centered efforts are valuable for ecosystem measurement, yet they do not provide a repository first and verifiable ground truth of MCP implementations that is built from code evidence in the repositories themselves. In this paper, we construct a large scale repository centered dataset of MCP implementations collected directly from GitHub. Our pipeline discovers candidate repositories with the GitHub REST and GraphQL APIs, then applies multi stage, evidence based verifi- cation to confirm that each project is a working server, client, or gateway. The verification uses tangible code level signals, includ- ing dependency fingerprints from package manifests and protocol specific file layouts, and it records these signals as evidence for each entry. A manual review over a representative sample confirms the precision of the pipeline, which supports reproducibility and transparent curation. The final dataset contains 2,297 validated arXiv:2607.10123v1 [cs.SE] 11 Jul 2026 MSR ’26, April 13–14, 2026, Rio de Janeiro, BrazilBenny Toeppe, Amine Barrak, and Emna Ksontini projects out of 3,238 discovered candidates, organized in a repro- ducible JSONL schema. Beyond point in time metadata, we also collect change history to support evolution studies, including com- mit records and pull requests that modify MCP related files and configuration paths. The complete dataset, including implementation evidence, clas- sification outputs, and code, is publicly accessible at [1]. 2 Dataset Construction Figure 1 summarizes our dataset construction pipeline. We began with 3,238 public repositories referencing the Model Context Proto- col (MCP). After removing stale and documentation-only reposi- tories, 3,058 remained. Our verification pipeline confirmed MCP- related code artifacts in 2,387 repositories. A final refinement step based on manual validation removed 90 non-operational projects, resulting in 2,297 verified MCP implementations. Figure 1: Flow of dataset construction from initial GitHub results to the final verified MCP implementations. 2.1 Initial Repository Discovery We collected candidate repositories directly from GitHub using the REST Search API combined with GraphQL metadata retrieval. To ensure relevance to the emergence of MCP-driven agentic work- flows, we limited the dataset to repositories created or updated between January 2024 and October 2025. We designed five search queries to capture both broad references to MCP and more specific implementation contexts. Two queries targeted explicit references to the protocol, while three focused on contexts where MCP usage is strongly associated with implemen- tation, such as Claude Desktop integrations and server or client role naming. Table 1 summarizes the total results returned from GitHub and the number retained after filtering for duplicates, false positives, and archived projects. Table 1: GitHub search queries and resulting repository Query Total repositories (response) Total repositories (Kept) "MCP" in:name,readme,description3,1482,379 "mcp server" in:name,readme,description2,4101,999 "Model Context Protocol" in:name,readme,description1,8151,521 "Claude Desktop" MCP in:name,readme,description1,093979 "mcp client" in:name,readme,description800743 After merging overlapping results across queries and removing duplicates, we obtained 3,238 unique repositories. 2.2 Filtering for Active Maintenance To ensure that the dataset reflects active MCP development rather than abandoned prototypes or documentation, we applied the fol- lowing filters: •Repositories with no commits within the last nine months were removed. •Repositories consisting solely of documentation, tutorials, or announcement stubs were removed. • Forks without modification beyond the upstream version were excluded. This resulted in a refined candidate set of 3,058 repositories. 2.3 Multi-Stage Verification Pipeline We applied a verification pipeline designed to detect operational MCP implementations. Each repository was examined across three evidence layers: 2.3.1 Manifest and Dependency Evidence. We searched ecosystem- specific manifest and lock files to identify MCP-related dependen- cies, including: •JavaScript:package.json,package-lock.json,yarn.lock • Python: pyproject.toml, Pipfile.lock, poetry.lock • Rust, Go, PHP: Cargo.toml, go.mod, composer.json Common dependency indicators included:mcp/sdk,fastmcp, mcp, and mcp-client. 2.3.2 Directory Structure and Entry Points. Because manifests alone do not ensure operational implementation, we analyzed: • Directory patterns such as/src/mcp/, /cmd/mcp/, and /bin/mcp- server.js •Executable entry points configured via script definitions (e.g., "mcp:run", mcp-server, [project.scripts]) Repositories exhibiting MCP entry points were marked as exe- cutable MCP systems. 2.3.3 Integration and Environment Evidence. We inspected deploy- ment environments via: • CI/CD workflows (e.g., .github/workflows) • Containerization files (e.g., Dockerfile, docker-compose) • Claude Desktop configuration files (e.g., config.json) This step identified 660 repositories with no operational MCP artifacts, which were removed, along with 11 incomplete implemen- tation scaffolds. This resulted in 2,387 verified MCP repositories. 2.4 Manual Validation and Rule Refinement To evaluate the automated verification stage, two authors inde- pendently reviewed the 170-repository subset, which was selected at the 95% confidence level with an estimated margin of error of ±7–8%. Each author examined whether the project implemented MCP by inspecting configuration files, dependency declarations, and entry-point code. Disagreements were resolved through dis- cussion to reach a final consensus, reducing individual bias. This validation revealed several recurring sources of false positives: •Repositories using"MCP"to refer to unrelated systems (e.g., Minecraft Coder Pack). A Large-Scale Dataset of MCP Implementations on GitHubMSR ’26, April 13–14, 2026, Rio de Janeiro, Brazil •Reference-only mentions of MCP without executable server or client code. • Template repositories with placeholder code and no func- tional implementation. The manual assessment between the two authors found that 83.0% of the reviewed repositories represented genuine MCP im- plementations, while 12.0% were false positives and 5.0% were false negatives. Most errors stemmed from language-specific file con- ventions or incomplete dependency manifests. Extrapolating these proportions to the initial set of 2,387 automatically verified reposi- tories yields a Wilson confidence interval of [79.0%, 87.0%] at the 95% confidence level. We refined the filtering rules based on these findings, removing 90 additional false matches and producing a final dataset of 2,297 verified MCP implementations. 3 Dataset Contents and Characteristics This section outlines the 2,297 verified MCP repositories, the op- erational roles they implement, how roles interact, and how role assignments and metadata were derived. 3.1 Role-Based MCP Execution Model The Model Context Protocol defines how agents invoke external tools through a structured request-response workflow. In practice, implementations of MCP adopt one of three primary operational roles that correspond to different points in the execution chain. Figure 2 illustrates the interaction pattern among these roles. • Client: initiates connections to MCP servers and consumes their tools, resources, or prompts. Typical examples include user-facing interfaces such as Claude Desktop integrations. •Server: Exposes MCP-compatible tools, resources, or prompts that Clients can invoke. Servers implement the logic for com- putation, retrieval, transformation, or control when handling client requests. •Gateway: Mediates MCP traffic between components or external ecosystems. Gateways translate, route, or relay re- quests, often bridging MCP with APIs. MCP Clients(one per connected MCP Server) Client 0Client 1Client 2 MCP Host (Application) Claude Desktop Chat interface IDE plugin MCP Servers/GatewaysProvide context Server A • Tools • Resources • Prompts Server B • Tools • Resources • Prompts Gateway C • Tools • Resources • Prompts External Services / APIs (DB, Git, Search, Weather, etc.) Init JSON-RPC 2.0 Tool Call Figure 2: MCP architecture showing the host, clients, and servers/gateways exposing tools and resources. 3.2 Role Classification Rules Each verified repository was assigned a primary operational role based on source-level evidence. The role classification used a rule- based scoring system combining manifest signals, entry-point pat- terns, and semantic cues from metadata and documentation, result- ing in one of three roles: Client, Server, or Gateway. Rule-Based Scoring System. Three independent score variables were computed for each repository:푆 푐 (client score),푆 푠 (server score), and푆 푔 (gateway score). Signals were drawn from repository meta- data, directory structure, source paths, dependency manifests, and commit-level evidence. •Client signals: Use of MCP client libraries and explicit tool invocation (e.g.,connect(),invoke(),use_tool(), paths such as@mcp/sdk/client), including editor plugin contexts (e.g., vscode, cursor, claude_desktop). • Server signals: Registration and exposure of MCP tools or capabilities, indicated by directories like/tools/or /re- sources/, manifest references to@mcp/sdkorfastmcp, and server entrypoints such asserver.py,server.ts, or mcp- server binaries. •Gateway signals: Logic forwarding MCP requests across systems, indicated by terms such asgateway,router,relay, orproxy, and bridges to external APIs or services. Observed patterns fall into six subtypes: transport relay, language bridge, authentication policy, orchestration, sandbox iso- lation, and discovery/registry. Each match contributed to a numeric score based on indicator strength (strong = 2 points, weak = 1 point), where strong sig- nals derived from source and manifest files and weak signals from README/metadata text. Decision Logic. The final role was determined based on the com- parative magnitude of the three scores: (1) If푆 푐 ≥ 3 and푆 푠 ≤ 1, classify as Client. (2) If푆 푠 ≥ 3 and푆 푐 ≤ 1, classify as Server. (3) If푆 푔 ≥ 4 and both푆 푐 and푆 푠 < 2, classify as Gateway. A client override rule was applied to prevent misclassification of editor extensions and IDE integrations that contain inciden- tal routing logic. If gateway-scored repositories contained editor signals (e.g.,vscode,cursor,claude_desktop), the final classifi- cation was reassigned to Client. Manual Disambiguation . Repositories where the scoring system did not yield a clear dominant role (e.g., when|푆 푐 −푆 푠 | ≤1 or when all three scores were below threshold) were marked as low confidence. These repositories were reviewed manually to determine whether they primarily issued tool requests, exposed tools, or mediated between systems. If a dominant operational role could not be iden- tified after inspection, the repository was labeled as Unclassified. Applying these rules resulted in 1,962 Servers, 1,462 Clients, and 80 Gateways. Some repositories exhibited both client and server behavior and were assigned to both roles, while 36 could not be assigned a dominant role and were marked as Unclassified. Among the 80 Gateways, orchestration gateways were the most common (n=47), followed by language bridges (n=22). Transport relays (n=6) and authentication policy gateways (n=5) appeared less MSR ’26, April 13–14, 2026, Rio de Janeiro, BrazilBenny Toeppe, Amine Barrak, and Emna Ksontini Figure 3: Dataset Schema and Entity Relationships for the MCP Repository Dataset frequently, with sandboxing (n=2) and discovery/registry gateways (n=1) being rare. The 36 Unclassified repositories were mostly lightweight or in- complete projects, including agent adapters (n=13), chat UI inte- grations (n=5), documentation or specification scaffolds (n=4), SDK utilities and CLI tooling (n=6), small demo or benchmark artifacts (n=4), and unstructured repositories (n=4). 3.3 Language Characteristics by Role We examined the primary implementation language of each reposi- tory after role classification. Table 2 presents the top three languages for each role, ranked by number of repositories. Table 2: Top 3 Languages per MCP Role RankServerClientGateway 1Python (785)Python (530)TypeScript (25) 2TypeScript (597)TypeScript (492)Python (22) 3JavaScript (177)JavaScript (137)Go (17) Python and TypeScript dominate both server and client imple- mentations. JavaScript appears in smaller client- and server-side projects and examples. Gateways show a distinct profile, with Go appearing as a third major language. 3.4 Dataset Schema and Repository Metadata Figure 3 shows the schema used to store the verified MCP reposito- ries and their metadata. The dataset centers on a core repository index, with auxiliary tables for language composition, role classifi- cation, evidence signals, and pull request activity. Repository Core and Verification Evidence. The dataset centers on theTRUE_MCP_REPOStable, which lists the 2,297 verified reposito- ries. Each repository is linked to: • CORE_REPO_DATA, containing metadata such as creation date, last push timestamp, and star count. • EVIDENCE_SUMMARY, which records the types of signals that contributed to verification (manifest, entry points, directory patterns, etc.) along with evidence strength scores. • REPO_TYPE, which defines the repository’s assigned role (Client, Server, Gateway), subtype where applicable, and supporting evidence. Commit-Level Activity. Development history is stored in theCOMMITS table, which records commit messages, author identity, and code change size. Across all verified repositories, we observe: • Median commits per repository: 70 • Median commit message length: 38 characters • Median additions per commit: 19 lines • Median deletions per commit: 4 lines • Median changed files per commit: 2 files • Median number of unique contributors per repository: 4 • Median repository stars: 156 • Median forks per repository: 27 • Median open issues per repository: 3 • Median number of published releases: 1 These patterns suggest iterative, small-step development styles rather than large batch updates. Pull Request Structure and Collaboration. Pull request metadata is stored in thePULL_REQUESTStable, with aggregate summaries in REPO_PR_SUMMARY. We track counts of merged PRs, review patterns, and author involvement. At the dataset level, we observe: •Most MCP servers and clients are maintained by small teams (2–5 active contributors). •Gateway repositories show higher PR activity, with an average of 49.6 pull requests per repository, compared to 33.7 for clients and 29.9 for servers. A Large-Scale Dataset of MCP Implementations on GitHubMSR ’26, April 13–14, 2026, Rio de Janeiro, Brazil 4 Conclusion We constructed a dataset of 2,297 verified MCP repositories using a multi-stage discovery and verification process based on source-level evidence. The dataset records role assignments, evidence indicators, language composition, and development activity in a structured format. Python and TypeScript are the most common languages in both client and server implementations, while gateways addi- tionally use Go. Several repositories include both client and server functionality within the same codebase. The dataset is intended to support reproducible analysis of MCP implementation practices, with future work focusing on updating the dataset over time and refining role and subtype classifications. References [1]anonymous. 2025. Verified MCP Implementations Dataset. doi:10.5281/zenodo. 17573071 [2]Amine Barrak. 2025. Traceability and Accountability in Role-Specialized Multi- Agent LLM Pipelines. In Proceedings of the MAS-GAIN Workshop at the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE. [3]Mohamed Amine Ferrag, Norbert Tihanyi, and Merouane Debbah. 2025. From llm reasoning to autonomous ai agents: A comprehensive review. arXiv preprint arXiv:2504.19678 (2025). [4]Mohammed Mehedi Hasan, Hao Li, Emad Fallahzadeh, Gopi Krishnan Rajbahadur, Bram Adams, and Ahmed E Hassan. 2025. Model context protocol (mcp) at first glance: Studying the security and maintainability of mcp servers. arXiv preprint arXiv:2506.13538 (2025). [5] Zhiwei Lin, Bonan Ruan, Jiahao Liu, and Weibo Zhao. 2025. A Large-Scale Evolv- able Dataset for Model Context Protocol Ecosystem and Security Analysis. arXiv preprint arXiv:2506.23474 (2025). [6]Meriem Mastouri, Emna Ksontini, and Wael Kessentini. 2025. Making rest apis agent-ready: From openapi to mcp servers for tool-augmented llms. arXiv preprint arXiv:2507.16044 (2025). [7]Salvatore Raieli and Gabriele Iuculano. 2025. Building AI Agents with LLMs, RAG, and Knowledge Graphs: A practical guide to autonomous and modern AI agents. Packt Publishing Ltd. [8] Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. Toolformer: Language models can teach themselves to use tools. Advances in Neural Information Processing Systems 36 (2023), 68539–68551. [9] Qiaoyu Tang, Ziliang Deng, Hongyu Lin, Xianpei Han, Qiao Liang, Boxi Cao, and Le Sun. 2023. Toolalpaca: Generalized tool learning for language models with 3000 simulated cases. arXiv preprint arXiv:2306.05301 (2023).