David Soria Parra

David Soria Parra is an Anthropic Member of Technical Staff and co-creator, with Justin Spahr-Summers, of the [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) (MCP). Released as open source on November 25, 2024, MCP gives AI applications a common way to connect to external tools and data. It addresses a practical engineering problem: building a separate integration for every application and data source repeats much of the same work.[1][10][2]

As of September 2026, Soria Parra shares MCP’s [lead-maintainer responsibilities](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) with Den Delimarsky and chairs the Agentic AI Foundation’s technical committee. His responsibilities encompass both the protocol and the governance of its open-source community.[6][10][7]

In their April 2025 joint interview, the MCP creators recalled the friction of copying information between Claude Desktop and an IDE during internal developer-tooling work in July 2024. Desktop features and IDE access to the filesystem were useful in different ways, but moving between them required manual transfers. Soria Parra later described his contribution and Spahr-Summers’s role in a 2026 OpenUK interview: “While the idea was mine, Justin really was the one who believed in it being important and helped to drive a lot of the initial implementation.”[3][2]

The reusable unit is the connection. Developers expose tools or data through MCP servers; clients in AI applications connect to those servers using the same protocol. Instead of separately connecting each of N applications to each of M integrations, application developers and integration developers implement a common interface. Anthropic’s launch paired the specification and SDKs with local Claude Desktop support and servers for systems including GitHub, Google Drive, and Slack. The capabilities exposed and the access controls still determine what a particular connection can do.[1][2]

Soria Parra regards openness as a requirement for the ecosystem MCP needs. In the OpenUK interview, he argued that developers must be able to implement both clients and servers freely, with an open specification defining their communication and open-source SDKs making implementation easier. His stated aim was to let people bring their own workflows to AI across IDEs, desktop applications, and websites.[2]

He explained Anthropic’s donation of MCP to the Linux Foundation as a way to preserve vendor neutrality and avoid trademark or licensing risks. In his view, open standards should keep AI companies competing on model quality and safety rather than control of tools. That position does not extend to a preference for open models: in the same interview, he expressed Anthropic’s belief that proprietary models were safest for widespread enterprise development.[2]

In his April 2026 maintainer update, Soria Parra announced Delimarsky as a fellow lead maintainer and Clare Liguori as a core maintainer. He explained that MCP’s governance model was intended to let the project grow without any one person becoming a bottleneck. He credited Delimarsky’s authorization and security contributions, including co-authoring the authorization specification and leading the November 2025 specification release.[7]

Soria Parra and Delimarsky’s August 2026 roadmap reported that the July 28 release had removed protocol-level sessions and the initialization handshake. The underlying scaling problem was concrete: when a client’s session state belongs to one backend server, a load balancer must keep sending requests to that instance or operators must arrange to share the state. Self-contained requests let different instances process requests independently. The accepted stateless-MCP design, authored by Jonathan Hefner, Mark Roth, Shaun Smith, Harvey Tuch, and Kurtis Van Gent, separated discovery and per-request metadata from the former handshake. Applications can still retain state above a stateless protocol.[8][9]

Their August roadmap set priorities for longer-running agents and delegated authority. It proposed improving how tasks, progress notifications, and events work together, and standardizing identity for agents running unattended or acting on behalf of users. These were plans for future work, built around existing identity and authorization standards.[8]

The roadmap also proposed progressive tool discovery: a server would expose a small entry point and reveal more of its catalog as a conversation narrowed. Soria Parra and Delimarsky identified large tool catalogs as a cost and selection problem for models. They also prioritized clearer tool-result contracts and SDK documentation, noting that developers increasingly use coding agents to build against MCP libraries.[8]

Before MCP, Soria Parra worked on developer tooling, source control, and static analysis at Facebook and Meta for approximately ten years, according to his 2026 recollection. His earlier PHP and Mercurial work supplies context for that career in the infrastructure developers use.[2]

Soria Parra traces his start in open source to PHP contributors who mentored him at Mayflower GmbH in Munich, where he worked part-time. He recalls beginning with patches, documentation, and libraries, then obtaining a university-era job at Sun Microsystems optimizing PHP for SPARC processors because of those contributions. He also recalls serving as release manager for PHP 5.4 and 5.5. Work in the Mercurial community subsequently connected him with someone building Facebook’s source-control team, leading to his move there.[2]

On July 30, 2011, he authored PHP’s [proposal to choose a distributed version-control system](https://wiki.php.net/rfc/dvcs). It compared Git and Mercurial against Subversion’s network dependence, slow operations, and difficult merging, while acknowledging tradeoffs such as losing partial directory checkouts. The proposed contributor workflow used pull requests, local merging, and synchronization with PHP’s own repository.[5]

Soria Parra personally preferred Mercurial, arguing that its concepts were easier for Subversion users to learn and that extensions offered flexibility for PHP’s tooling. He nevertheless identified GitHub’s large community and ease of participation as Git’s strongest advantage. The project accepted Git, with voting ending on September 7, 2011.[5]