10,000 servers in a year: MCP becomes the common socket between LLMs and client systems

Just over a year after Anthropic announced the Model Context Protocol on 25 November 2024, the protocol had more than 10,000 public servers in operation. Then, on 9 December 2025, Anthropic handed it to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. A connection standard that began as one company’s blog post now sits with a neutral foundation.

For a Forward Deployed Engineer, that number is less market news than a job description. Work at a client site nearly always comes down to one question: how do you let a model read data held in the client’s internal database, ticketing system or ERP, none of which were ever designed to talk to an LLM? Until recently, every such case meant a hand-written integration layer, tied to one particular chat application.

The official documentation defines MCP as an open-source standard for connecting AI applications to external systems, and likens it to a USB-C port for AI applications.

Three roles, three kinds of feature, one idea borrowed from editors

The current spec (version 2026-07-28) is built on JSON-RPC 2.0 and has three roles: host, client and server. The host is the LLM application that opens the connection. The server is what you write to expose the client’s systems to the model. A server offers three kinds of feature: resources, prompts and tools. Tools are the functions the model can execute.

Host (LLM application, opens the connection)
   Client  ⇄  JSON-RPC 2.0  ⇄  Server (you write it)
                                  ├─ resources · prompts · tools
                                  └─ customer's database / ticket / ERP

(Diagram labels: Host = the LLM application, which opens the connection; Server = what you write; bottom line = the client’s database / ticketing / ERP.)

The spec says it took its inspiration from the Language Server Protocol, and that explains why it spread so fast. LSP lets one language server work with every editor. MCP does the same for AI: one server, many hosts. The documentation lists Claude, ChatGPT, VS Code and Cursor as supported, with the promise that you build once and integrate everywhere.

Take an example. You are sent to a logistics company that wants its operations team to ask about order status in plain language. Instead of writing a plugin for one chat application, you build an MCP server that runs over stdio and exposes a single tool. The tool takes an order number and queries the client’s database. The database credentials come from environment variables, as the spec recommends for stdio.

The host connects and lists the tools. When a user asks a question, the model decides to call the tool, and the host asks the user for permission before running it.

Now suppose the analytics team wants to call the same server from Cursor while writing SQL. The documentation promises you will not have to rewrite the connection. You should test for yourself what actually has to change between the two hosts. In enterprise integration, the hard part is not getting it working once. It is keeping it working when the client switches or adds chat applications, and that is the problem MCP goes after.

The real limits are permissions and responsibility, not the protocol

The part FDEs should read most closely is the spec’s security stance. Tools count as arbitrary code execution, and the host must get the user’s explicit consent before calling any tool. With enterprise clients, that means designing tools that are narrow and separate, such as one tool for reading and another for writing. The host’s permission prompt then means something to the user and does not become a habit of clicking “Allow”.

Authorisation in MCP is optional, and how it works depends on the transport you choose.

	stdio	HTTP
Authorisation under the spec	Does not follow the spec’s authorisation mechanism; credentials come from the environment	OAuth 2.1
Typical scenario at the client site	Server runs on each employee’s machine	Central server serves a whole department
What to agree with the client’s IT team	Who gets the environment variables, and where they are stored	Which identity provider, and which scopes for each tool

In practice, the same server can run over stdio on employees’ machines or over HTTP centrally for a department, and each choice brings its own authorisation model. Have that conversation with the client’s IT team in the first meeting.

MCP also promises nothing about data quality, how accurately the model picks tools, or how clean the client’s legacy schema is. It standardises the socket, not the current. The spec and documentation are public on GitHub under the MIT licence, so any question about what the protocol does can be checked at the source rather than taken from second-hand write-ups.

If you are starting out, a sensible order is JSON-RPC 2.0 first, then the LSP mental model, then OAuth 2.1 basics, and only then writing a server. When applying for jobs, a repo with a working MCP server on a realistic mock enterprise schema says more than any line on a CV claiming “agent experience”.

And when an FDE job description mentions “connecting LLMs to internal systems”, expect that building or running MCP servers is very likely part of the role.

The protocol has passed from one company to a neutral foundation. The rest of the work, turning those 10,000-plus public sockets into something clients will actually switch on, falls to the people on site.