Why I'm Excited About MCP

Over the past few months I have been going deeper into one of the most useful pieces of AI infrastructure I have come across: the Model Context Protocol, or MCP. If you work with language models, whether you are building copilots, internal tools, or side projects, it is worth knowing about.

Models are capable, and isolated

The limitation I have run into again and again is simple: the model is smart, but it does not know anything unless you feed it the right context. Documents, databases, tools, workflows. Getting that context into the model securely and flexibly has always been a headache.

MCP is a standardized protocol that closes that gap. With it you can expose a folder of files to your assistant as resources, give it a set of functions it can call such as running a SQL query or sending an email, and offer pre-written prompts that guide interactions or define workflows. All through one clean protocol that works with any compliant server or client. No hacks and no custom glue code.

My first experiment

I built a lightweight MCP server in Python, added a run_query tool to safely reach my PostgreSQL database, and ran it locally with the MCP dev tools. From there I could send test queries and simulate model interactions straight through the protocol. No frontend, no UI, just structured data in and out.

The reason that took an afternoon rather than a week is how little the SDK asks for. Install it:

pip install "mcp[cli]"
# or, with uv:
uv add "mcp[cli]"

A server is then a couple of decorated functions. This is the shape of it, straight from the SDK's own quickstart:

from mcp.server import MCPServer

mcp = MCPServer("Demo")


@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b


@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"

That is the whole server. There is no JSON Schema to write, because the type hints a: int, b: int are the schema. There is no request parsing, no validation code, and no protocol handling. The docstring becomes the description the model reads to decide whether to call the tool, which means writing a clear one is a real part of the work.

You run it against the MCP Inspector to poke at it before wiring up any client:

uv run mcp dev server.py

Swap add for a function that opens a database connection and runs a parameterised query, and you have roughly what I built. That gave me a way to let the model talk to my data, run logic, and explain the results, all in structured JSON.

What makes it work

• It respects boundaries. You control what the model sees and which tools it can run. Nothing happens without your say-so, and the surface is exactly the functions you decorated.
• It is modular. Build only what you need. There is no large framework to adopt first.
• It is the right shape. Context, control, and composability are exactly what agent-based systems need in order to work.

The boundary point is worth taking seriously rather than treating as a feature list item. A tool named run_query that accepts arbitrary SQL is a very different security proposition from one that accepts a customer ID. The protocol gives you the control; deciding how narrow to make each tool is still your job.

For me AI has never been only about the technology. It is about building tools that help people do things better, and MCP is what gets the right context to a model at the right time, in the right way. I am genuinely interested to see where it goes, and I plan to keep building with it.

If you want to try it, I made a custom ChatGPT assistant for MCP, built entirely from the official docs. It walks through MCP step by step, helps you build clients or servers faster, and helps you debug an implementation.