--- title: "What Is MCP? The Model Context Protocol Explained" excerpt: "MCP is an open standard that lets AI agents call external tools through one interface instead of a bespoke integration per tool. Here is what it actually is, what an MCP server does, where it helps, and what it does not solve." metaDescription: "What is MCP? The Model Context Protocol explained: what an MCP server does, how agents call tools through it, why it exists, and its real limits." publishedAt: 2026-07-30 author: Shiplight AI Team categories: - Guides - Engineering tags: - mcp - model-context-protocol - mcp-server - coding-agents - ai-tooling metaTitle: "What Is MCP? Model Context Protocol Explained" featuredImage: ./cover.png featuredImageAlt: "Illustrated Shiplight blog cover: a central glowing protocol hub connecting one AI agent outward to several distinct tool cards through identical connectors." --- An AI model on its own can only produce text. To do anything in the world, read a file, query a database, open a browser, it needs tools, and something has to define how it asks for them. The Model Context Protocol is the open standard that settled that question, and it is why a tool built once now works across most AI clients rather than one. This guide covers what MCP is, what an MCP server actually does, why the standard mattered enough to win, where it genuinely helps, and what it does not solve. ## The short definition **MCP (Model Context Protocol) is an open standard that defines how AI applications connect to external tools and data sources.** An AI client speaks MCP on one side. A server implements MCP and exposes some capability on the other. Neither has to know anything specific about the other. The comparison people reach for is USB. Before a common connector, every peripheral shipped its own cable and its own driver. After, one port took anything. MCP is the same move applied to giving AI models hands. ## What an MCP server is An MCP server is a program that exposes capabilities to an AI client over the protocol. It usually offers some combination of three things: - **Tools:** actions the model can invoke. Read a file, run a query, click a button in a browser. - **Resources:** data the model can read. Documents, database records, logs. - **Prompts:** reusable templates the client can surface to the user. Servers run either locally on your machine, communicating over standard input and output, or remotely over HTTP. A local server is the common case for developer tooling, because it can touch your filesystem and your running application without anything leaving your machine. Configuring one is typically a few lines in your client's config file: ```json { "mcpServers": { "shiplight": { "command": "npx", "args": ["-y", "@shiplight/mcp"] } } } ``` Restart the client, and the server's tools appear in the model's available toolset. From then on the model can decide to call them. ## Why the standard mattered Before MCP, connecting a model to a tool meant writing an integration for that specific pairing. Ten clients and ten tools implied a hundred integrations, and every new client started from zero. The protocol collapses that to twenty. Build a server once and every MCP-capable client can use it. Build a client once and the whole existing server ecosystem works on day one. That is the entire value proposition, and it is why adoption moved quickly. In practice it means the tooling you invest in is not a bet on one vendor's agent surviving. When Google retired Gemini CLI in June 2026 and moved developers to Antigravity CLI, workflows wired through MCP carried over. Workflows built against that specific CLI did not. ## What it is actually used for **Developer tooling.** Filesystem access, git operations, running tests, driving a browser. This is the densest part of the ecosystem because it is where agents do the most work. **Data access.** Letting a model query a database or search internal documents without that data being pasted into a prompt. **Browser automation.** Giving an agent a real browser so it can see the application it just changed. See [Playwright MCP](/blog/playwright-mcp) for how that specific case works, including why structured accessibility snapshots beat screenshots. **Team-specific capability.** Internal APIs, deployment tooling, whatever your organization does that a general agent cannot know about. ## What MCP does not solve Worth stating plainly, because the enthusiasm around the protocol tends to skip this. **It is plumbing, not judgment.** MCP defines how a model asks for a tool. It has nothing to say about whether the model should have asked, or whether the result it got back means what it thinks it means. **It does not make an agent's self-assessment trustworthy.** Give an agent a browser through MCP and it can check its own work, which is genuinely valuable. It is still an agent evaluating code it just wrote, from the context that produced it. That is a structural limit no protocol addresses. See [can coding agents test their own code?](/blog/can-coding-agents-test-their-own-code) **It expands your attack surface.** A server runs with whatever permissions you gave it, and the model decides when to call it. Treat installing an MCP server with the same care as installing any dependency that can touch your filesystem or your production data. Prefer servers you can read. **It does not create durable artifacts by itself.** A tool call happens and the result scrolls past. If the point of the call was to verify something, and nothing was written down, tomorrow's regression is uncaught. Turning a one-time check into something that runs on every future change is a separate design decision, and the one most teams skip. That last point is where we do most of our work. [Shiplight](/plugins) exposes browser verification and test generation as MCP tools, and the tests it generates are written into your repository as YAML rather than into a vendor database, so the check survives the session that produced it. ## Getting started Pick a client that speaks MCP, which in 2026 means most of them, including Claude Code, Cursor and Codex. Add a server to its config. Restart. Ask the model to do something that needs the tool. Start with one server rather than ten. The failure mode for newcomers is installing a dozen, watching the model's tool list balloon, and losing the ability to reason about what it is doing. ## Frequently Asked Questions ### What does MCP stand for? Model Context Protocol. It is an open standard defining how AI applications connect to external tools and data sources. ### What is an MCP server? A program that exposes tools, data, or prompt templates to an AI client over the protocol. It runs locally over standard input and output, or remotely over HTTP. ### Is MCP the same as an API? No. An API is an interface to one service; MCP is a standard for how models discover and call tools generally, and most MCP servers wrap APIs. See [MCP vs API](/blog/mcp-vs-api). ### Which AI tools support MCP? Most current agents and assistants, including Claude Code, Cursor, Codex and Antigravity CLI. That breadth is the main practical argument for building tooling on it. ### Is MCP secure? The protocol does not make an unsafe server safe. A server runs with the permissions you grant and the model chooses when to call it, so vet servers as carefully as any dependency with filesystem or production access. ## Related Reading - [MCP vs API](/blog/mcp-vs-api): the distinction people most often get wrong - [Playwright MCP](/blog/playwright-mcp): giving an agent a real browser - [MCP for testing](/blog/mcp-for-testing): why the protocol suits verification work - [How to use MCP for test automation](/blog/mcp-test-automation-workflow): the workflow end to end - [Claude Code testing](/blog/claude-code-testing): a client-specific walkthrough