MCP-Eco: A Linked Dataset of MCP Servers, Consumers, and Development Activity

MCP-Eco: A Linked Dataset of MCP Servers, Consumers, and Development Activity Khalid Tounoussi∗ , Mohammed Sayagh∗ , Ali Ouni∗ , Yutaro Kashiwa‡ ∗ ÉTS Montréal, University of Quebec, Montreal, Canada

arXiv:2611.06897v1 [cs.SE] 4 Nov 2026

khalid.tounoussi.1@ens.etsmtl.ca, {mohammed.sayagh, ali.ouni}@etsmtl.ca ‡ Nara Institute of Science and Technology (NAIST), Nara, Japan yutaro.kashiwa@is.naist.jp

Abstract—The Model Context Protocol (MCP) enables LLM agents to access external tools and data. Studying its software ecosystem requires connecting server interfaces, the projects that configure these servers, and their development activity. However, this information is scattered across directories, package registries, configuration files, and repository histories. We present MCP-Eco, a relational dataset that integrates these sources and links consumer configuration declarations to candidate server projects. Its frozen release contains 16,880,899 records across 19 Parquet tables, covering 78,302 candidate server projects, 16,165 candidate consuming repositories, and 9,200 configuration declarations. Of these declarations, 5,975 resolve to 5,138 distinct repository–server pairs. The dataset also includes tool, resource, and prompt descriptions, declared dependencies, and associated development records, including pull requests, reviews, issues, and commits. Provenance fields distinguish directory-reported capabilities from those observed through live probing and document discovery sources and declaration-matching methods. These connections support research on MCP interface design, configuration practices, and repository maintenance, while enabling practitioners to inspect tool schemas and existing integration configurations. The dataset and accompanying analysis scripts are publicly available at https://huggingface.co/datasets/ mcp-research-alliance/mcp-ecosystem Demonstration video: https://www.youtube.com/watch?v= N7TqnNneSfU Index Terms—Model Context Protocol, MCP, LLM, AI coding agents, software ecosystem, mining software repositories, dataset

I. I NTRODUCTION Large language model (LLM) agents act through external tools: they read files, query services, and change their environment. The Model Context Protocol (MCP), introduced by Anthropic in November 2024 [1], standardizes how agents discover and invoke such tools [2]. An MCP server exposes tools that perform actions, resources that provide data, and prompts that supply reusable instructions. A project that wants to use a server declares it in a configuration file, which an agent host such as Claude Desktop or Cursor reads at runtime to connect to each listed server. The ecosystem therefore has two sides: the projects that implement servers and the projects that consume them. Both sides are software engineering subjects. A server is an ordinary software project with interface design, documentation, dependency, and maintenance concerns, with one difference: an LLM selects among its tools by reading natural-

language descriptions and input schemas, so description quality can change agent behavior [3]. A consuming project’s configuration records which servers its developers chose and how they launch them. Both sides receive contributions from coding agents such as Claude Code and Copilot. Several studies and datasets have begun to describe the ecosystem. Hasan et al. conducted the first large-scale empirical study of MCP servers, examining the health, security, and maintainability of 1,899 servers [4], and later identified quality smells in tool descriptions [3]. MCPCorpus [5] collects about 14,000 servers and 300 clients with normalized GitHub metadata. MCPZoo [6] targets runnability, packaging servers so that they can be launched and queried. Guo et al. [7] measure 8,060 servers and 341 clients. These resources share three limits. First, their client side consists of host and client implementations, which speak the protocol, rather than the projects that adopt servers through configuration, so none links a server to the repositories that declare it. Second, they capture repository metadata at one point in time but not the pull requests, reviews, issues, and commits through which servers and adopters change. Third, where capability lists are provided, each comes from one channel, either a directory listing or a probe, so advertised and observed interfaces cannot be compared within one resource. We propose MCP-Eco, a dataset that links candidate server projects to consuming repositories through parsed configuration declarations. On the server side, it contains 78,302 candidate server projects discovered through five directories, six package registries, and code search, with their 65,233 registry listings, 45,272 launch commands and endpoints, and 662,693 declared dependencies. Their capabilities are stored as 284,845 tool, 20,795 resource, and 8,983 prompt records, each tagged as observed by live probing or retrieved from the Glama directory. On the consumer side, it contains 16,165 candidate consuming repositories with 45,529 discovery signals and 9,200 parsed configuration declarations that link repositories to the servers they declare, with the match method recorded for each resolved link. From the associated repositories, it adds 1.73M pull requests, 620K reviews, 301K review comments, 991K issues, 2.07M issue comments, and 9.34M commits, including consumer-side pull requests matched to coding-agent signatures. Every capability, signal, and declaration keeps its source and match method, so a user can restrict an analysis

Capability observations Public sources directories, package registries, code search, GitHub API

Normalized candidate records servers by repository URL, consuming repositories

tagged probe or glama

Configuration parsing

Joins that retain provenance source, signal, and match method kept

Researcher query SQL with explicit units over local Parquet files

declaration rows, nullable server_id

Fig. 1. How MCP-Eco is built and used, from public sources to queries with explicit counting units.

to probed rows, compare directory claims with observed behavior, or audit a single link. Table I summarizes the release. II. DATA C OLLECTION A Python crawler collected the data in PostgreSQL and exported the release to Parquet on 2026-06-23 (UTC). Fig. 1 summarizes the collection pipeline. Stage 1: Discovering candidate servers. Candidates come from three channels. (1) Directories. The crawler queries the APIs of the official MCP registry, Glama, Smithery, PulseMCP. For MCP.so, it reads server listing pages found through sitemaps. It collects server names, description, repository URL, package identifiers, and transport details where available. Each Candidate’s directory listing is recorded in server_registry_listings. (2) Package registries. The crawler searches npm keywords for mcp, mcp-server, and model-context-protocol, and runs a freetext search for mcp-server. It queries the search APIs of NuGet, crates.io, and Maven Central with mcp. For PyPI, it filters package names for MCP patterns. For Docker Hub, it lists images in the mcp/ namespace. Repository URLs are extracted from package metadata where available. (3) Code search. GitHub queries look for mcpName in server.json and startCommand or runtime in smithery.yaml. These fields indicate how a server is published or launched. Sourcegraph queries also look for server SDK imports and implementation patterns across languages. Repository URLs are normalized and deduplicated. Repository URLs are normalized by removing trailing slashes and .git suffixes. Candidates with the same normalized URL are merged into one mcp_servers row. The discovery_ source field records the channels that found each candidate. The frozen release contains 78,302 candidate records. Available star counts reflect discovery-time metadata. Package identifiers and connection endpoints are stored in mcp_ server_transports. For GitHub repositories, the crawler fetches dependency files from the repository root through the GitHub Contents API. These include package.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, and pom.xml. Declared dependencies are stored in server_ dependencies, together with their version constraints, dependency types, ecosystems, and file paths. Stage 2: Observing capabilities. Tools, resources, and prompts are stored as observations with a source column, and uniqueness is enforced per source, so the same capability can appear once as advertised and once as observed. Rows

with source=glama copy the lists published by the Glama directory, fetched through each server’s capability page (the /schema subpage of its listing). Rows with source=probe come from live probing. For each candidate with a transport record, the prober chose one transport and preferred a remote endpoint over stdio. Remote endpoints were contacted directly over streamable HTTP or SSE. After a successful initialize handshake, the prober requests tools/list, resources/list, and prompts/list. Tool records retain input JSON schemas where available. Resource records retain URIs, MIME types, and descriptions. Prompt records retain descriptions and argument metadata. Missing records can reflect skipped probes, connection failures, or failed listing requests. They do not establish that a server exposes no capabilities. Stage 3: Discovering consuming repositories. GitHub code search is queried for mcpServers in configuration files such as claude_desktop_config.json, mcp.json, and cline_mcp_settings.json, and under .cursor/. Sourcegraph also searches for client SDK imports and framework adapters such as from mcp import ClientSession and MultiServerMCPClient, alongside dependency, transport, and infrastructure patterns. Every hit is stored in repo_discovery_signals with its category (host configuration, client code, framework adapter, or manifest dependency), the matched path, and the pattern. The 45,529 signals cover 16,165 repositories. The consumer_type label summarizes the evidence. Parsed declarations or host-configuration signals yield ai_user. Client-code or framework-adapter signals yield ai_builder. Both kinds yield both. Ambiguous evidence yields sdk_unconfirmed, while insufficient evidence yields unknown. Server candidates with consumer evidence are retained and marked is_also_server. Stage 4: Parsing and matching declarations. For each consuming repository, the crawler requested twelve fixed configuration paths, such as .mcp.json and .cursor/mcp.json, from the default branch at fetch time. It parsed the mcpServers object of each JSON file found. Each entry becomes one repo_ server_usage row, unique by repository, raw server name, and file path. The row keeps the command, the arguments, and a client type derived from the path. This produced 9,200 rows. Each row is then matched to a candidate server using package identifiers, endpoint URLs, or server names. Of the 9,200 rows, 5,975 matched, giving 5,138 distinct repository-

server pairs. Resolved declarations receive a server_id, with the matching rule recorded in match_method. Unresolved declarations keep a null server_id. Stage 5: Harvesting development records. Development records were collected from GitHub-hosted server candidates and consuming repositories through the GitHub REST API, using Perceval [8]. On the server side, we collected pull requests, issues, and comments through the GitHub REST API, keeping items updated since the MCP launch on 202411-25. It targeted the 13,966 GitHub-hosted candidates with at least ten stars at discovery. Reviews and review comments were fetched only for a sample of servers: those declared in a configuration on the consumer side, those Glama marks as official, and a deterministic sample of candidates with stored pull requests. On the consumer side, we collected issues since the MCP launch date for all 16,165 repositories. Coding-agent signatures follow Li et al. [9], with Jules and Codegen added. The matched signature is stored in relevance_signal. Commits were extracted from servers and consuming repositories. We used PyDriller [10] to extract insertions, deletions, and files changed. Commits are keyed globally by commit_hash, retain the first recorded repository URL, and store author dates. Issues, pull requests, reviews, and comments carry bot flags based on GitHub account type Bot. In total, 22,750 repositories have at least one development record. Export. On 2026-06-23 every table was exported from PostgreSQL to one Parquet file. schema.sql records the schema and constraints. III. DATASET AND ACCESS Data model. Table I groups the 19 tables into four blocks. Server-side tables are linked through server_id, consumerside tables off repo_id, and repo_server_usage bridges the two with a nullable server_id. Development tables are keyed by pr_id, issue_id, and commit_hash and point back to a server or a repository. Four provenance columns travel with the data: discovery_source on candidates, source (probe or glama) on capability rows, match_method on declarations, and relevance_signal on consumer pull requests, plus a bot flag on authors. Access. The Hugging Face dataset page provides public access under CC BY 4.0: one Parquet file per table under parquet/, the PostgreSQL schema in schema.sql, and collection_ metadata.json with the crawler version, and per-table counts. Analyses should pin the frozen revision shown in Listing 1. Companion code on GitHub1 downloads and verifies the pinned files and reruns both examples below. Example for a software engineer. Listing 1 shows an engineer who wants a coding assistant to inspect a GitHub issue, read the relevant source files, and prepare a pull request. MCP-Eco records the reference GitHub server’s probed get_issue, get_file_contents, and create_pull_request 1 https://github.com/khalid-tounoussi-1/mcp-eco-artifact

TABLE I I NVENTORY OF 16,880,899 STORED RECORDS ACROSS 19 TABLES , WITH IDENTIFIERS FOR JOINING RELATED RECORDS . Table

Records Main keys

Server candidates and capabilities mcp_registries 7 registry_id mcp_servers 78,302 server_id server_registry_listings 65,233 server_id, registry_id mcp_server_transports 45,272 server_id mcp_tools 284,845 server_id, source mcp_resources 20,795 server_id, source mcp_prompts 8,983 server_id, source server_dependencies 662,693 server_id Consuming repositories consumer_repos repo_discovery_signals Configuration declarations repo_server_usage

16,165 repo_id 45,529 repo_id 9,200 repo_id, server_id (nullable)

Associated development activity commits 9,336,613 commit_hash, repository_url server_pull_requests 1,610,439 pr_id, server_id client_pull_requests 121,161 pr_id, repo_id pr_reviews 620,151 review_id, pr_id pr_review_comments 300,883 review_id, pr_id pr_commit_bridge 597,344 pr_id, commit_hash ecosystem_issues 991,441 issue_id, server_id or repo_id issue_comments 2,065,843 issue_id Total

16,880,899

Listing 1. GitHub MCP server tool schemas and a linked project configuration. 1 SELECT t.tool_name, t.input_json_schema, 2 c.repository_url, u.config_file_path, 3 u.raw_command, u.raw_args, u.match_method 4 FROM mcp_tools t 5 JOIN repo_server_usage u USING (server_id) 6 JOIN consumer_repos c USING (repo_id) 7 WHERE t.server_id IN ( 8 SELECT server_id FROM mcp_server_transports 9 WHERE package_identifier = 10 '@modelcontextprotocol/server-github') 11 AND t.source = 'probe' 12 AND t.tool_name IN ('get_issue', 13 'get_file_contents', 'create_pull_request') 14 AND u.match_method IN ('package', 'package_ver') 15 AND lower(c.repository_url) = 16 'https://github.com/redis/redisinsight' 17 AND u.config_file_path = 'mcp.json' 18 ORDER BY t.tool_name

tools in mcp_tools. Their stored schemas describe the required inputs. Following server_id to repo_server_usage leads to setup examples, including RedisInsight’s mcp.json declaration of @modelcontextprotocol/server-github. The dataset therefore helps the engineer inspect tool interfaces and consult an existing configuration when planning this workflow. Example for a researcher. A researcher studies how MCP tools support paper-retrieval workflows. They start with the

arXiv server’s recorded search_papers, download_paper, and read_paper tools. Following server_id to ecosystem_issues reveals a historical report describing how asynchronous conversion interrupted the transition from downloading a paper to reading it. MCP-Eco brings the tool interfaces and developer report together, providing a concrete case for studying coordination between tools.

Ethics and redistribution. Records come from public registries, public code search, and public repositories, and the release metadata records scrub_pii=false, so commit author emails, GitHub identities, and public issue and pull request text are present in the data. Users should not use the data to profile individuals. The CC BY 4.0 license covers this release and does not relicense third-party content.

IV. R ESEARCH O PPORTUNITIES

VI. C ONCLUSION MCP-Eco provides a public relational dataset connecting candidate Model Context Protocol server projects, their capabilities, consumer configuration declarations, and repository development records. By bringing these sources together, it enables researchers to examine interface design, configuration practices, and maintenance across the MCP ecosystem. Practitioners can inspect recorded tool schemas and consult existing configurations when planning integrations. To use the dataset, researchers can start from a server, capability, or consuming repository and follow the recorded links to construct a study-specific subset. Capability sources and declaration-matching methods support explicit filtering, while the accompanying schema and analysis scripts provide a starting point for reproducible queries. Analyses should distinguish configured connections from runtime use and account for collection coverage and matching uncertainty. Future releases will prioritize validating server–consumer links, improving entity resolution, and preserving versioned capability observations to support studies of ecosystem evolution.

Capability interface design. Tool, resource, and prompt records support studies of how MCP capabilities are named, structured, and documented. Researchers can examine tool input schemas, resource URIs and MIME types, and prompt arguments alongside their descriptions to investigate interface and documentation quality. Configuration practice. The 9,200 declarations record which servers projects declare, in which host files, with which launch commands, and in which combinations. Questions include which servers are co-declared, how often packages are versionpinned, and how declarations split between local launches and remote endpoints. Maintenance and adoption. Linked configuration and development records enable studies of the relationship between declared server integration and repository maintenance. Researchers can examine whether servers declared by more repositories exhibit different pull-request acceptance rates, merge times, or issue-response patterns. Such analyses must account for collection coverage and distinguish repositorywide activity from MCP-specific changes. Coding-agent contributions. Agentic consumer pull requests support studies of observed coding-agent activity, including acceptance outcomes and review effort in MCP projects. V. L IMITATIONS , VALIDATION S TATUS , AND E THICS Coverage. MCP-Eco is a snapshot of a changing ecosystem, bounded by the sources queried and their search limits. Record counts describe this release, not the MCP population. Probing covers only candidates that could be launched or reached without credentials or local setup, and directory metadata can be stale. Declaration counts measure configured linkage, not runtime use. Consumer-side pull requests include only those matched to an agent signature, so they describe agent activity but not its share of all contributions. Reliability. Candidate servers can include false positives and monorepos with several implementations, and consumer labels rest on code-search signals. The token-based matching rule can resolve a bare argument to the wrong candidate (Section III), and can hide real links. Validation status. We verified file integrity against the pinned release, reproduced the reported table counts, and checked schema constraints against the crawler implementation. These checks establish consistency of the exported artifact but do not measure the semantic accuracy of its contents. The precision of server discovery, consumer classification, and declaration matching remains to be evaluated.

R EFERENCES [1] Anthropic, “Introducing the model context protocol,” https://www. anthropic.com/news/model-context-protocol, Nov. 2024, accessed June 2026. [2] X. Hou, Y. Zhao, S. Wang, and H. Wang, “Model context protocol (MCP): Landscape, security threats, and future research directions,” arXiv preprint arXiv:2503.23278, 2025. [3] M. M. Hasan, H. Li, G. K. Rajbahadur, B. Adams, and A. E. Hassan, “Model context protocol (MCP) tool descriptions are smelly! Towards improving AI agent efficiency with augmented MCP tool descriptions,” arXiv preprint arXiv:2602.14878, 2026. [4] M. M. Hasan, H. Li, E. Fallahzadeh, G. K. Rajbahadur, B. Adams, and A. E. Hassan, “Model context protocol (MCP) at first glance: Studying the security and maintainability of MCP servers,” arXiv preprint arXiv:2506.13538, 2025. [5] Z. Lin, B. Ruan, J. Liu, and W. Zhao, “A large-scale evolvable dataset for model context protocol ecosystem and security analysis,” arXiv preprint arXiv:2506.23474, 2025. [6] M. Wu, P. Chen, G. Hong, B. An, J. Chen, B. Wan, X. Pan, J. Dai, and M. Yang, “MCPZoo: A large-scale dataset of runnable model context protocol servers for AI agent,” arXiv preprint arXiv:2512.15144, 2025. [7] H. Guo, Y. Hao, Y. Zhang, M. Xu, P. Lv, J. Chen, and X. Cheng, “A measurement study of model context protocol ecosystem,” arXiv preprint arXiv:2509.25292, 2025. [8] S. Dueñas, V. Cosentino, G. Robles, and J. M. Gonzalez-Barahona, “Perceval: Software project data at your will,” in Proceedings of the 40th International Conference on Software Engineering: Companion Proceedings, 2018. [9] H. Li, H. Zhang, and A. E. Hassan, “The rise of AI teammates in software engineering (SE) 3.0: How autonomous coding agents are reshaping software engineering,” arXiv preprint arXiv:2507.15003, 2025. [10] D. Spadini, M. Aniche, and A. Bacchelli, “PyDriller: Python framework for mining software repositories,” in Proceedings of the 26th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2018.

Related documents

• Know the Shape, Find the Fault: Topology-Conditioned Diagnosis of Multi-Agent LLM Failures#1234493
• Correction: Context is key for cybersecurity: leveraging external knowledge for process model explanation via LLMs#667025
• Corporate Language Model (CLM): Transforming Tacit and Fragmented Enterprise Knowledge into a Sovereign, Auditable, and Executable Corporate Intelligence Layer#927671
• A flexible language model-assisted electronic design automation framework#1386982
• Benign Alone, Harmful Together: Exploiting Experience Composition in Self-Evolving LLM Agents#423847