Source: arXiv preprint — Majeed, Mahmoud, Nadi — 2026-07-28
Summary
While plenty of research has looked at MCP servers, almost none has looked at the applications that actually consume them — the client-side code developers write to wire an LLM app up to MCP tools. This paper mines 1,723 real-world MCP applications from GitHub, derives a taxonomy (MCPAppTax) from a manually-labeled sample, then applies it across the full dataset with an LLM-assisted pipeline. The headline finding: 85.2% of apps configure MCP servers via files and 81.1% use an official SDK to talk to them, but there's no shared naming convention for configuration — every project is inventing its own pattern, application-side, from scratch.
Key Takeaways
- MCP standardizes the server side of the protocol tightly but leaves the application/client side completely open — this study is the first large-scale look at what developers actually do with that freedom.
- 85.2% file-based config and 81.1% official-SDK usage shows strong convergence on how to connect, but the absence of naming conventions shows how you organize that connection is still the wild west — comparable to where npm's package.json was before conventions solidified.
- The paper also characterizes human-in-the-loop mechanisms — how much oversight developers build in before letting an MCP-connected agent actually act — which matters directly for anyone shipping an MCP-based agent into production today.
- This is empirical, not opinion: 1,723 mined repositories is a large enough sample that the "no naming convention yet" finding is a real signal about the ecosystem's maturity, not an anecdote.
Reel Script
Hook (~16s, 36 words): MCP has a spec for how servers should behave. It has no spec for how you're supposed to wire your app up to those servers — and a new study of 1,723 real projects proves nobody's agreed on an answer yet.
Core Concept (~65s, 150 words): Quick primer: MCP, the Model Context Protocol, is the standard that lets an LLM application call external tools — a database, a file system, a search API — through one common interface, instead of every app writing custom glue code for every tool. Think of it like a universal power adapter: MCP defines the plug shape so any tool that speaks MCP can plug into any app that speaks MCP. What MCP doesn't define is what's on your side of the socket — how you store your server configuration, which SDK you use to make the call, how much human approval you require before the agent is allowed to actually execute an action. This paper went looking at real GitHub projects to see what developers do with that freedom, and built a taxonomy — MCPAppTax — to categorize the patterns that emerged.
Hands-On (~50s, 120 words): The concrete numbers: across 1,723 mined MCP applications, 85.2% store their server configuration in a file rather than, say, environment variables or a database, and 81.1% use an official SDK instead of hand-rolling the protocol calls. That's strong agreement on the big decisions. But there's no equivalent number for configuration file naming or structure — meaning if you open ten different MCP projects, you'll likely see ten different ways of organizing the same underlying choice. Picture it as a bar chart: two tall, convergent bars for "file-based config" and "SDK use," next to a wide scatter of tiny bars representing every different naming pattern in use.
Takeaway (~22s, 48 words): If you're building an MCP-based agent right now, don't assume there's an established best practice to copy — there isn't one yet for configuration structure. Pick something file-based, use the official SDK, and document your own convention clearly, because you're currently defining the norm, not following it.