What the Heck is MCP? A Full-Stack Dev's Practical Take

I kept seeing "MCP" pop up everywhere while I was messing around with AI Agent tools. Hermes Agent docs mentioned it, Claude Code had configs for it, Cursor said it was supported too. At first I didn't pay much attention — figured it was just another buzzword. Then one day I needed an AI to query a database, call an API, and read local files, and I realized every tool had its own way of doing integrations. My config files were a mess. That's when it hit me — MCP might actually be solving a real problem.

My site's been up for about a month now, and I've been wrestling with various AI tool integrations the whole time. Today I want to break down what MCP actually is, why it exists, and how to actually use it. No fluff, no marketing speak — just my honest understanding as someone who's been tinkering with this stuff.

The Problem: AI Tool Integration Hell

Before MCP, if you wanted an AI coding assistant to do "real stuff" (not just chat), every tool had its own extension system:

Claude Code: 10 Essential Claude Code Skills That Supercharge Developer Productivity — write Markdown files to define behavior
Cursor: .cursorrules — another custom config format
Hermes Agent vs OpenClaw Architecture Security and Use Cases Compared: Its own tool system and plugin mechanism
VS Code extensions: Each one doing its own thing

Here's the pain: say you build a "check weather" tool and want it to work in both Claude Code and Cursor. Sorry — you need to write two separate adapters. Different formats, different protocols, different connection methods.

It's like every phone brand using their own charger — Lightning, Micro USB, USB-C, all different. You end up carrying three cables everywhere.

MCP is the USB-C.

So What is MCP?

MCP stands for Model Context Protocol. Anthropic proposed it in late 2024 as an open standard. In plain English: it defines a common way for AI models (and AI tools) to connect to external data sources and tools.

Or even simpler:

MCP lets AI talk to external tools in the same "language."

Whether you need to query a database, read files, call an API, or control a browser — if those tools implement the MCP protocol, AI can use them directly. No more writing separate integration code for each tool.

The Core Concepts

There are a few key players in MCP, and honestly it's not complicated:

MCP Server: The provider of capabilities. A "filesystem MCP Server" gives you read/write file access. A "database MCP Server" lets you query databases.

MCP Client: The consumer of capabilities. Usually the AI tool itself — Deep Dive Into Claude Code Core Architecture and Agent Runtime Mechanisms, Hermes Agent, etc.

Transport: How the client and server talk to each other. Two main flavors:

stdio: Communication through standard input/output — great for local tools
HTTP/SSE: Communication over the network — for remote services

That's it. Server provides tools, client calls tools, standard protocol in between.

Why Does MCP Matter?

Back to the original problem: without MCP, every AI tool has its own extension system and developers have to adapt repeatedly.

MCP solves this with standardization. Build once, use everywhere.

Before MCP:

code

1	`Claude Code → write Skills config → call weather API`
2	`Cursor → write .cursorrules → call weather API`
3	`Hermes → write a plugin → call weather API`

Three codebases, three configs, three things to maintain.

With MCP:

code

1	`Write one weather MCP Server → Claude Code / Cursor / Hermes all work`

One implementation, every MCP-compatible client can plug in.

What does this mean for developers? Build one MCP Server, and your tool works with every MCP-supporting AI product out there. The network effect kicks in hard.

What Does an MCP Server Look Like?

Enough theory — let's look at code. An MCP Server is actually pretty simple. Here's a minimal example in Python.

Install the dependency:

bash

1	`pip install mcp`

A basic MCP Server that provides an "addition" tool:

python

# mcp_demo.py
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
 
app = Server("demo-calculator")
 
@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="add",
            description="Calculate the sum of two numbers",
            inputSchema={
                "type": "object",
                "properties": {
                    "a": {"type": "number", "description": "First number"},
                    "b": {"type": "number", "description": "Second number"},
                },
                "required": ["a", "b"],
            },
        )
    ]
 
@app.call_tool()
async def call_tool(name, arguments):
    if name == "add":
        result = arguments["a"] + arguments["b"]
        return [TextContent(type="text", text=str(result))]
 
async def main():
    async with stdio_server() as (read_stream, write_stream):
        await app.run(read_stream, write_stream, app.create_initialization_options())
 
if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

That's it — a working MCP Server in a handful of lines. It provides an add tool that takes two numbers and returns their sum.

Obviously this is just a demo. In real life you'd hook it up to anything: databases, file systems, APIs, even hardware devices.

How Do You Configure It?

You've got a Server — now how do AI tools find it? Through config files. Different clients have slightly different formats, but the core is the same: tell the client how to launch the Server.

For Claude Code, create .mcp.json in your project root:

json

{
  "mcpServers": {
    "calculator": {
      "command": "python",
      "args": ["mcp_demo.py"]
    }
  }
}

Hermes Agent goes in config.yaml:

yaml

mcp:
  servers:
    calculator:
      command: python
      args: [mcp_demo.py]

Cursor uses .cursor/mcp.json — same idea, different file.

The key message: tell the client what command to run to start the Server. The client handles everything else — lifecycle management, communication, shutdown. You don't have to worry about any of that.

Existing MCP Servers Worth Using

Building your own Server is great, but even better — tons of people have already built them. The MCP ecosystem is growing fast, and GitHub is full of ready-to-use Servers.

Here are some I've found genuinely useful:

Filesystem

The most common one. Lets AI read and write your local files.

bash

1	`npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir`

One command and AI can access files in the specified directory. It has path restrictions — it won't let the AI roam your entire filesystem. Good safety design, honestly.

Database Queries

Several options:

PostgreSQL: @modelcontextprotocol/server-postgres
SQLite: @modelcontextprotocol/server-sqlite
MySQL: Community implementations available

Configure the connection string, and AI can write SQL queries, pull data, do analysis. Super useful for backend devs.

Web Search

bash

1	`npx -y @anthropic/server-brave-search`

Hook up the Brave Search API and AI can search the internet. No more relying on the AI's "memory" — it can look up real-time information.

GitHub

bash

1	`npx -y @modelcontextprotocol/server-github`

Let AI interact with GitHub: browse repos, create Issues, submit PRs, read code. Combined with AI's code understanding, it's great for Code Review workflows.

Browser Automation

The Playwright MCP Server lets AI control a browser: open pages, click buttons, fill forms, take screenshots. Useful for automated testing or scraping scenarios.

And More

Slack, Google Drive, Notion, Docker, Kubernetes — you name it, someone's probably built an MCP Server for it. The community's creativity is honestly impressive.

Search mcp server on GitHub or check the official MCP servers repo for the full list.

The Pits I Fell Into

Everything sounds great on paper. But in practice, there are definitely some gotchas. Let me rant about a few.

Pit 1: Docs Don't Match the Version

MCP is still evolving fast, and the Python SDK changes frequently. A lot of tutorials online use outdated APIs. I copied code from a blog post and got a bunch of ImportErrors because the package API had already changed.

Fix: Read the official docs and the GitHub README. Don't trust random blog posts.

Pit 2: stdio vs HTTP Confusion

MCP has two transport modes. Some Servers only support one. If your client expects stdio but the Server only offers HTTP, connection fails.

I wasted half a day on this before realizing the transport mode was wrong.

Pit 3: Permission Nightmares

The filesystem MCP Server has path restrictions, but some Servers aren't as careful with security. If you configure a database MCP Server, AI gets the ability to execute SQL — including DROP TABLE.

In production environments, pay close attention to permissions. Read-only access, least privilege principle — do it properly.

Pit 4: Debugging is Painful

MCP communication uses JSON-RPC, and error messages aren't always the most helpful. With stdio mode especially, you can't see the communication — you have to rely on client logs.

Tip: enable verbose logging during development, or use the MCP Inspector (official debugging tool) to inspect the communication.

MCP vs Function Calling

I was confused about this at first too. Function Calling (from OpenAI) lets GPT call functions. MCP also lets AI call tools. What's the difference?

In short:

| Aspect | Function Calling | MCP | |--------|-----------------|-----| | Definition | Tools defined in API requests | Independent Server process | | Reusability | Tied to specific API calls | Standalone process, works with any client | | Runtime | AI returns call params, your code executes | Server runs independently, client calls via protocol | | Ecosystem | Each provider has different format | Unified standard, cross-platform |

Function Calling is more like "AI tells you what function it wants to call and with what parameters" — your code still does the actual execution. MCP is an independent service process that AI communicates with through a standard protocol.

They're not competing — they're at different layers. Function Calling is a model capability. MCP is an application protocol.

What's It Actually Like to Use?

Enough theory. What's the day-to-day experience?

My current MCP Server setup:

Filesystem: AI can read/write project files
GitHub: Browse Issues, do Code Review
Brave Search: Search technical docs

The workflow looks something like this:

I tell the AI: "Look at this Issue and figure out what's wrong"
AI reads the Issue content via GitHub MCP Server
AI reads related code via filesystem MCP Server
Analysis done — it gives fix suggestions or directly modifies code
After I confirm, AI can submit a PR via GitHub MCP Server

The whole thing is driven by natural language. I describe what I need, and the AI decides which tools to use. Way more efficient than manually doing each step.

It's not perfect yet — sometimes the AI picks the wrong tool or fills in parameters incorrectly. But the direction is right, and these issues will shrink as models get better.

Should You Start Using MCP Now?

My take: if you're using AI coding tools (Claude Code, Cursor, Hermes, whatever), you can start playing with MCP now. No need to set up everything at once — start with filesystem and search, the two most practical ones.

If you're a tool developer, consider building an MCP Server for your tool. The ecosystem is still young, and early entrants get more visibility.

If you just chat with AI occasionally and write some articles, MCP probably isn't urgent for you. It mainly solves the AI-to-external-tools integration problem, which doesn't matter much for pure chat use cases.

What's Next

I'm planning a follow-up article — a hands-on guide to building a useful MCP Server from scratch, like connecting to a popular third-party API. Stay tuned for that.

Also want to dig deeper into MCP's security mechanisms. Letting AI operate external systems means security can't be an afterthought. That's a rabbit hole I'll explore later.

Drop a comment if you've got questions. And if you're also playing with MCP, I'd love to hear about your setup and the issues you've run into 😄

1	`# mcp_demo.py`
2	`from mcp.server import Server`
3	`from mcp.server.stdio import stdio_server`
4	`from mcp.types import Tool, TextContent`
5
6	`app = Server("demo-calculator")`
7
8	`@app.list_tools()`
9	`async def list_tools():`
10	`return [`
11	`Tool(`
12	`name="add",`
13	`description="Calculate the sum of two numbers",`
14	`inputSchema={`
15	`"type": "object",`
16	`"properties": {`
17	`"a": {"type": "number", "description": "First number"},`
18	`"b": {"type": "number", "description": "Second number"},`
19	`},`
20	`"required": ["a", "b"],`
21	`},`
22	`)`
23	`]`
24
25	`@app.call_tool()`
26	`async def call_tool(name, arguments):`
27	`if name == "add":`
28	`result = arguments["a"] + arguments["b"]`
29	`return [TextContent(type="text", text=str(result))]`
30
31	`async def main():`
32	`async with stdio_server() as (read_stream, write_stream):`
33	`await app.run(read_stream, write_stream, app.create_initialization_options())`
34
35	`if __name__ == "__main__":`
36	`import asyncio`
37	`asyncio.run(main())`

1	`{`
2	`"mcpServers": {`
3	`"calculator": {`
4	`"command": "python",`
5	`"args": ["mcp_demo.py"]`
6	`}`
7	`}`
8	`}`

1	`mcp:`
2	`servers:`
3	`calculator:`
4	`command: python`
5	`args: [mcp_demo.py]`