What Is MCP? The AI Foundations Most Developers Skip

The AI ecosystem is full of content about what to build. Almost none of it explains what is actually happening. That gap is costing developers real hours.

Wrecking Ball logo mark

Wrecking Ball

Industry News
15 min read         Jun 5, 2026

I spent two weeks stuck on a problem that took ten minutes to solve once I understood what an MCP server actually was. Not a revelation. Two weeks of blaming everything else: the model, the prompts, the framework, the tool. None of those were the problem. I just didn’t have the one foundational concept I needed, and nothing in the sea of AI content I was consuming had bothered to explain it.

That is the thing about the current AI ecosystem. There is endless content about what to build and which tools to use. Almost none of it explains what is actually happening. And that gap is costing developers real hours.

This piece fixes the basics. MCP, skills, plan mode, and how to actually talk to a model. Four foundations you need before you touch a framework, install a skill library, or spin up an agent and wonder why the output is bad. Written by the engineers and creatives who use them in production.

What Is MCP? An Agent-Readable Interface in Plain Language

I had heard MCP thrown around for months. People on the team were using it. I had seen it in repos. I kept absorbing enough context to sound informed in a conversation without actually knowing what I was talking about. That is a dangerous place to be as an engineer, because eventually you try to build something and you hit the wall.

For me, the wall was Obsidian. I had been using it as my personal document vault: notes, project context, client references, all of it in one place. And I needed to connect it to Claude. I knew Zapier could connect apps. I knew APIs existed. But what I did not understand was how an AI model was supposed to interface with any of it in a way that was actually useful.

MCP is not a tool. It is a protocol. A standardized way for AI models to call external systems, execute methods, and get structured responses back. Not request data passively. Actually do things. The Model Context Protocol was open-sourced by Anthropic and has since been adopted across the industry.

“MCP is a JSON RPC sort of architecture that is method-based. If you imagine a REST API, with a REST API you say I want a list of articles and it returns a structured list. MCP is similar, except it’s method-based instead of resource-based. So instead of saying give me a list of articles, I would say multiply, with inputs 2 and 4, and the response would be 8. It’s a JSON structure to ask a separate system to perform a method.”

Noah Mason, Sr. Full Stack Engineer

The distinction between resource-based and method-based is the thing most people miss. REST APIs are built for humans querying data. MCP servers are built for agents executing actions. That changes everything about how you architect AI systems.

“What MCP does is make an agent-readable and agent-writable interface for something. We’ve spent our whole last decade creating systems that prevent bots. The entire internet was built to be human-only. MCP flips that completely. It says, here’s a backdoor. Just for agents.”

Noah Mason, Sr. Full Stack Engineer

Google Drive. Slack. Outlook. Obsidian. Any system with an MCP server can be operated by an agent, not just queried by one. The first real proof came through Obsidian. Once Claude was reading and writing to the vault through MCP, the next moves became obvious. From Obsidian, the connection went to Slack, then Outlook. James built a personalized morning briefing system that pulls every message and email from the previous day, categorizes what needs attention, and drafts responses in his own voice. His words on the subject: “I hate email, it’s a goddamn mess.” So he automated his way out of it. No subscription fees. Token usage so small it barely registers.

This is what most MCP content misses. It is not just an integration pattern. It is a business model question. Every SaaS tool you pay for to manage your workflow is a candidate for replacement by something you build yourself on top of these protocols. And the products that survive will be the ones that went agent-first.

“Obsidian is not a unique application. What is unique about it is that they went MCP first. They went agent-readable, agent-writable first. That’s the only difference between Obsidian and Notion. They went agent first. MCP can be a value prop for a product. Full stop.”

Noah Mason, Sr. Full Stack Engineer

Stop Installing Skill Libraries. Build Your Own.

Skills are the part of this ecosystem where most people go wrong fastest. You can search GitHub right now and find thousands of them. Someone writes a markdown file, calls it a skill, publishes it to a repo, and suddenly it is circulating everywhere. That does not make it good.

“Just like the npm ecosystem, there’s an equal amount of garbage. People write a markdown file and claim it’s a skill. And if your LLM has four different skills it thinks it should trigger, and there’s overlap between them, that’s bad. You’re confusing your LLM. You don’t know what the hell is going on.”

Noah Mason, Sr. Full Stack Engineer

The right way to think about a skill is simple. When you figure out a repeatable pattern and can describe it in natural language, that is a skill. It is not something you install. It is something you derive from your own working knowledge of how a job gets done. Noah does not install off-the-shelf skills. He reads them for research, then builds from scratch. James applied the same logic to design work, feeding Wrecking Ball’s brand guidelines into Obsidian and connecting them to Claude so that every diagram, document, and artifact comes out in the right visual language automatically.

The framework for thinking about this: the skill for scaffolding a new design system is completely different from the skill for creating a component inside one that already exists. As Noah put it, “treating them as the same job tells the model to start over every time.” Two different jobs. Two different skills. If you blur that line, the model cannot hold the distinction either.

The practical test for a good skill is simple: if you removed it, would the model’s output change in a specific, predictable way? If yes, the skill is doing real work. If no, it was never earning its place. Skill overlap is quieter than it sounds. The model will not tell you it is confused. It will just give you blended, inconsistent output that looks plausible but varies across sessions for no apparent reason. When that happens, audit your skill set before you blame the model. Look for two skills that could both plausibly fire on the same input. That is your conflict. Cut one, or rewrite both with tighter trigger language.

Use the Tools While They Are Immature

I was anti-AI-assisted coding not that long ago. I said it out loud, to the team. I love writing code. I think it is an art form. And I was not interested in outsourcing that to a tool I did not trust. One epiphany changed my mind, and it was not a feature. It was a realization about timing.

“You cannot wait until these tools are mature. There is not going to be a line where we say now it’s mature, now we use it. The early adopters are going to have an advantage and the rest are not. You couldn’t use React until it was mature. With AI, you have to use it while it’s immature, because it’s such a shift. You cannot gauge if it’s getting better unless you use it. You cannot just watch YouTube videos.”

Noah Mason, Sr. Full Stack Engineer

There is a version problem too. If you are not paying for access to the current models, you are not evaluating AI. You are evaluating a year-old version and wondering why the results do not match what you are hearing about. Noah’s framing: using an older model tier versus the current one is the difference between a kindergartner and a high schooler. They are not the same tool. Engineers who conclude AI coding is not useful yet are usually running the wrong version and do not know it.

Once you are in the right tools, there is still a way to communicate with them that produces great results and a way that produces garbage. That gap is not closed by a better model. It is closed by learning how to prompt, and that is a skill you only develop by doing it.

“Talking to an LLM is a skill. Eventually, when it knows everything about everybody, you can just type a sentence. But right now, there is a way to talk to it to get good results and a way to get bad results. You have to learn that by experience. It’s not teachable.”

Noah Mason, Sr. Full Stack Engineer

The connection to design principles is not a metaphor. Understanding text hierarchy, when to use headings, when to use bullet points versus prose, these things change how a model parses your input. The same prompt, restructured with headings and separated paragraphs, produces a measurably different result. Noah connects this directly to his design background: his knowledge of typography helps him communicate with the model the same way it helps him build a more readable page. He puts it simply: “prompts should be beautiful, the same way good code is beautiful.”

And then there is plan mode. I learned this the hard way. Someone told me early on to plan everything before I start. I said no, I want to move fast. That was the biggest mistake I made.

Plan mode is a pre-execution phase built into Claude Code. Before writing a single line of code, the model reads your project, maps your intent to the existing structure, and produces a detailed implementation plan. You review it, you approve it, then execution begins. The model is not making architectural decisions on the fly. It has a spec. The difference between plan mode and agent mode is the difference between an engineer who designs before building and one who starts pulling cables and figures it out as they go. Use plan mode any time your task touches more than one file, has dependencies between components, or involves logic you have not written yet. Use agent mode for isolated, well-defined tasks where the scope is completely clear.

“There’s a sentence at the beginning of plan mode that says: don’t do any work, just plan. That’s all it is. That’s the whole thing. And when I heard that, I thought, oh. That’s all.”

Noah Mason, Sr. Full Stack Engineer

When you skip plan mode and go straight into agent mode, you burn through your token budget fast. Worse, when the agent hits an issue mid-build, it will patch or hack that issue in isolation, without context of everything surrounding it. You end up with a codebase full of local fixes that create global problems.

The context window compounds this. Every model has one, and they only behave well inside the first sixty percent of it. Stay specific. Keep changes small. Work file by file when you can. When the model identifies related changes across other files, acknowledge them and move on: those go in the next conversation. Noah does this literally, telling the model “that’s OK, we’ll do that next” rather than letting it expand scope mid-task. That discipline is what keeps output clean across a long build.

Build Something for Yourself. Don’t Wait for a Client.

The advice for engineers who have been slow to adopt is not about which tool to install first. It is about how to build the kind of experience that actually accelerates your learning.

“Set up challenges for your own personal gain. When you’re doing something for yourself, there are no limits. Find people who are deep into this already and learn from what they’ve done. Not copying their process. Taking it into your own journey. Do your own projects. Build your own experiences. If you wait for a client, the client comes with its own rules, its own friction. Work for yourself first.”

James Begera, Creative Director + Partner

James spent a weekend building Kung Fu Theater in Three.js. He had wanted to work in Three.js for years but never had the time to learn it alongside everything else. One weekend with AI-assisted code later, he had a functional, mobile-ready 3D experience with theater mode. The knowledge of how to approach it was already there. The tools just removed the barrier between knowing and building.

The reason personal projects work better than client work for learning is not about motivation. It is about feedback loops. On a personal project you can try something, break it, understand why it broke, and try again in the same afternoon. On a client engagement that same loop takes weeks and involves other people’s schedules, risk tolerances, and definitions of done. Client work also cannot give you permission to be bad at something. Learning requires producing output you are not proud of yet. A personal project absorbs that. A client brief does not.

For creatives, the principle is the same one Tarantino proved before AI existed. Research obsessively. Develop your eye. Build the reference library. The tools will handle more and more of the execution. What they cannot manufacture is taste, judgment, and the ability to direct.

“The technical aspect of things is becoming easier. Anybody can create a lot of different stuff. But you’re going to see the difference between good production output and garbage output in how the story moves through the visuals. You can’t just prompt your way out of it.”

James Begera, Creative Director + Partner

Capability inspires ideas. That is the real payoff, and it is the thing that keeps you up at two in the morning. The moment you understand what you can actually do with these tools is the moment the ideas start arriving faster than you can build them.

The Foundations Don’t Change. The Tools Do.

MCP. Skills. Plan mode. How to prompt. These are not advanced concepts reserved for people who have been at this for years. They are the foundation. They are what you need before you touch a framework, before you install a skill library, before you spin up an agent and wonder why the output is bad.

If nobody taught you this stuff before now, that was the problem. Not your ability. Not your background. The content ecosystem skipped the basics and went straight to the features. We are fixing that.

At Wrecking Ball, we build with these concepts in production, for clients like Mastercard, Sony Music, and Norwegian Cruise Line, and on our own internal tools, our own research, our own late-night projects. The engineers and creatives doing that work are the ones who wrote this.

“We are going to be the early adopters. We are going to be the people that spread this around. It’s a tree. It starts at the trunks. And then everyone around us is branches.”

Noah Mason, Sr. Full Stack Engineer

Learn the foundation. Build something for yourself. Use the tools while they are immature. Talk to the model like you would talk to a senior colleague. Plan before you build. Keep your context clean. That is it. That is what we know right now. And we will keep writing it down as we learn more.

Frequently Asked Questions

What is an MCP server in simple terms?

An MCP server is a standardized, method-based interface that lets an AI model call an external system and have it perform an action, then return a structured response. Unlike a REST API, which is resource-based and built for humans querying data, MCP is built for agents executing actions. It makes a system agent-readable and agent-writable, so an AI can operate it, not just read from it.

What is the difference between MCP and a REST API?

A REST API is resource-based: you ask for a list of articles and it returns the data. MCP is method-based: you ask a separate system to perform a method, like “multiply 2 and 4,” and it returns the result. REST APIs are designed for humans querying data; MCP servers are designed for AI agents executing actions.

Should I install AI skills from GitHub or build my own?

Build your own. Most published skills are low quality, and overlapping skills confuse the model into producing blended, inconsistent output. A good skill is a repeatable pattern you can describe in natural language and derive from your own working knowledge. The test: if you removed the skill, would the model’s output change in a specific, predictable way? If not, it is not earning its place.

What is plan mode in Claude Code?

Plan mode is a pre-execution phase where the model reads your project, maps your intent to the existing structure, and produces a detailed implementation plan before writing any code. You review and approve it, then execution begins against a spec rather than improvised architecture. Use plan mode any time a task touches more than one file, has dependencies between components, or involves logic you have not written yet. Use agent mode for isolated, well-scoped tasks.

Why does paying for current AI models matter?

If you are not on the current model tier, you are evaluating a year-old version and drawing conclusions from the wrong tool. The quality gap between an older tier and the current one is wide. Engineers who conclude AI coding is not useful yet are often running outdated models without realizing it.


Want to build with these foundations instead of guessing at them? Contact Wrecking Ball to see how we put MCP, custom skills, and agent-first workflows into production for brands that need real results, not demos.

Read More Articles

Industry News

From Mess to Masterpiece: How Wrecking Ball Engineers Data to Drive Real-World Impact

Industry News
5 min read         Jan 26, 2026
Industry News

From Fragmented Systems to Flawless CX: Dolby’s Media Delivery Transformation

Industry News
4 min read         Aug 5, 2025
Industry News

Understanding Your Customer Data, Enterprise CDP, and Path to Personalization

Industry News
6 min read         Jul 10, 2025