Over the past few weeks I built my own MCP server for this blog, blog-mcp, and in the process really understood why people are talking so much about the Model Context Protocol right now. The idea behind it is actually simple: an MCP server is a bridge between an AI model like Claude and a real system, whether that's a database, an API, or an internal tool. Instead of me copy-pasting between chat and an admin panel, the server just describes a handful of functions ("tools") the model can call, with clearly defined inputs and outputs.
For my blog, that means concretely: blog-mcp exposes tools like create_draft, update_draft, or list_articles. Claude can use these to create article drafts directly, maintain multilingual translations, or check editorial status, all without me writing SQL myself or opening the backend dashboard. The model only sees the tool description (which parameters, what purpose), not my database code, and it can still work with it meaningfully.
What became especially clear to me while building this: tool schemas are essentially a contract between code and model. If the schema changes (say, a new locale parameter for translations), the server needs to actually be redeployed, otherwise the model keeps working with an outdated idea of what's possible. That's exactly what happened to me while testing, a PUT request technically went through, but because the locale feature wasn't deployed yet, it overwrote the entire article instead of just one translation. A good example of how important clean schema design and versioning are for MCP servers, especially since the model essentially has to trust the schema blindly.
Still, the biggest win for me is the workflow itself: I can think through a blog post in a chat window, have it written or write it myself, and have it land directly as a draft in the real database, no context switching. It feels less like "using AI" and more like an additional, very flexible interface to my own system.