arXiv:2607.25635v2 [cs.SE] 29 Jul 2026
An Empirical Study of Model Context Protocol Applications Muhammad Hamza Arshad Majeed
May Mahmoud
Sarah Nadi
New York University Abu Dhabi Abu Dhabi, United Arab Emirates [email protected]
New York University Abu Dhabi Abu Dhabi, United Arab Emirates [email protected]
New York University Abu Dhabi Abu Dhabi, United Arab Emirates [email protected]
Abstract—The Model Context Protocol (MCP) standardizes how large language model applications communicate with external tools, but leaves the application side unspecified: unlike traditional dependencies resolved through package managers, developers integrating MCP servers face no conventions for configuration, communication, or human oversight. This ecosystem is also under-researched, with existing work focused on servers rather than the applications consuming them. We conduct a large-scale study of 1,723 MCPApps mined from GitHub. We first derive MCPAppTax from a representative sample, then use an LLM-assisted pipeline to apply it across the full dataset, characterizing server integration across configuration, SDK use, and human-in-the-loop mechanisms. Our results show that the ecosystem has converged on some practices but not others: most MCPApps configure servers using files (85.2%) and use an official SDK (81.1%) to communicate with servers, yet no naming convention has emerged for configuration files. Human oversight diverges most, logging (90.8%) and enable/disable controls (77.2%) are common, but only 37.2% gate tool execution behind a blocking approval step, leaving the LLM able to invoke any enabled tool unconditionally in most MCPApps.
I. I NTRODUCTION The Model Context Protocol (MCP) is an open standard introduced by Anthropic in late 2024 [1] to standardize how Aritificial Intelligence (AI) systems, specifically those powered by large language models (LLMs), connect to external tools, data sources, and services. LLMs are fundamentally constrained by their static training data and limited context window [2]. Giving LLMs access to external tools such as databases, search engines, and web services extends their capabilities by supplying real-time context and executable functionality. MCP defines a universal interface: rather than every AI application writing custom integration code for every external tool it uses, MCP lets both sides implement a single shared protocol. Architecturally, MCP defines a clientserver protocol that decouples the AI application from external resources, assigning distinct roles to the MCP host, client, and server. An MCP server wraps an external service and exposes its functionality through a standardized schema; an MCP host is an AI application that consumes one or more such servers through embedded MCP clients. In this paper, we focus on MCP hosts, which we hereafter refer to as MCP-enabled AI applications, or MCPApp for short. In essence, MCP turns an MCP server into a dependency: developers publish servers that expose resources and function-
ality, and MCPApps instantiate clients to call and consume them [1]. This mirrors how software systems reuse third-party libraries and web services whose behavior affects functionality, performance, security, and reliability. Most work on MCP focuses on the server side, such as server maintainability [3] and security [4], leaving how MCPApps integrate and configure servers in practice largely unexamined. This stands in contrast to traditional software dependencies, which have long been studied from the consuming application’s side, e.g., how applications select, configure, and update the third-party libraries they depend on [5]–[7]. By characterizing how MCPApps configure, communicate with, and oversee the MCP servers they depend on, we aim to understand how the emerging MCP ecosystem is evolving and whether it raises new challenges in dependency management. We center our study on answering the following question: How do MCPApps configure and use MCP servers as software dependencies? We decompose it into three research questions, one per integration dimension: RQ1: How do MCPApps configure the MCP servers they depend on? We characterize where and how MCPApps declare and store the servers they depend on. • RQ2: How do MCPApps manage communication with MCP servers? We study how MCPApps instantiate the MCP client and communicate with servers. • RQ3: What human-in-the-loop controls do MCPApps place on tool invocation? We examine the human oversight mechanisms MCPApps implement around tool execution. •
To answer these questions, we build MCPAppDS, a dataset of 1,723 MCPApps. From a representative sample, we derive the MCP Configuration Taxonomy (MCPAppTax), which captures variations across the dimensions we study. Using an LLM-based classification pipeline, we then label the remaining MCPApps according to MCPAppTax. Our results show that the MCP ecosystem has converged on some integration practices while remaining fragmented on others. For configuration, 85.2% of MCPApps store their server list in a file, but most use different file names. For communication, 81.1% use an official MCP SDK, while 18.9% implement the client layer themselves. Human-in-the-loop controls show the greatest divergence: 90.8% log at least part of the MCP execution
lifecycle and 77.2% maintain explicit enable/disable control over servers or tools, but only 37.2% implement a blocking approval gate before tool execution. Unlike traditional dependencies, whose declaration, resolution, and trust are mediated by package managers, MCP has no equivalent layer, leaving MCPApps to manage server dependencies through applicationspecific conventions and pointing to a need for ecosystem-level standards as MCP matures. To the best of our knowledge, this is the first large-scale study of the MCP ecosystem that focuses on MCPApps and casts a dependency lens on how they configure and use MCP servers. All scripts and data are available in our online artifact.1 II. BACKGROUND AND M OTIVATING E XAMPLES
1
1 https://figshare.com/s/1dc2ea96aca29038d99e
"mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol /server-filesystem", "/Users/alice/projects"], "env": {} } }
3 4 5
6 7 8 9 10
} Listing 1. MCP server configuration file in ChatGPTNextWeb/NextChat.
1 2
In this paper, we follow the definitions outlined by the official MCP documentation [8]. An MCP server is a program that can extend an LLM’s capabilities and provide additional context through exposing a set of tools, or prompts that can be executed, and data sources. MCP servers can execute locally or remotely. An MCP host is an AI application that connects to MCP servers through MCP clients. An MCP client is the protocol-level component of a host that enables connections to servers. Typically, each MCP server used by a host needs a corresponding MCP client to enable connections to it. While we have observed that the term MCP client is used loosely in practice to refer to the AI applications themselves as well [9], we follow the MCP documentation that clearly separates hosts (i.e., the AI application) from the low-level clients. For clarity, we refer to the MCP host/AI application as MCPApp. The canonical example of an MCPApp is Claude Desktop [1], used as the primary reference implementation by Anthropic. It can manage connections to multiple MCP servers simultaneously using MCP clients, with each client handling direct communication with a single server. MCP standardizes the protocol by which servers communicate with clients within MCPApps, including the JSON-RPC 2.0 message format, handshake and capability negotiation, as well as primitives exposed by the server (tools, prompts, and resources). MCP also standardizes the transport mechanisms (Stdio and Streamable HTTP) utilized. Accordingly, MCP SDKs are language-specific libraries that implement the full MCP specification, allowing developers to easily implement MCP servers and clients. Official MCP SDKs exist for TypeScript [10], Python [11], Java [12], Kotlin [13], C# [14], Swift [15] and Rust [16]. While MCP standardizes client-server communication, it leaves MCPApp-side architectural and operational boundaries unspecified. For example, there is no single enforced way to declare or specify the servers available to an MCPApp. Additionally, while MCP SDKs exist, developers are not forced to use them and can implement the communication and transport mechanisms themselves (as long as they adhere to the MCP specification). Finally, the MCP standard does not specify
{
2
3
// client.ts - SDK-based client construction import { Client } from "@modelcontextprotocol/sdk /client/index.js"; import { StdioClientTransport } from " @modelcontextprotocol/sdk/client/stdio.js";
4 5
6
7
const transport = new StdioClientTransport({ command, args, env }); const client = new Client({ name: "nextchat-mcpclient" }, {}); await client.connect(transport);
8 9 10
11 12
13
14
// actions.ts - ungated tool execution export async function executeMcpAction(clientId, request) { const client = clientsMap.get(clientId); logger.info(`Executing request for [${clientId }]`); return await executeRequest(client.client, request); // no approval gate } Listing 2. MCP client instantiation and ungated tool call in ChatGPTNextWeb/NextChat (adapted to shorten)
any approval or human-in-the-loop (HITL) mechanisms that should be performed before a tool from an MCP server is run. To illustrate these variances, we provide real motivating examples found from our analysis. Listing 1 shows how the MCPApp ChatGPTNextWeb/NextChat [17],reads from a JSON configuration file (mcp_config.json) to discover the list of servers to connect to, alongside their configuration parameters such as the command, arguments, or transport settings. Listing 2 shows how the application then imports the official MCP SDK client and transports, i.e., the Client and StdioClientTransport classes. Crucially, during the execution of tools on Lines 10 -14, the LLM request is routed directly to the tool call, with no human intervention to approve or deny the process; the tool call is only logged. On the other hand, daodao97/ChatMCP [18] stores its server list in two locations depending on the platform. On desktop and mobile, it reads and writes a JSON file called mcp_server.json in the application data directory, with default values bundled as an asset (assets/mcp_server.json), while on the web, it stores the list under the key mcp_servers_json in SharedPreferences (browser local storage). As shown in Listing 3,
1
2
3
4 5 6
7 8
9
// stdio_client.dart - manual JSON-RPC message construction (no SDK) Future<JSONRPCMessage> sendToolCall({required String name, required Map<String, dynamic> arguments}) async { final message = JSONRPCMessage( method: ’tools/call’, params: {’name’: name, ’arguments’: arguments }, ); return sendMessage(message); // writes raw JSON to server process }
10 11
12
13 14
15 16 17
// chat_page.dart - blocking approval gate before execution final approved = await _showFunctionApprovalDialog(event); if (approved) { await _sendToolCallAndProcessResponse(event. name, event.arguments); } else { _runFunctionEvents.clear(); // user cancelled } Listing 3. Self-managed client and approval gate in ChatMCP.
the client is implemented entirely by the application itself rather than using the official MCP SDK: On Lines 1-7, StdioClient constructs raw JSON-RPC 2.0 tools/call messages manually and writes them directly to the server process. ChatMCP also provides both per-server and pertool enabling toggles. Furthermore, as shown in Listing 3 Lines 12-17, ChatMCP implements a dedicated human-inthe-loop flow in _showFunctionApprovalDialog(), where it displays a non-dismissible AlertDialog before tool execution, which the user must explicitly allow or cancel. The examples above show that developers vary in how they manage MCP server integration in practice, a marked contrast to the integration of “traditional” third-party packages. Each programming language ecosystem typically has package managers that enforce how dependencies are declared (e.g., pom.xml for Maven with Java, package.json for JavaScript), yet no comparable standard governs how an MCPApp declares the MCP servers it depends on. Beyond dependency declaration, MCP introduces unique architectural considerations that have no equivalent in traditional dependencies. The first is communication: whereas a library can only be invoked directly through API calls in the programming language, an MCP server is reached over a wire protocol. The MCP SDK provides high-level APIs for this, but using it is optional. Since MCP is a wire protocol, compliance follows only from adhering to the specification (e.g., the JSON-RPC 2.0 message schemas), allowing an MCPApp to forgo the SDK and implement its own client. The second is invocation: while explicit calls in code determine which (and when) of a library’s APIs are used, an MCPApp has no such control by default over when a server’s tools get executed. Instead, the LLM decides which tools to call when. Governing these calls requires adding human-in-the-loop mechanisms. In this paper,
we study how these differences manifest in practice across MCP-enabled applications. III. DATASET C ONSTRUCTION To answer our research questions, we need to identify a large collection of MCPApps to analyze. Toeppe et al. [19] recently released a dataset of GitHub repositories with MCPrelevant implementations, including both client and server repositories (referred to hereafter as Toeppe-MCPImpl). Specifically, this dataset contains 2,297 GitHub repositories, of which the authors classify 711 as Server, 215 as Client, and 1,240 as Both. Given our terminology defined in Section II, the clients’ category corresponds to the MCPApps we focus on. Thus, we are specifically interested in the repositories they categorize as “client” or “both”, which amounts to 1,455 repositories. However, upon inspecting the repositories listed in Toeppe-MCPImpl, we notice several limitations. First, the dataset contains only repositories created or updated between January 2024 and October 2025. Additionally, upon further inspection of the repositories marked as clients or both, we notice several mismatches in the categorization. For example, google-gemini/gemini-cli [20] is classified in the dataset as “both” with high confidence. However, based on its documentation, “Gemini CLI brings the power of Gemini models directly into your terminal” with the “Setup an MCP server” section further providing guidance on how to “connect Gemini CLI to [. . . ] external databases and services.”. This indicates that Gemini CLI should be categorized as client only (or MCPApp in our terminology), not both. Another example is the repository IBM/mcp [21], which is categorized as “both”. However, this repo only documents a list of IBM MCP Servers, a list of contributors, and a link to a Discord group. For information relevant to MCPApps, the repository only has this line: “We recommend using Langflow or your IDE of choice as MCP client.” Accordingly, this is a documentation repository that does not actually contain the implementation of an MCPApp. Another example is of modelcontextprotocol/python-sdk [11], which is again classified as “both” in the dataset while it is neither an MCPApp nor a server, but is instead an official SDK that used for building MCPApps or MCP Servers. Based on these observations, we define a new mining pipeline to precisely identify MCPApps. Such a pipeline follows the same idea of a two-step process used in Toeppe-MCPImpl: searching GitHub for candidate repositories, followed by further filtering and categorization. However, we are mainly interested in finding as many MCPApps as possible (rather than any MCP-related repository). We first conduct a detailed manual investigation to identify (1) search keywords we can use on GitHub and (2) filtering criteria that can be used to identify MCPApps. We then design an automated search and filtering pipeline to construct our final data set. As a result of our manual investigation, we also construct a ground-truth labeled dataset to evaluate our automated pipeline.
TABLE I E XAMPLES OF TOP - YIELDING G IT H UB SEARCH QUERIES , DRAWN FROM THE 17 REPO - SEARCH AND 29 CODE - SEARCH QUERIES . Search type
Example queries
repo search
Model Context Protocol in:name,description,readme, MCP client in:name,description,readme, mcp-client in:name,description,readme, mcp-go in:name,description,readme, topic:mcp
code search
client/streamableHttp.js language:TypeScript, SSEClientTransport language:TypeScript, mark3labs/mcp-go filename:go.mod, client/stdio.js language:TypeScript, from mcp.client.streamable_http language:Python
In the next subsections, we first describe our manual investigation that led to the final search queries that we used to mine GitHub for candidate repos, and then we detail our automated approach for classifying repositories as MCPApps. A. Manual Investigation and Identifying Candidate MCPApp Repositories from GitHub a) Deriving search queries: Toeppe-MCPImpl used 5 GitHub search queries to identify MCP-relevant repos (“MCP”, “mcp server”, “Model Context Protocol”, “Claude Desktop MCP”, “mcp client”). They searched for these keywords in the repository name, description, and README [19]. Since our objective is to target MCPApp implementations, we need search terms that are targeted specifically towards MCP hosts and clients, rather than any MCP-related repository. Accordingly, we inspect a subset of repositories from Toeppe-MCPImpl that we manually confirmed as MCPApp. We look into recurring keywords found in repositories that would be considered MCPApp. We also identify some additional open-source repositories in registries that list MCPApps, including Glama, MCP.so, PulseMCP, and MCPservers.org2 , as well as Awesome MCP Clients [22] and examples on the official MCP documentation. Some of the repositories we inspected include nanbingxyz/5ire [23] and aaif-goose/goose [24]. We inspect each of these repositories’ README and source code to identify any recurrent patterns that we can use to search GitHub for potential MCPApps repositories. Through this manual analysis, we identify both keywords that appear in the repository documentation or descriptions and specific API calls that typically occur in MCPApps. Specifically, we identify 17 keywords that can appear in a repo’s topics, name, description, or README file. For example, “Model Context Protocol”, “MCP Host”, “MCP Application” and “MCP Client”. We also identify 29 APIs or dependencies that can appear in the codebase, such as “@modelcontextprotocol/sdk”, or transport patterns, e.g., “StdioClientTransport”. 2 https://glama.ai/mcp/clients; https://mcp.so/clients; https://www.pulsemcp. com/clients; https://mcpservers.org/clients
Table I shows examples of the top-yielding queries among the 46 we used; the full list is included in our online artifact. b) Inspect Candidates and Build Ground Truth Dataset: Even though our search terms are geared towards MCPApps, it is natural that the search may return MCP servers or even non-MCP relevant repositories. Accordingly, we need to define a filtering strategy to identify MCPApps from the set of candidate repositories. Executing the GitHub search queries identified in the previous step returns 21,355 repos. Following Toeppe-MCPImpl, we set the minimum repository update date to January 2024, allowing us to retrieve repos with at least one update between January 2024 and until the search execution date (latest June 11, 2026). We run all 46 queries, merge the results, and de-duplicate repositories returned by more than one query. To filter out small-scale toy projects, we also discard repositories with fewer than 10 stars or a size smaller than 10 KB. Through this sequence of steps, we obtain 6,994 candidate repositories. We select a statistically representative random sample of 68 candidate repositories (90% confidence level and 10% margin of error) for manual analysis. Through our manual analysis, we first want to confirm which of these are actually MCPApps, providing us with ground truth we can use to evaluate any automatic categorization. Secondly, we keep track of the reasons (or evidence) we find in the repositories that led us to identify them as MCPApps. This evidence can serve as filtering criteria for an automated pipeline. Two of the authors independently inspect each sampled repository to determine whether it is an MCPApp and record the evidence they use to reach their decision. If it is not an MCPApp, they mark the repository type it best matches. Overall, we identify the following RepoType categories for the returned candidate repos: MCPApp, MCP Server, SDK, and Documentation. There were even some Non-MCP Relevant repositories returned, such as spmallick/learnopencv [25], which is a computer vision tutorial. Out of the 68 examined repositories, we found only 21 to be MCPApps. The labeled set of 68 repositories serves as our ground truth for later automated categorization. B. Automatic Classification of MCPApps Our analysis showed that no single keyword, dependency, or manifest can cleanly and deterministically separate these categories using a rule-based filtering method. The same MCP import or transport class can appear across servers, SDKs, and Apps, so assigning a category requires reading how MCP is actually used. Since manually reviewing the code across the entire candidate dataset is infeasible, we define an LLMbased approach to categorize repositories into the RepoTypes we identified above. For each repository, we clone it and scan all source and configuration files for MCP-related signatures, ranking files by hit count. We then assemble the README and the top-ranked files into a single structured prompt that asks the model to categorize the repository into one of the five RepoType categories, or return Unsure if the evidence is insufficient. If the model returns Unsure, we perform a second pass with additional evidence from the ranked list. A
second Unsure is accepted as final. We use gpt-5 for this categorization, with our full prompt available in our artifact. Before running our LLM-based classification pipeline on the full dataset, we first evaluate it on our 68 manually labeled repositories. The classifier achieves an overall accuracy of 95.6% (65/68). For MCPApp identification in particular, the precision is 1.000, recall 0.905, and the F1 score is 0.950. C. Final Data Set Having validated our pipeline’s performance on a groundtruth set, we then apply it to the full set of mined repositories. At the time of running the classification script, four of the repository URLs we collected were no longer available and could not be cloned. Accordingly, the final input list to the LLM contained 6,990 repositories. Apart from 20 repositories that required a second iteration (i.e., first iteration returned Unsure), the LLM classified all repositories in the first attempt. Overall, the LLM categorizes 1,727 repos as MCPApps, 2,732 as MCP-Servers, 522 as SDKs, 823 as documentation, and 1,181 as Non-MCP-relevant. There were also 5 remaining Unsures, which we manually resolve. None of these turned out to be MCPApps. As a final additional validation, we randomly sample an additional 30 repositories from the 1,727 repositories labeled as MCPApps. We manually confirm that 29 of these 30 are indeed MCPApps, while the remaining one is a documentation repository that contains a small MCP app demo implementation snippet. This gives us high confidence that our classification pipeline is robust and that we can proceed with using it. We discard the documentation repository, leaving us with 1,726 MCPApps. At the time of our final analysis, 3 of these repositories were deleted or set to private. We exclude these three, leaving us with a final data set of 1,723 MCPApps referred to as MCPAppDS. IV. M ETHODS : A NALYZING MCPA PPS We design a multi-stage research pipeline to identify and categorize the integration patterns of MCP servers in MCPApps. Our approach follows a derive-then-scale structure: we first manually analyze 50 randomly sampled MCPApps to derive MCPAppTax, then develop an automated LLM-based pipeline that applies MCPAppTax across the full dataset. A. Manual Analysis and Taxonomy Derivation We first manually inspect 50 randomly sampled repositories from our MCPAppDS. We review the source code, configuration files, and documentation of each repository to answer each of our three research questions. During the review, we note the evidence we find so we can use it later for our large-scale LLM-based analysis. We iteratively combine observations into named codes/categories. As we examined more repositories, the classification properties began to repeat, and no new categories emerged. Specifically, we find that the taxonomy reached empirical saturation at about 30 repositories. Based on this analysis, we derive the MCP integration taxonomy, MCPAppTax.
Two authors independently labeled 29 of the 50 repositories across all five MCPAppTax dimensions, with per-dimension raw agreement between 75.9% and 93.1%. Because perdimension Krippendorff’s α can be misleadingly low when label distributions are skewed, we report a pooled α over all 29 × 5 = 145 (repository, dimension) items: 0.82, indicating substantial agreement. We resolved all disagreements, which were mostly boundary cases, through discussion; one author then labeled the remaining 20 repositories using the refined criteria. 1) Dimension 1: Configuration: We find that there are mainly two ways in which MCP servers are declared and configured: Configuration Files: Server definitions are stored in an external, non-executable file such as JSON, YAML, or TOML. The file typically follows a declarative schema listing server names alongside their transport type, command, arguments, and environment variables. A sample configuration file can be seen in Listing 1. For example, johnrobinsn/askit [26] stores its server list in mcp_config.json while mario-andreschak/FLUJO [27] stores it in mcp_servers.json. Database: Here, server definitions are stored in a relational or embedded database and managed through explicit Object-Relational Mapping (ORM) or query operations. For example, nanbingxyz/5ire [23] stores server records in a PGlite table via Drizzle ORM. We also observe server definitions declared in client-side stores such as LocalStorage or IndexedDB in web-native and desktop hybrid applications (e.g., Electron, Chrome extensions). We consider these as a form of database as well. For example, NitroRCr/AIaW [28] stores its server list using Dexie.js with installedPluginsV2 as the keyed store. 2) Dimension 2: Client Instantiation and Server Communication: Recall that the MCPApp communicates with an MCP server through an initiated MCP client within the app. We find that there are mainly two ways by which this process is managed: The MCP SDK: Here, the MCPApp creates the client and manages server communication all through the MCP SDKs for each programming language. For example, johnrobinsn/askit [26] uses the official MCP SDK methods for Python, specifically stdio_client(..), sse_client(..), streamablehttp_client(..). Self-Managed: In this setup, the MCPApp does not actually use the official MCP SDK to communicate with the server. Instead, it writes its own client-server communication code. For example, daodao97/ChatMCP [18] (discussed in Section II and Listing 3) defines a custom McpClient interface with four concrete implementations selected at runtime based on the server type: StdioClient, SSEClient, StreamableClient, and InMemoryClient. Each implementation handles its own transport-level communication, JSON-RPC message construction, and session lifecycle independently.
3) Dimension 3: Human-in-the-loop (HITL): In this dimension, we describe whether an MCPApp includes any mechanisms through which human oversight is incorporated into the tool invocation workflow. We identify three mechanisms that may be present in any combination: approval required, allowed list, and logging. Approval Required: The MCPApp intercepts an MCP tool call before execution and explicitly prompts the user to approve or deny it. The tool does not execute until the user responds. For example, before each tool call, nanbingxyz/5ire [23] asks the user for confirmation where they can allow the tool to execute always, never, or only once (i.e., it will ask again the next time the tool is executed). Similarly, autohandai/code-cli [29] implements a PermissionManager with mode:’interactive’ as its default, halting on each tool call. Approval Required applies only when the source code clearly show such a blocking user approval step gates tool execution. Allowed List: The MCPApp maintains a user-controlled list or flag that determines which servers or tools are active, checked before or during invocation. Unlike Approval Required, which intercepts each tool call in real time, an allowed list is configured in advance, so once a server or tool is enabled, it executes without further prompting. For example, AstrBotDevs/AstrBot [30] implements an active flag on each server entry controlled via a dashboard toggle (enable_mcp_server). A repository is considered to use Allowed List only when there is an explicit run-time check that can reject or skip a server or tool based on user-controlled configuration. Logging: The MCPApp logs MCP tool activity, traces, or monitoring dashboards under its default runtime configuration. In this case, the code has logging infrastructure active at INFO level during the MCP connection lifecycle, tool calls, or error handling. This as opposed to DEBUG level logging, which is only used by the app developers themselves. For example, daodao97/ChatMCP [18] uses the Dart Logger package extensively throughout its MCP connection lifecycle and tool invocation paths. 4) Use Case Domain and Domain Specificity: In addition to the three integration dimensions above, we also examine how MCPApps vary in their primary purpose and target domain. We therefore collect two supplementary labels for each repository. Use Case Domain captures the application’s primary role: an AI Assistant is a standalone tool that end users run to accomplish tasks using AI; an MCP Support Tool is used by developers to build, test, evaluate, or debug an AI or MCP system; and Infrastructure refers to components that manage or proxy MCP servers themselves rather than serving end users directly. Domain Specificity captures whether the application targets a particular domain (e.g., finance, healthcare, software development) or is general-purpose. A general-purpose host is not built around any one domain, it’s usually a chatbot that users can point at whatever they need by connecting the MCP servers of their choice.
B. LLM-based Classification Pipeline For feasibility of categorizing all MCPApps according to MCPAppTax dimensions, we create an LLM-based classification pipeline. The central challenge is evidence retrieval: a repository may contain thousands of files, but the classification along any dimension can typically be decided by a small handful of files. Supplying the entire repository to the model is both expensive and counterproductive, as the few decisive files are drowned out by irrelevant context. Our pipeline therefore first retrieves a compact set of evidence files per taxonomy dimension, and then issues 2 focused LLM queries, one for configuration, communication and the use case domain, and another for human-in-the-loop. a) Evidence Retrieval: Using the cloned repository, we analyze all files while skipping generated files or dependency directories such as node_modules, dist, .venv, and target. We maintain two independent keyword sets that determine which files are most relevant for each query. The MCP keyword set combines configurationrelated terms (e.g., mcpServers, mcp_server.json, yaml.load, sqlite, localstorage, drizzle, indexeddb) with communication-related terms (e.g., StdioClientTransport, client.connect, callTool, JSONRPCMessage). The HITL keyword set covers oversight-related terms such as approval, permission, allowed_list, and logging. Each file is scored by the total number of keyword hits in its content, producing two ranked lists, one for each of the evidence buckets. b) File Selection: For the MCP query (configuration and communication), we select up to 20 files from the ranked list using a three-tier priority: (1) files whose path or filename contains mcp, (2) files whose content contains mcp, and (3) remaining files in keyword hit rank order. This reflects our observation that MCP-specific integration code is most often located in MCP-named files. For the HITL query, we use a two-tier priority: (1) files whose content contains mcp (since HITL logic frequently lives in general-purpose UI or controller code whose path does not mention MCP), and (2) remaining files in keyword hit rank order. For each query, we include the selected files (truncated to 20,000 characters each) and the README file (truncated to 4,000 characters). c) LLM Query 1: Configuration and Communication: The first query presents the selected MCP evidence files together with the README and asks the model to assign the two supplementary labels, use-case domain and domain specificity, as well as the two MCPAppTax dimensions covered by this query: configuration type, including the concrete file or database name, and communication source, including the concrete client or session class names used. The prompt instructs the model to classify based on code evidence for each label. If the evidence is insufficient to classify any dimension confidently, the model is instructed to return Unsure rather than guess. d) LLM Query 2: Human-in-the-loop: The second query presents the HITL evidence files and asks the model to classify
three independent binary controls. We ask the model to classify Logging as Yes if the codebase has logging infrastructure active at INFO level for the MCP connection lifecycle, tool registration, or error handling. We ask it to classify Allowed List as Yes if there is an explicit runtime check that can reject or skip a server or tool based on user-controlled configuration. Finally, we ask it to classify Approval Required as Yes if the files clearly show a blocking user-approval step that gates tool execution. Note that the LLM categorizes each separately, allowing a repository to exhibit any combination of the three. e) Model Selection: We evaluated two factors when selecting the model for the classifier: whether reducing the number of files from 20 to 10 affects classification quality, and how gpt-5 compares to gpt-5-mini. Running four experiments (one per combination) on the same 10 groundtruth repositories, we found that the main taxonomy labels were largely insensitive to model choice, with both models agreeing on 95% of categorical classifications. Reducing context from 20 to 10 files, however, reduced recall as decisive files were dropped from the evidence set. We therefore adopt gpt-5-mini with 20 files per query, substantially reducing cost relative to gpt-5. f) Unsures: It is possible in some cases that the evidence set sent to the LLM does not contain files that can conclusively be used for classification. For this reason, and to reduce the risk of the LLM confidently misclassifying repositories, we add an option to return ‘Unsure’ for any of the three dimensions. We try to manually resolve as many ‘Unsure’ labels as possible.
TABLE II D ISTRIBUTION OF C ONFIGURATION TYPES ACROSS MCPA P P DS (n = 1,687 LABELLED ). Configuration
Count
%
File only File + Database Database only
1,290 148 249
76.5% 8.8% 14.8%
overall accuracy of 96.5%, with per-dimension accuracy ranging from 93.1% to 100%. We resolved the mismatches in the MCPAppDS. V. R ESULTS A. Dataset Overview: Use Case Domain Before examining the three taxonomy dimensions, we describe the composition of MCPAppDS by use case domain. We find that 68.7% of MCPApps are AI Assistants, i.e., standalone applications that end users run to accomplish tasks with AI assistance. MCP Support Tools represent 21.6% of the MCPApps where developers use them to build, test, or explore AI and MCP systems. The remaining 9.7% are Infrastructure components that manage or proxy MCP servers rather than serving end users directly. In terms of the domain across all MCPApps, 59.5% are general-purpose, while the remainder target specific domains, most commonly software development (15.8%), security (3.2%), research (1.9%), and finance (1.5%).
C. Evaluation
B. RQ1: How are MCP Servers Configured in MCPApps?
We evaluate the LLM-based classification pipeline against the manually annotated ground-truth set of 50 MCPApps from our formative study. For each MCPAppTax dimension, we compute accuracy over labelled cases (excluding entries where predicted label is Unsure). The pipeline achieves an overall accuracy of 98.3% across the five dimensions, with individual axes ranging from 95.8% (Configuration) to 100.0% (Communication Source, Logging the full dataset. We apply our LLM-based pipeline to all 1,723 MCPApps in MCPAppDS. After running the pipeline, 529 repositories had at least one Unsure field. From these, we are able to resolve 471 of the repositories. For each taxonomy dimension, we report results over the repositories for which a label was resolved; the count of resolved repositories varies slightly by dimension and is reported in each table. The remaining Unsure values account for no more than 2.1% of any single field, and these correspond to repositories whose source code is inaccessible (binary releases, VS Code extensions, docs-only repositories) or whose configuration falls outside MCPAppTax (CLI-supplied or hardcoded server definitions, discussed in Section VI). To further strengthen the reliability of the LLM results, we manually validated the classifications for 30 randomly sampled repositories across MCPAppTax. Excluding cases where the LLM returned Unsure, the pipeline achieves an
Table II summarizes the configuration dimension across the 1,687 repositories with a resolved label. We find that 85.2% of MCPApps use a file to store their MCP server list, either exclusively (76.5%) or alongside a database (8.8%). File-based configurations are declarative JSON, YAML, or TOML documents that list server names with their transport type, command, arguments, and environment variables. However, there is no dominant naming convention: while 69.1% of file-configured repositories include mcp in their configuration file name, they split across competing variants such as mcp.json (30.7%) and mcp_servers.json (12.8%). This contrasts with traditional dependency management, where file names are standardized by convention (e.g., package.json, pom.xml). Accordingly, MCPApps converge on configuring MCP servers mainly through files, but not on any shared naming convention for those files. We also find that 23.5% of MCPApps use a database, either as the sole mechanism or combined with a file. The database layer itself varies between SQL-backed stores and browsernative persistence (localStorage and IndexedDB, typically in Electron or web-based clients). Repositories that combine both file and database (8.8%) typically use files for per-project server definitions while storing user-managed or dynamically discovered servers in a database.
TABLE III D ISTRIBUTION OF C OMMUNICATION S OURCE ACROSS MCPA P P DS (n = 1,710 LABELLED ) Communication Source
Count
%
SDK Self-managed
1,386 324
81.1% 18.9%
RQ1 Summary: Files are the dominant configuration mechanism (85.2%), but there is a lack of naming convention. Database storage is also used (23.5%) but varies between SQL stores and browser-native persistence. C. RQ2: How is Communication with MCP Servers Managed? Table III summarizes the communication sources across the 1,710 repositories with a resolved label. Among these MCPApps, 81.1% communicate with MCP servers through an official MCP SDK. The remaining 18.9% of MCPApps implement the client layer entirely themselves, managing JSON-RPC 2.0 message construction, transport initialization, and session lifecycle without relying on any official SDK. These repositories define custom client types (e.g., StdioClient, SSEClient, McpClient) that interact with MCP servers directly at the message level. The implementation is therefore valid as long as it adheres to the JSON-RPC 2.0 message format and transport conventions. RQ2 Summary: 81.1% of MCPApps use an official MCP SDK, but 18.9% implement the client layer themselves. D. RQ3: What Human-in-the-Loop Controls Are Present? Table IV reports the per-mechanism breakdown of observed HITL controls. Note that the three HITL categories are independent and can appear in any combination. We find that logging is nearly universal where 90.8% of MCPApps send logs at INFO level or above covering during at least part of the MCP lifecycle, whether connection or tool invocation. Recall that logging does not prevent or gate any tool execution, but it provides an observability channel, either through user-facing dashboards and trace views or through application logs. We also find that allowed lists are common, but approval gates are less common. Specifically, 77.2% of MCPApps maintain some form of explicit enable/disable control over servers or tools. This control is configured in advance: at each tool call, the application automatically checks whether the requested server or tool is enabled, without involving the user. In contrast, only 37.2% implement a blocking approval gate, where each tool call is suspended until the user explicitly allows or denies it. Conversely, in 62.8% of MCPApps, no approval is required before a tool executes: once a tool is enabled, the LLM’s request alone triggers execution. This gap suggests that the majority of developers who implement HITL controls prefer to set these configurations before the session, rather than through real-time interruption of the execution loop.
TABLE IV D ISTRIBUTION OF HITL MECHANISMS ACROSS MCPA P P DS. E ACH MECHANISM IS COMPUTED OVER ITS OWN RESOLVED SUBSET (n = Y ES + N O , EXCLUDING U NSURE ). HITL Mechanism Logging (n = 1,714) Allowed List (n = 1,717) Approval Required (n = 1,714)
Yes
No
1,557 (90.8%) 1,325 (77.2%) 638 (37.2%)
157 (9.2%) 392 (22.8%) 1,076 (62.8%)
We also explore the combinations of HITL mechanisms, focusing on the 1,703 repositories with resolved labels across the the three mechanisms. From these MCPApps, we find that 32.3% implement all three controls simultaneously. The most common pattern is logging combined with an allowed list but without an approval gate (40.0%), reflecting passive observability plus pre-session access control with no additional approval required during tool calls. 20.0% of MCPApps have no active gate of any kind: neither an allowed list nor an approval step. Within this group, 16.4% rely on logging alone, and 3.5% implement no HITL mechanism at all. RQ3 Summary: Logging is near-universal (90.8%) and allowed lists are common (77.2%), but only 37.2% of MCPApps implement a blocking approval gate. The most common pattern, logging plus an allowed list but no approval gate (40.0%), provides pre-session control with no real-time intervention. VI. D ISCUSSION A. MCP Servers are not fully standardized dependencies Our central motivation is to understand how MCP servers compare to traditional software dependencies from a dependency management perspective. Our results reveal a picture of partial standardization: the MCP ecosystem has converged on some practices but remains fragmented on others, with meaningful dependency management and security implications along each divergence. a) Where standardization has emerged: Two dimensions show clear convergence. First, files are the dominant configuration mechanism: 85.2% of MCPApps store their server list in a JSON, YAML, or TOML file, echoing how traditional package managers use declarative manifests. Second, the official MCP SDKs have achieved strong adoption, with 81.1% of MCPApps using one to manage client-server communication. Both patterns suggest that developers have gravitated towards standardization similar to traditional software ecosystems. b) Where standardization is absent: Despite converging on files, developers have not converged on a file name. In traditional ecosystems, the manifest file name is fixed by the package manager (package.json, pom.xml, requirements.txt), which enables automated analysis tools, vulnerability scanners, or CI pipelines to reliably locate and parse dependency declarations. With MCP, no equivalent convention exists: although mcp.json is the most common configuration file name, it appears in only 30.7% of fileconfigured repositories. Tooling that wants to audit which
MCP servers an application depends on cannot assume any specific file name, making automated dependency discovery significantly harder. Similarly, 81.1% use an official SDK while 18.9% implement the MCP client layer themselves. Traditional in-process libraries surface no such layer: developers call an API directly, with no protocol to implement, so the choice does not arise. Because MCP is a wire protocol, a selfmanaged client is valid, but it also means that a fraction of MCPApps carry custom JSON-RPC 2.0 implementations that may deviate from the specification. c) Security implications of missing oversight standards: With MCP, the decision of which tools get called is delegated to the LLM, and the absence of a standardized oversight mechanism leaves the MCPApp developers to decide independently how much control to impose. Our results show that these choices vary, spanning the full range from blocking approval gates to no oversight at all (Table IV). The clearest consequence is at the permissive end: 62.8% of MCPApps require no approval before a tool executes, the LLM’s request alone is enough to run an enabled tool.The risk is greatest in the 20.0% of MCPApps with no active gate of any kind. These applications have neither an allowed list restricting which tools are enabled nor an approval step, so the LLM can invoke any tool unconditionally. Within this tier, the 16.4% that rely on logging alone retain observability, but no means of prevention, and the remaining 3.5% have no HITL mechanism at all. In these configurations, a prompt-injection or toolpoisoning attack [4], [9], a compromised MCP server [3], or an unexpected LLM decision could trigger tool execution with no structural opportunity for the user to intervene. This contrasts with how traditional dependency risks are managed. There, invocation is fixed in code and statically analyzable: call sites are auditable, and dependencies can be screened ahead of execution through security scanning and knownvulnerability databases. Dependencies can still misbehave, but the ecosystem provides mechanisms to surface that risk (e.g., vulnerability scanners and security advisories) and to contain it (e.g., pinning or removing a flagged dependency) before any code runs. MCP lacks these safeguards: there is no standard configuration file to scan and no vulnerability database for MCP servers. Moreover, since the LLM decides at runtime which tools to call, the only place left to intervene is the tool call itself, yet 62.8% of MCPApps have no approval gate there (Table IV). B. Configuration Patterns Beyond MCPAppTax During manual resolution of Unsure configuration labels, we found a few repositories that fit none of the three MCPAppTax configuration categories and were absent from our formative sample; we note them as observations. Two patterns recur: hardcoded server definitions, where the command or URL is embedded in source code (e.g., kirillsaidov/ollama-mcp-example [31]), typically in tutorials and demos; and CLI-supplied identity, where the server is passed as a commandline argument with no persistent configuration (e.g.,
nccgroup/http-mcp-bridge [32]). Both are too rare to affect our findings, but they represent the least visible form of dependency, existing only in runtime invocation and leaving no trace in configuration files or a database. VII. T HREATS TO VALIDITY a) Construct Validity: This concerns whether MCPAppTax and our labeling procedure actually measure what we claim to measure: the MCP integration practices of MCPApps. We derived MCPAppTax through iterative manual analysis of 50 randomly sampled MCPApps and observed empirical saturation after approximately 30 repositories; nevertheless, rare integration strategies may fall outside its categories. Our pipeline is designed to handle such cases safely: rather than forcing an out-of-taxonomy repository into an existing category, it returns Unsure, and manual inspection of these cases surfaced only a handful of rare patterns (e.g., hard-coded server definitions), which we report in Section VI and which do not affect our findings. A second threat is that we measure integration practices through static source code analysis rather than runtime behavior, so dynamic configurations may not be detectable from repository contents alone. We mitigate this by assigning a label only when explicit code evidence supports it, and conservatively labeling repositories Unsure otherwise. b) Internal Validity: This concerns whether our repository mining and classification process introduces any systematic errors. Our study relies on gpt-5 to identify MCPApps and gpt-5-mini to classify them according to MCPAppTax. Recent work on LLM-assisted software engineering highlights several threats associated with such workflows, including prompt sensitivity, hidden model biases, and limited contextual reasoning, especially when tasks require interpretation beyond well-defined coding schemes [33], [34]. These studies also conclude that LLMs are most reliable for deductive classification tasks that employ predefined codebooks and retain human oversight throughout the analysis [34]. Our pipeline is designed to mitigate these threats. We designed our pipeline accordingly. We manually developed MCPAppTax before any large-scale classification, giving the model a fixed codebook. We evaluated both the repository identification pipeline and the taxonomy classification pipeline against manually annotated ground-truth sets, observing high agreement with human annotations. When evidence was insufficient, the model returned Unsure rather than a forced prediction, and we resolved these cases manually. The LLM thus served as an annotation assistant within a human-supervised workflow. c) External Validity: Our study analyzes 1,723 opensource MCP-enabled AI applications hosted on GitHub. Consequently, the observed design patterns may not generalize to proprietary, commercial, or internally developed MCP applications. Furthermore, the MCP ecosystem is evolving rapidly, with new SDKs, transport mechanisms, security practices, and deployment architectures continuing to emerge as the protocol matures. Our findings therefore represent a snapshot
of the ecosystem at the time of data collection rather than a characterization of all future MCP-enabled applications. VIII. R ELATED W ORK A. MCP Datasets Several authors curated datasets of MCP-related implementations to enable empirical analysis. Toeppe et al. [19] released a dataset of 2,297 GitHub repositories with MCP-relevant implementations, classifying each as server, client, both, or gateway. As discussed in Section III, we examined this dataset as a reference point and used it to derive targeted search queries, which were used in our classification pipeline with a focus exclusively on MCPApps. Lin et al. [35] constructed MCPCorpus, a large-scale dataset of the MCP ecosystem comprising roughly 14,000 MCP servers and 300 clients. For each entry, they record protocol-level attributes (tools, SSE URLs, server launch commands, and related configuration) alongside GitHub repository signals such as star counts. They used a public registry3 as the primary source for discovering servers and clients, with GitHub used only to enrich the resulting metadata. Two characteristics distinguish their work from ours. First, MCPCorpus is predominantly server-centric, only 300 of its entries are clients, whereas ours focuses on the host/MCPApp side. Second, we search GitHub directly for implementations rather than drawing from registries, letting us collect the open-source code of a substantially larger, hostcentric dataset. Guo et al. [36] also collected a dataset of 8,060 MCP servers and 341 clients as part of a broader measurement study. B. Empirical Studies and Analysis of MCP The majority of MCP research takes a security perspective, focusing on vulnerabilities in MCP servers and the susceptibility of MCP clients to prompt injection and tool-poisoning attacks. Hasan et al. [3] conducted the first large-scale empirical study of 1,899 MCP servers, examining their health, sustainability, security vulnerabilities, and maintainability issues using static analysis and a hybrid analysis pipeline. Hou et al. [4] conducted a systematic study of MCP’s architecture and security landscape, categorizing threats across the server lifecycle and identifying prompt injection and unauthorized access as primary risks. While HITL mechanisms can be viewed as one defense against unwanted tool calls, we do not specifically examine the security of MCP servers or attack vectors such as prompt injection; instead, we focus on the practices that developers employ at the application layer in MCPApps. Guo et al. [36] collected 8,060 MCP servers and 341 MCP clients as part of a measurement study. As part of their client analysis, they examined the communication protocols used by clients and whether they support single-server or multi-server integration. They found that stdio remains the dominant transport mechanism while streamable HTTP shows limited adoption, and that 80.9% of clients connect to a single 3 https://mcp.so/
server. While Guo et al. characterize the ecosystem at the protocol and topology level, our analysis extends this by examining how MCPApps configure their server lists, how they instantiate MCP client connections, and what human oversight mechanisms, if any, are in place before a tool is executed. Stein [37] analyzed 177,436 tools published in public MCP server repositories between November 2024 and February 2026, finding a notable shift toward action tools that directly modify external environments (from 27% to 65% of tool usage over the study period). This shift to high-stakes action tools shows why the presence or absence of approval gates in MCPApps has real world consequences, a dimension we study in this paper. Singh et al. [38] surveyed MCP’s foundational architecture and core primitives, including tools, resources, and prompts. They described tools as capabilities that models can actively invoke at runtime, typically subjected to human approval, distinguishing them from the more passive, predefined behavior of resources and prompts. While Singh et al. acknowledged human-in-the-loop (HITL) control as a desirable property of MCP-enabled systems, they do not empirically examine whether and how MCPApps actually implement such controls in practice. Our work fills this gap through a large-scale empirical analysis, characterizing the diversity of HITL mechanisms that developers employ in practice. Huang et al. [9] applied STRIDE and DREAD [39] frameworks to identify and prioritize potential threats across MCP architectures. They then used their derived threat model to assess 7 MCP-enabled AI applications (hosts), which the authors refer to as MCP clients (Claude desktop for Windows, Cursor, Cline, Continue, Gemini CLI, Claude Code, and Langflow). By creating malicious servers and designing four attack types, they explored which clients are susceptible to the attacks. They specifically looked at different defense or detection mechanisms implemented in the clients: warning messages displayed to the user, confirmation dialogs required, tool execution blocked or sandboxed, or logging of suspicious activity. Whereas Huang et al. derived defense categories from a threat model and applied them to a small, curated set of hosts, we identify human-in-the-loop mechanisms from a large corpus of MCPApps; our taxonomy partially overlaps with their catalog, both cover blocking approval and logging, and we add allowed-list controls as a third, empirically observed mechanism. IX. C ONCLUSION The Model Context Protocol (MCP) has rapidly become a standard for connecting AI applications with external tools. Yet, how developers integrate MCP servers in practice remains under-studied. We present the first large-scale empirical study of MCPApps, introducing MCPAppTax, which characterizes MCP integration across configuration, client communication, and human-in-the-loop controls. Applying it to 1,723 open-source MCPApps on GitHub via an LLM-assisted mining pipeline, we provide a quantitative characterization of the ecosystem’s configuration, communication, and oversight
practices. The taxonomy offers a standardized vocabulary for describing MCP integrations, and the released MCPAppDS and pipeline lay a foundation for future study of MCP adoption, security, and engineering practices. R EFERENCES [1] Anthropic. (2024, Nov.) Introducing the Model Context Protocol. [Online]. Available: https://anthropic.com [2] P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. Küttler, M. Lewis, W.-t. Yih, T. Rocktäschel, S. Riedel, and D. Kiela, “Retrieval-augmented generation for knowledge-intensive NLP tasks,” in Advances in Neural Information Processing Systems (NeurIPS), vol. 33, 2020, pp. 9459–9474. [3] 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,” ACM Transactions on Software Engineering and Methodology, 2025. [4] 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. [5] E. Larios Vargas, M. Aniche, C. Treude, M. Bruntink, and G. Gousios, “Selecting third-party libraries: The practitioners’ perspective,” in Proceedings of the 28th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM, 2020, pp. 245–256. [6] J. Cox, E. Bouwers, M. van Eekelen, and J. Visser, “Measuring dependency freshness in software systems,” in Proceedings of the 37th International Conference on Software Engineering (ICSE), vol. 2. IEEE, 2015, pp. 109–118. [7] R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Do developers update their library dependencies? an empirical study on the impact of security advisories on library migration,” Empirical Software Engineering, vol. 23, no. 1, pp. 384–417, 2018. [8] Anthropic, “Architecture overview,” https://modelcontextprotocol.io/ docs/learn/architecture, 2025, accessed: 2026-06-18. [9] C. Huang, X. Huang, N. Tran, and A. M. Fard, “Model Context Protocol Threat Modeling and Analysis of Vulnerabilities to Prompt Injection with Tool Poisoning,” Journal of Cybersecurity and Privacy, mar 2026. [10] Model Context Protocol, “Typescript sdk for the model context protocol,” https://github.com/modelcontextprotocol/typescript-sdk, 2024, accessed: 2026-06-30. [11] ——, “Python sdk for the model context protocol,” https://github.com/ modelcontextprotocol/python-sdk, 2024, accessed: 2026-06-30. [12] ——, “Java sdk for the model context protocol,” https://github.com/ modelcontextprotocol/java-sdk, 2024, accessed: 2026-06-30. [13] ——, “Kotlin sdk for the model context protocol,” https://github.com/ modelcontextprotocol/kotlin-sdk, 2024, accessed: 2026-06-30. [14] ——, “C# sdk for the model context protocol,” https://github.com/ modelcontextprotocol/csharp-sdk, 2024, accessed: 2026-06-30. [15] ——, “Swift sdk for the model context protocol,” https://github.com/ modelcontextprotocol/swift-sdk, 2024, accessed: 2026-06-30. [16] ——, “Rust sdk for the model context protocol,” https://github.com/ modelcontextprotocol/rust-sdk, 2024, accessed: 2026-06-30. [17] ChatGPTNextWeb, “Nextchat,” https://github.com/ChatGPTNextWeb/ NextChat, 2025, accessed: 2026-06-30. [18] daodao97, “Chatmcp,” https://github.com/daodao97/ChatMCP, 2025, accessed: 2026-06-30. [19] B. Toeppe, A. Barrak, and E. Ksontini, “A large-scale dataset of mcp implementations on github,” in Proceedings of the 23rd International Conference on Mining Software Repositories (MSR) - Data and Tool Track, ser. MSR ’26. IEEE / ACM, 2026. [20] google-gemini, “gemini-cli,” https://github.com/google-gemini/ gemini-cli, 2025, accessed: 2026-06-30. [21] IBM, “mcp,” https://github.com/IBM/mcp, 2025, accessed: 2026-06-30. [22] punkpeye, “Awesome mcp clients,” https://github.com/punkpeye/ awesome-mcp-clients, 2025, accessed: 2026-06-30. [23] nanbingxyz, “5ire,” https://github.com/nanbingxyz/5ire, 2025, accessed: 2026-06-30. [24] Block, “goose,” https://github.com/aaif-goose/goose, 2025, accessed: 2026-06-30. [25] spmallick, “learnopencv,” https://github.com/spmallick/learnopencv, 2025, accessed: 2026-06-30.
[26] johnrobinsn, “askit,” https://github.com/johnrobinsn/askit, 2025, accessed: 2026-06-30. [27] mario-andreschak, “Flujo,” https://github.com/mario-andreschak/ FLUJO, 2025, accessed: 2026-06-30. [28] NitroRCr, “Aiaw,” https://github.com/NitroRCr/AIaW, 2025, accessed: 2026-06-30. [29] autohandai, “code-cli,” https://github.com/autohandai/code-cli, 2025, accessed: 2026-06-30. [30] AstrBotDevs, “Astrbot,” https://github.com/AstrBotDevs/AstrBot, 2025, accessed: 2026-06-30. [31] kirillsaidov, “ollama-mcp-example,” https://github.com/kirillsaidov/ ollama-mcp-example, 2025, accessed: 2026-06-30. [32] NCC Group, “http-mcp-bridge,” https://github.com/nccgroup/ http-mcp-bridge, 2025, accessed: 2026-06-30. [33] S. Baltes et al., “Evaluation guidelines for empirical studies in software engineering involving large language models,” arXiv preprint, 2025. [34] N. A. Ernst and C. Treude, “Genai is no silver bullet for qualitative research in software engineering,” arXiv preprint arXiv:2603.08951, 2026. [35] Z. Lin, B. Ruan, J. Liu, and W. Zhao, “A Large-Scale Evolvable Dataset for Model Context Protocol Ecosystem and Security Analysis,” ArXiv, vol. abs/2506.23474, jun 2025. [36] H. Guo, Y. Hao, Y. Zhang, M. Xu, P. Lyu, J. Chen, and X. Cheng, “A Measurement Study of Model Context Protocol,” ArXiv, vol. abs/2509.25292, sep 2025. [37] M. Stein, “How are AI agents used? Evidence from 177,000 MCP tools,” arXiv preprint arXiv:2603.23802, 2026. [38] A. Singh, A. Ehtesham, S. Kumar, and T. T. Khoei, “A survey of the Model Context Protocol (MCP): Standardizing Context to Enhance Large Language Models (LLMs),” Preprints, apr 2025. [39] A. Shostack, Threat Modeling: Designing for Security. Wiley, 2014.