Why MCP Is Surging, and How to Use It in Design, Video and 3D Work

The Model Context Protocol (MCP) is an open standard for connecting AI applications to outside systems. The official documentation compares it to a USB-C port for AI apps. Just as one connector replaced a drawer of incompatible cables, MCP gives AI apps a single way to reach local files and databases, tools such as search engines and calculators, and prompts built for specific tasks.

The use cases in the docs sit close to the work of creators and developers. Claude Code generates an entire web app from a Figma design. An AI model builds a 3D design in Blender and sends it to a 3D printer. An agent reaches Google Calendar and Notion and works like a personal assistant. The docs list Claude, ChatGPT, Visual Studio Code, and Cursor among supported clients. The core promise is that you build a server once and reuse it across many AI apps.

Mentions jumped from 1 to 11 in a week, putting MCP in the surge stage

Muckle's radar scores MCP at 61.5/100 and places it in the surge stage. Mentions over the past 7 days reached 11, up from 1 in the 7 days before, so 11 of the 16 mentions in the last 30 days landed in the most recent week. Three channels carried the topic, and the number of people and sites mentioning it rose to 11 from 1 the week before. MCP was first picked up on March 7, 2025, which makes this less a new concept than a known standard being revisited in several places at once. The absolute counts are small, so this is not a mass-market explosion. What gives the signal substance is that independent sources raised the same topic in the same week.

Recent mentions fall into five groups: security write-ups on tool-description tampering and supply-chain risk; pieces on specification revisions and client compatibility; enterprise cases that turned internal APIs into scoped agent tools; attempts to extend MCP into browser environments; and setup guides for developers in Korea alongside announcements of MCP launches from Korean services. For what actually changed in the revised specification, read the spec pages in the official docs. This report does not stand in for that list.

Scale figures help but need care. Academic literature cites more than 8 million weekly SDK downloads in 2025, and more than 10,000 active servers and 97 million monthly downloads in early 2026. Another study reports 64,611 unique servers, depending on how they were collected. Units, dates, and counting definitions differ, so none of this converts into a growth rate or a real user count. One study of Claude Code's architecture lists MCP as one of four extension mechanisms (MCP, plugins, skills, hooks), which suggests MCP has become a default extension path inside developer tools.

Servers expose capabilities and AI apps call them

MCP uses a client-server design. When the client inside an AI app connects to a server, the server offers three kinds of things: tools, which are actions it can run; resources, which are data it can read; and prompts, which are templates for specific tasks. Connect several servers at once and the model can combine their tools into a workflow. Academic literature describes the communication layer as JSON-RPC based and divides a server's lifecycle into creation, operation, and update, analyzing security and privacy risks at each stage.

One practical point matters more than the rest. The model chooses tools based on the descriptions the server provides. A thin description leads to the wrong tool being called, or the right one never being found. That is why the same server can feel very different depending on the model and client pairing.

The official docs offer three starting points: building a server that exposes data and tools, building an app that connects to servers, and building MCP Apps, which are interactive apps that run inside an AI client. For current details on connection order, transports, and authentication, treat the Architecture and Security pages as the reference.

Where it fits in design, 3D, content operations, and server development

UI design to code. Attach a server connected to your design tool to a coding agent, point it at a specific frame, and ask for a component implementation. After the generated code lands in the project, a designer compares it with the mockup for visual differences. The official example goes as far as a full web app, but cutting the first pass down to one screen or one component makes review easier. Giving the design file read-only access is the safer setup.

3D scene work. If a Blender server exposes scene creation and editing as tools, you can ask in plain language for a base shape, then keep going with material and layout adjustments. The docs describe a scenario where a 3D design is made and then printed. Start from a copy of the working file, and add a confirmation step at every point where the scene changes or a file is exported.

Video and content operations. A realistic use is reading calendar and notes tools to gather shoot schedules, storyboard notes, and asset lists into a draft checklist. A benchmark covering personal tools such as social and collaboration accounts reports that even current agents struggle badly with personalized tool use. Hand over lookup and organizing first. Actions that are hard to undo, such as publishing, deleting, or sending invitations, should wait for a human to approve.

Exposing your own service as tools. An industry study that analyzed 15 servers sorted recurring structures into five patterns: resource gateway, tool orchestrator, stateful session server, proxy aggregator, and domain-specific adapter. A team that wants to expose an asset management API or a render queue can reasonably start from a domain-specific adapter and grow the tool count slowly. A research framework that converts repositories into MCP services automatically has also been proposed, but it is a proposal, not an adoption story.

Comparing MCP with function calling, direct integrations, and browser agents

The literature describes function calling as a way to put external data or API results into the model's context, and MCP as an attempt to standardize tool interfaces that used to differ by provider. The two are described as complementary. MCP also turns up alongside A2A, which handles delegation between agents, while MCP covers tool calls.

Two research results are useful for comparison. In an environment of more than 18,000 tools wrapping real services' REST APIs, models using tool search matched or beat browser-based agents. Smaller models, though, did not make full use of the retrieved tools, and even top models struggled in complex enterprise settings. In another experiment with four conditions (two coding agents and two task sets), a single code-execution tool was the cheapest or statistically tied on cost in three conditions, with the same pass rate. In the remaining condition it was directionally 14.4% more expensive, though not statistically significant. Both results are tied to their evaluation conditions, so neither works as a complete selection rule.

Accuracy falls as tools multiply, and the security review widens

Tool count and description quality. One industry paper reports that selection accuracy falls as the number of tools per context grows, dropping below 90% at 10 to 15 tools for Claude Haiku 4.5 and 20 to 30 for Sonnet 4. A study of 856 tools found that 97.1% of tool descriptions had at least one defect. Improving the descriptions raised the median task success rate by 5.85 percentage points, but execution steps grew by 67.46%, and in 16.67% of cases performance got worse. Longer descriptions are not automatically better, so test against representative tasks and refine from there.

Cost and success rate. In a benchmark across 11 servers and 6 domains, input tokens climbed quickly as interaction steps increased, and agents often did not know exactly how to use a given server. Top success rates by benchmark split widely, at 78.95% and 43.72%. Tasks, server setups, and grading methods differ, so these numbers cannot be compared directly, and the automatic grading in the first benchmark agreed with human reviewers 81% of the time.

Security. Researchers were able to upload malicious MCP servers to three widely used aggregation platforms, and a study with 20 participants reported that users had trouble identifying them. One benchmark found every model it evaluated vulnerable to attacks aimed at MCP. An analysis of 1,899 open-source servers reported general vulnerabilities at 7.2% and tool poisoning at 5.5%, and static analysis of 10,655 servers found sensitive information exposure above 10%. On the other side, a study that manually verified existing scanners' alerts found that fewer than half of the sampled alerts were true positives. These figures come from different samples and measure different things, so they cannot be merged into a single risk rate, and static analysis results are not leak rates during real execution. They are still reason enough to check whether keys, tokens, and personal data slip out through tool results and logs. One report also scanned about 2,000 servers and found none with authentication, so check the authentication setup first on any server exposed to the outside.

Licenses and requirements. The specification, the SDKs, and individual servers each carry their own license and runtime requirements. Check the repository description of the server and SDK you plan to use for its license, supported clients, and required runtime. Security extensions proposed in research papers are researchers' proposals, not changes to the official specification, and most rest on the authors' own experiments.

Ethics and permissions. A server accesses accounts and acts on a user's behalf. Limit the client's scope to the accounts and operations it needs, and before opening files that hold other people's assets or personal data to a server, work out what you are allowed to share.

Start with one small task and add tools gradually

1. Read the overview and Architecture pages in the official docs to get the relationship between servers, clients, tools, resources, and prompts.
2. In a client you already use (Claude, ChatGPT, Visual Studio Code, Cursor, or another app listed as supported), connect just one server. Pick one with a clear origin that is actively maintained.
3. Choose one read-heavy task and check the tool list, the call results, and the number of steps taken. Compare time, cost, and success rate against your existing API integration or manual process.
4. For tools that change state (publishing, deleting, writing files), turn on approval before execution, and grant only the minimum permissions needed.
5. If you need to expose your own capabilities, read the Build servers and Security pages in the docs, release a small set of needed tools first, and test descriptions and results against representative tasks.

Muckle's view: begin with read-heavy work and grow the tool count slowly

MCP is already a practical candidate, because the way AI apps reach design, 3D, scheduling, and in-house APIs is being standardized. At the same time, accuracy falls as tools multiply and server trustworthiness is a standing concern, so for now the sensible move is to confirm value on reversible work such as lookups and first drafts. The jump in mentions over a single week reads as security and specification-revision debates heating up together, so before adopting, check the Security page in the official docs and the repository description of the server you plan to use.