uptime · 1416 days · 41 posts published · last deploy 1 hour, 42 minutes ago build:passing rss
~ / software-web / what-is-an-mcp-server-model-context-protocol-explained.md
Software & Web · 16. June 2026 · ~5min · 19fbf53

What Is an MCP Server? The Model Context Protocol Explained

How LLMs get tools – explained with the MCP server that runs this blog

>
devmaker.net
author · 19fbf53 · 2026-06-16
A language model like Claude or GPT can phrase things impressively – but on its own it can't do anything: it can't read a file, call an API or publish anything. The Model Context Protocol (MCP) closes exactly that gap: it's an open standard through which an LLM can reach external tools and data. This article explains, without buzzword bingo, what an MCP server really is, which building blocks it consists of and when your own makes sense – concretely, using the MCP server I use to run this blog (devmaker.net). You only need a basic understanding of APIs; by the end you'll know whether MCP makes sense for your project.
Part of a guide

This article is part of the AI Agents Guide – the curated learning path for AI agents.

A large language model is, at its core, a text generator: it predicts the next word. Impressive – but on its own it can't touch anything in the real world. It doesn't know your files, can't query a database and can't publish anything. This is exactly where the Model Context Protocol (MCP) comes in.

The problem: the LLM is locked in

As long as an LLM only sits in the chat window, it's a clever conversation partner without hands. But the moment it should become genuinely useful – change code in your repo, query a server's status, create a blog article – it needs a bridge to real tools. In the past every vendor built that bridge themselves, incompatibly. MCP standardizes it.

MCP: the USB standard for AI tools

The most fitting analogy: MCP is to AI tools what USB is to peripherals. Instead of building a separate adapter for every combination of LLM client and tool, both speak a shared protocol. An MCP server provides capabilities; an MCP client (e.g. Claude Desktop, Claude Code or LibreChat) uses them. Every server works with every client.

The flow is simple: the client asks the server “what tools do you have?”, the server answers with a list plus descriptions. The LLM then decides on its own when to call which tool – and the server executes it.

The three building blocks: tools, resources, prompts

  • Tools are actions the LLM can trigger – functions with parameters (“create an article”, “query the click stats”). This is the most important and most common building block.
  • Resources are data to read – files, database entries, API responses that the model receives as context.
  • Prompts are predefined templates a client can offer as ready-made commands.

Concretely: my MCP server for devmaker.net

This isn't theory – this blog is run exactly this way. I built an MCP server that controls the Wagtail/Django website behind devmaker.net. Its tools are called, for example, write_article, set_streamfield_content, generate_ai_image or publish_page. An LLM sits in front of it as the client: I say “create the article and set the tags”, the model picks the right tools and calls them – the server does the actual work in the database.

A minimal server with FastMCP (Python) shows how little it takes:

from fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def server_time() -> str:
    """Returns the current server time as an ISO string."""
    from datetime import datetime
    return datetime.now().isoformat()

if __name__ == "__main__":
    mcp.run()

The docstring is not decoration: it's the description the LLM uses to decide whether to call the tool. With MCP, good descriptions are half the battle.

A server like this barely needs any resources – my devmaker MCP server runs as a lean service on the same power-efficient mini PC that carries the rest of my homelab:

When is your own MCP server worth it?

Whenever you want an LLM to work with your own system repeatedly: your API, your database, your homelab, your tooling. For a one-off question, an MCP server is overkill. But if the model should perform concrete actions reliably and repeatably, a cleanly defined MCP server is the more robust route than any copy-paste into the chat.

What I left out

Deliberately left out for the overview: the transport topic (stdio vs. HTTP/SSE) and the pitfalls of remote operation – there's a dedicated article for that: MCP server doesn't survive a deploy: SSE vs. Streamable-HTTP. Likewise authentication and error handling, which a production server needs.

Conclusion & outlook

An MCP server is the standardized bridge that turns an LLM from a pure text machine into an actor that operates real tools. The concept is manageable – tools, resources, prompts – and with FastMCP you start in a few lines. If you now want to build one yourself, it continues step by step here: Developing MCP servers in Python: from empty repo to the first tool.

// More recommendations

Ad · Affiliate link – if you buy through it, I may earn a commission. It doesn’t change the price for you.

// responses (0)
> echo "your thoughts" >> what-is-an-mcp-server-model-context-protocol-explained.responses

Post your comment

Required for comment verification