代理框架與安全
Testing 1,723 MCP Applications: Nearly Two-Thirds Did Not Require Approval Before Tool Execution
The first large-scale study of MCP clients found that official SDKs and file-based configuration have become mainstream, but only 37.2% of applications require blocking approval. The protocol has standardized communication formats, but permissions, configuration, and human oversight have yet to converge into consistent application-layer practices.
An empirical study released on July 28 collected 1,723 applications integrating the Model Context Protocol (MCP) from GitHub and examined how developers configure servers, choose SDKs, and place control checkpoints between humans and agents. The results show that 81.1% use official SDKs and 85.2% store server configuration in files, indicating that MCP’s basic integration paths are beginning to converge. However, no common convention has emerged for configuration file names, making automated discovery, portability, and security auditing more difficult.
More notable is the imbalance among oversight mechanisms: 90.8% of applications retain logs and 77.2% allow servers to be enabled or disabled, yet only 37.2% implement blocking approval before a tool is actually executed. In other words, although most applications support retrospective tracing and can disable an entire group of tools at once, models can generally invoke tools directly once they are enabled. For agents with permissions to write files, execute commands, or access external APIs, these three controls are not equivalent. Logs cannot retract data that has already been sent, while server-level switches make it difficult to restrict individual calls containing high-risk parameters.
The official MCP specification primarily defines JSON-RPC messages, lifecycle management, authorization, and server-provided capabilities such as tools, resources, and prompts. It does not prescribe a standardized approval interface or configuration format for applications. The study therefore recommends treating client-side conventions as a standardization issue as well. Engineering teams can begin by assigning a risk level to each tool, requiring synchronous approval for write, payment, deletion, and credential operations, and including call parameters and results in redactable audit logs.
These figures cannot be considered representative of the entire MCP ecosystem. The sample includes only public GitHub repositories, and the classification process was assisted by an LLM. Private enterprise applications may employ different controls. Future research should examine whether newer stateless transports and SDK updates lead to portable permission policies, and whether blocking approvals actually validate parameters rather than merely displaying a generic tool name.