MCP's win is economic, not technical novelty: it collapsed the integration matrix. Every AI app needing every tool used to mean bespoke pairs. With a standard interface, capability authors write one server and every compliant host benefits. That is also why the ecosystem's real currency became server quality — thousands exist, of wildly uneven provenance. So the practitioner's problem moved from "how do I integrate" to "what should I trust." Our evaluation guide is built for exactly that question, and the servers page maps the landscape's categories.
Protocol questions
What are the pieces: host, client, server?
The host is the AI application (a chat app, IDE, or agent). It runs one or more clients, each holding a connection to one server. Servers expose three main primitives: tools (functions the model may call), resources (data it may read), and prompts (reusable templates). Each is described so any client can discover it. The naming trips people: "server" includes tiny local processes; a filesystem server on your laptop is still a server.
How do MCP servers connect — locally or over the network?
Both, by design: local transports (stdio) serve servers running on your machine, and HTTP-based transports serve remote ones. The spec's auth guidance applies to the remote case. The transport choice is a real security boundary: local servers inherit your machine's trust model, while remote ones add network, auth, and multi-tenant questions. Check the current spec at modelcontextprotocol.io for transport details, which have evolved by revision.
Who maintains MCP, and how standard is it really?
It launched from Anthropic as an open project in November 2024. The consequential fact is adoption: major model providers and dev tools moved to support it through 2025. That is what makes a protocol a standard in practice. Governance and spec revisions are public on the official site and repos. For anything load-bearing, read the spec version your stack actually implements rather than any secondary summary — this site included.