Making sense of MCP

You ask an AI assistant a question. It gives you a useful answer. Then you ask it to check your own data, and suddenly you're copying tables into the chat, explaining where the files live, and trying to keep everything up to date.

That gap is what interests me. An assistant becomes much more useful when it can work with the information and tools we already use. MCP is one way to make that connection.

The problem behind the acronym

MCP stands for Model Context Protocol. It's an open standard for connecting AI applications to external tools and information.

Think about a team using a database, a code repository, and a collection of documents. Each assistant application needs a way to reach those systems. Building a separate connector for every combination quickly becomes a lot of repeated work.

MCP gives those connections a common interface. A developer can expose a system through an MCP server, and compatible applications can connect to it. There is still integration work to do, but more of it can be reused.

A little history

Anthropic introduced MCP on 25 November 2024. It was created by David Soria Parra and Justin Spahr-Summers, with an initial release that included the specification, development tools, and support in Claude Desktop.

The starting problem was practical: assistants were becoming more capable, while the information they needed was scattered across different systems. The connection to that information was becoming a problem of its own.

Through 2025, support spread across applications including Claude, ChatGPT, and Cursor. On 9 December, Anthropic announced that MCP was joining the Agentic AI Foundation, a new home under the Linux Foundation. The technical maintainers would continue their work, with a commitment to keeping the protocol open and independent of any one vendor.

For me, that shared direction is part of the appeal. A common interface becomes much more useful when different tools are willing to speak it.

What actually connects?

The architecture has three main parts. The application you're using is the host. It manages an MCP client, which connects to a server. The server exposes a particular set of capabilities: perhaps reading documents, looking up data, or carrying out an operation.

Tools have names, descriptions, and defined inputs. The application can discover what's available, request a tool call, and receive the result. MCP also supports resources that provide context and reusable prompt templates.

The useful bit is the division of responsibility. The application handles the conversation and coordinates access. The server knows how to work with its particular system.

Permissions still need care, especially when a tool can change something. I want to be able to explore a dataset with a clear understanding of what the assistant can read, what it can write, and which actions deserve my approval.

A small example: ArcticDB

One example from my own work is arcticdb_mcp, an MCP server for reading and writing data in ArcticDB.

Imagine a time series stored in a database. You might want to find the available datasets, inspect the most recent rows, or look at a particular date range. The server exposes tools for those operations, so a compatible assistant can request the data and use the returned results in the conversation.

It also exposes operations for updates, versions, and snapshots. ArcticDB continues to handle the data itself; the MCP server gives the assistant's application a structured way to interact with it.

That makes a fairly abstract protocol easier to picture: a question in the conversation leads to a specific operation against a real system.

The details can have their own post

I’ll come back to arcticdb_mcp in a more technical post: how the tools are defined, how queries reach ArcticDB, and the choices involved in handling data and write operations.

There’s plenty to unpack there. For this first piece, I wanted to start with the connection itself—and why I think it's worth building.