How I Use Skills and MCPs to Make AI Agents Actually Useful

Most AI agent demos look clean because the task is clean.

In reality, you’re hired as a frontend developer, then the same week you’re debugging backend responses, checking UI polish, testing edge cases, writing docs, reviewing security basics, and explaining why the app broke after someone skipped QA.

That’s where agents either help a lot or waste your time. The difference isn’t the model alone. It’s whether you give the agent repeatable ways to work and useful tools to work with.

That’s what Skills and MCPs are for.

What Are Skills and MCPs?

Skills are task-specific instruction packs. A good skill tells the agent how to approach a repeatable job: what standards to follow, what files or scripts matter, and what the output should look like.

MCPs (Model Context Protocol) give an agent access to external tools and live context — databases, design files, browser automation, docs, issue trackers, local project tools, or anything else exposed through a server.

Skills are the playbook. MCPs are the hands.

The Problem

Agents fall apart when you ask them to be “smart” without giving them a workflow.

That’s the mistake most people make. They open an agent and ask something broad:

Build this feature and make it good.

It sounds normal, but it lacks structure — so the agent guesses. Sometimes the guess is fine. Sometimes it writes code that works locally but doesn’t fit your project. Sometimes it gives a clean explanation and misses the one command that would’ve proven the fix.

This gets worse for indie developers and small teams. Companies want the final product, not the invisible work behind it: test coverage, code quality, deployment checks, security review, documentation, maintainability. When something breaks later, the blame still lands on the developer.

The problem isn’t “AI is bad at coding.” The problem is that one agent conversation is often asked to carry the weight of an entire delivery process.

What I Tried First

• Prompting harder — I wrote longer prompts with more instructions. It helped for one task, then disappeared in the next conversation.
• Keeping one giant rules file — It got noisy. The agent was reading rules for testing, writing, security, frontend, backend, and docs even when the task only needed one of them.
• Manually pasting context every time — It worked, but it was slow. Any workflow that depends on copy-paste discipline is a workflow I’ll eventually skip.

If you’ve been here, you’re not missing something obvious. A general-purpose agent needs a system around it.

The Insight

Don’t make the agent remember your whole process. Give it small workflows and real tools at the moment it needs them.

A skill narrows the behavior. It says: for this kind of task, follow this process, use these checks, produce this kind of output.

An MCP expands the agent’s reach. It says: for this kind of task, you can inspect the design file, run the browser, query the database, read project docs, or call a tool instead of guessing.

That’s it. The rest is implementation.

The Setup

Step 1 — List the Jobs You Actually Do

Don’t start by collecting tools. Start by naming the work.

For example:

- frontend implementation
- API debugging
- database migration review
- UI polish
- test writing
- release checklist
- article writing
- security review

This matters because “make my agent better” is too vague. “Make my agent better at reviewing Flutter PRs” is a workflow. When the job is clear, you can decide whether it needs a skill, an MCP, or both.

Step 2 — Turn Repeatable Behavior Into Skills

Create or install skills for work that has a repeatable process.

Examples:

code-review/
  SKILL.md

flutter-patterns/
  SKILL.md

article-writing/
  SKILL.md

seo/
  SKILL.md

A useful skill should answer four questions:

• What kind of task activates this skill?
• What process should the agent follow?
• What standards should the output meet?
• What should the agent avoid?

For example, a writing skill might include rules like:

- Lead with the concrete problem.
- Cut generic transitions.
- Use the requested article structure.
- Don't invent facts or credibility.

That’s much better than telling the agent “write well” every time. Activation rules prevent every skill from loading for every task. Quality gates make the output checkable before you publish or ship it.

Step 3 — Add MCPs Where Guessing Is Expensive

Use MCPs when the agent needs live context or tool access.

For example:

Design task        -> Figma MCP
Browser test       -> Playwright MCP
Database debugging -> Postgres or Supabase MCP
Flutter analysis   -> Dart tooling MCP
Issue planning     -> GitHub or tracker MCP

Without tools, the agent says:

This component should probably match the design.

With the right MCP, it can inspect the design, compare spacing, check text, and tell you exactly what changed.

That’s the difference between a chat assistant and a working agent.

A few good places to browse when you’re looking for what’s available:

• skills.sh — npm package for installing skills
• skillsmp.com — agent skills marketplace
• mcpservers.org — MCP server directory

Don’t install everything that looks useful. Start with the painful jobs you repeat every week.

Step 4 — Pair Skills and MCPs Together

The best setup is usually not one or the other.

Task Skill MCP Fix a UI bug Frontend patterns Browser or Figma Review a PR Code review Git, language tooling Write an article Article writing Local files, docs search Debug auth Backend / security Database, logs, docs Create issues Issue breakdown GitHub or tracker

The skill tells the agent what good work looks like. The MCP gives it enough access to prove the work. This is where the setup starts paying off — you stop managing every tiny instruction and start asking for outcomes with guardrails already in place.

Step 5 — Keep a Small Default Stack

Don’t build a giant agent cockpit on day one.

Start lean:

1. One skill for your main language or framework
2. One skill for code review
3. One skill for writing docs or issues
4. One MCP for browser testing
5. One MCP for your most important external system

That’s the sweet spot: enough structure to cover real work, not so much setup that every task becomes tool maintenance.

Once a workflow repeats three or four times, turn it into a skill. Once the agent keeps guessing about the same external system, add the MCP.

Bonus: Role-Based Agent Workflows

A useful pattern is to think in roles rather than tasks.

For example:

Frontend Agent:
- frontend skill
- accessibility checklist
- browser MCP
- Figma MCP

Backend Agent:
- backend skill
- database migration skill
- Postgres or Supabase MCP
- API docs access

Reviewer Agent:
- code review skill
- test runner access
- git tooling

You may still be using one actual agent interface, but the workflow changes based on the job. That keeps each request focused and prevents the agent from trying to be everything at once.

Wrapping Up

• Use skills when the agent needs a repeatable way to work.
• Use MCPs when the agent needs access to real tools or external context.
• Combine them when the task needs both judgment and verification.

This setup won’t remove responsibility from you. You still review the output, run the tests, and decide what ships. But it does reduce the amount of invisible process you have to hold in your head — and for an indie developer covering too many roles, that’s the whole point.