MCP, Skills, Commands, Agents: A Product Manager's No-BS Guide to AI Buzzwords

I wrote the first version of this back in February. A few months and a lot more hours in the repo later, I’m updating it with what actually changed in how I work — not a new post, just this one getting more honest.

Let me give you some clarity on these terms — not from an engineering perspective, but from a product manager’s point of view.

If you’re not familiar with MCP, Skills, or Commands, don’t worry. These buzzwords are everywhere now. Open LinkedIn and you’ll see “comment SKILL” or “comment MCP” posts promising to reveal secrets. I get it.

Here’s the thing: I’m not an overhyped AI guy. But I do believe AI is a massive growth opportunity for everyone. That’s why I make it a point to check each trend and actually use these tools myself. Because experimenting is the only way to understand what’s truly useful for you.

So here’s my journey breaking down these concepts.

The Tools I’m Using

Before diving in, let me share my current stack: Claude Code, Lovable, and Cursor. These are my main tools for AI-assisted development.

Quick aside: the IDE matters less than people assume. I use Cursor mostly because I like having several tabs open, not for its own model — VS Code would do the job just as well. I barely touch the file system by hand these days anyway, so the editor wrapped around it is almost beside the point.

Now, let’s demystify the buzzwords.

MCP: Where Everything Started

MCP stands for Model Context Protocol. It’s basically a standardized way, invented by Anthropic, to allow LLMs to perform actions outside their domain.

Think of it this way: you describe an external tool — like “I have a tool that reads emails” or “I have a tool that reads books.” You define what inputs the tool expects, and what output it returns.

If you’re a developer, think of MCP as a conversational, less structured version of a RESTful API. Behind the scenes, it might invoke actual APIs, combine multiple of them, do whatever logic you need. But the interface is conversational.

Why Is MCP Useful?

It lets you access external tools. Your Airtable. Your internal APIs. Whatever.

There are even wrappers that let you start from scratch with your own MCP server — they’ll wrap your OpenAPI specification and just work. Pretty well, actually.

The key thing to know: MCP is now the foundation for listing your app in OpenAI’s GPT store, Anthropic’s ecosystem, and similar platforms.

How It Works (Super Summarized)

1. The LLM detects that a tool is needed
2. It checks if that tool is registered in its MCP server list
3. The app you’re using — Cursor, Claude, etc. — acts as the MCP client and calls the tool (the MCP server)

The beautiful thing? You can encapsulate any logic behind your MCP server.

Let’s use Jira as an example. You could use the generic Jira MCP server. Or you could write your own MCP server that forces specific workflows for your team — while a generic one stays generic.

Where I Actually Reach for CLI Instead

Here’s the honest update, months later: in practice, I use way less MCP than this made it sound, and way more CLI.

My whole stack runs through the command line — AWS CLI, GCP CLI, that kind of thing. I don’t know everything about them, nobody does, but they’re powerful enough that working with them is genuinely a pleasure. The LLM can detect almost everything on its own from the CLI itself. I authenticate once, give it the high-level ask, and it does the rest.

I still use MCP. Just for a handful of things, not the majority of my workflow.

Both things are true. MCP is still the right call when you need a structured, discoverable interface — especially if you’re shipping an integration for someone else to plug into, like the Jira example above. But for my own day-to-day, the CLI wins more often than not, because the tool’s own docs and --help output already give the LLM everything it needs.

Skills: Human Language Behavior (and More)

A Skill is a described behavior, primarily written in human language.

The difference from MCP? Skills guide the LLM to do something in a specific way. Things like “ask me questions one by one” or “please specify X, Y, Z before proceeding.”

In practice, Skills are versioned packages — a SKILL.md file plus optional scripts and assets. So they can include both instructions and executable code, not just text. Agent Skills is actually an open standard now (see agentskills.io), so they’re portable across tools that support the standard.

You can combine Skills with MCP. At the end of the day, everything gets passed to the LLM and the agent.

The Catch With Skills

They’re less strict than code. The LLM can ignore them. It might even hallucinate. But Skills are still valuable because they inject context into your prompt consistently.

Think of Skills as behaviors — more than a single command. They describe how you want things done, not just what to do.

And yes, within a Skill, you can tell the LLM to call specific MCP servers.

When Skills Shine

Instead of over-typing every time, you can just say “I need a Jira task” and the LLM — depending on context — will detect the intent and follow the Skill’s definition.

Skills, Not Plugins

One more thing I’ve settled on: I’d rather have a pile of small, specific Skills than one big plugin.

I’m not against plugins — I just haven’t had the time to really try them. My read is that a plugin is mostly a way to bundle a bunch of Skills together. Fine, but I’d rather keep the pieces separate and granular.

In practice, that means naming Skills after the exact thing they cover. On Astika, for instance, I don’t have one catch-all “UI” skill — I have skills like astika-ui-<component>, one per component. It’s easier for the LLM to pick the right one and stay consistent with how I actually want that piece built, instead of guessing from something broader and vaguer.

And when a Skill isn’t working — the LLM picks the wrong one, or follows it loosely — I don’t just live with it. I go back and ask it to improve the Skill itself.

Commands: For the Slash-Command Nerds

If you’re old like me and remember slash commands, Commands are for you.

Commands are more specific and isolated than Skills. They’re introduced in tools like Cursor, and the idea is simple: you define your /slash-command with a definition of what the LLM should do.

The definition isn’t code — it’s still natural language. But Commands tend to be more granular.

Skills vs Commands: The Jira Example

• MCP: The Jira integration with all its tools
• Skill: The behavior you want — maybe describing the process, which tools to use, how to interact with the user
• Command: More specific actions like /jira-add or /jira-remove

Commands are like single (ish) operations. Behind the scenes, they might combine multiple calls, but they feel more atomic.

Agents and Chat: The Context Game

Now, how do Agents (or Chat, same thing) actually work?

They start with a prompt. But that prompt is long because it combines:

• Your own prompt
• The IDE’s response and context
• Your additional instructions

This is called context. And here’s the problem: LLMs have limited context windows. Even the biggest ones.

When Context Gets Saturated

At some point, your context will be saturated or diluted. The LLM starts performing worse. It tends to favor the latest context and may “forget” earlier instructions.

This is where Skills and Commands save you.

When you invoke a Skill or Command, you’re explicitly specifying what you want — rather than hoping the chat remembers. Think of them as snippets that expand into full explanations. The LLM never loses the memory of what you actually need.

It’s similar to a human developer losing track during a long coding session. Totally normal. But for some reason, we’re not graceful about it when AI does it.

Docs as the LLM’s External Memory

There’s a second layer to this, underneath Skills and Commands, and it’s honestly the part I care about most: how consistent the repository itself stays over time.

My brain wants to divide things methodically, and I organize the repo the same way. I keep a docs folder with a handful of numbered files, one per topic — a changelog, an architecture doc, that kind of thing. Then I train CLAUDE.md to read from that folder for context, and — this part matters just as much — to write back into it when something changes.

Keep your documentation updated. That’s most of the trick.

The benefit runs both directions. For me, it’s a forcing function to slow down and actually read what the LLM did, instead of trusting a stack of diffs I never opened — and I can ask it to translate a doc into plainer language if I don’t follow it. For the LLM, that folder is basically its memory across sessions. It knows what it did, why, and in what order, instead of relying on a context window that’s already forgotten how the conversation started.

The Prompt: The Ultimate King

The prompt is king.

Sometimes you can’t even see it — you can only guess. But the prompt is the ultimate request sent to the LLM. It includes:

• Parts of your code
• Your request
• Additional information
• Recommendations
• And more

Everything funnels into that prompt.

Project-Specific vs User-Specific

Here’s something useful: Skills and Commands can be project-specific or user-specific.

• User-specific: Your personal Skills that work across all your projects
• Project-specific: Skills shared in your code repository, available to your whole team

This flexibility is powerful for team collaboration.

The docs folder above follows the same split — it’s almost always project-specific, since it’s the history and architecture of that one repository, not something you’d want bleeding into every project you touch.

Picking the Right Model for the Job

The last habit I’ve picked up: stop reaching for the same model for everything.

I mostly stick to the big public models, but I’ve started splitting the work by what each one is actually good at, not by habit. Gemini, in my case, is strictly for pulling structured data out of something messy — I don’t use it for much else. Sonnet is my go-to for writing copy. Opus is what I reach for when the task is real code, not a one-liner.

It’s not a fixed rule yet, more a rough instinct: match the model to the shape of the task instead of defaulting to whichever one is already open in the tab. I’ll probably do a proper comparison down the line, once I’ve put in enough hours to say something sharper than “this one feels better for that.”

My Recommendation: Let AI Help You Find Patterns

Here’s a tip from my journey: keep writing using the agent or chat. At some point, you’ll notice repetitive stuff.

That’s your signal.

When you spot repetition, that’s the perfect moment to create a Skill or Command. And here’s the meta part: ask AI to help you identify these patterns. Ask it what commands or skills would be useful based on how you work.

---

As always, I’m still experimenting with AI. I don’t pretend to be the AI master or the AI kung fu panda. If something here doesn’t resonate, feel free to push back.

For me, writing these articles is a way to vent about my day-to-day discoveries — and hopefully be useful to my friends along the way.

Thanks for reading.