Agent Skills, MCP Servers and APM: Better Together, Not Interchangeable

There's a conversation happening in the AI tooling space that I keep running into, and it usually sounds something like this:

Now that we have Agent Skills, do we still need MCP Servers?

The short answer is yes — and the longer answer is that the question itself reveals a common misunderstanding about what each of these things actually does. They are not competing technologies. They are complementary layers that, when combined, produce something genuinely powerful.

Let me explain both, clear up the confusion, and show you what this looks like in practice.

What is an MCP Server?

MCP stands for Model Context Protocol — an open standard that allows AI agents to connect to external tools and services. Think of an MCP Server as a bridge between your AI Agents and the outside world in the forms of External API's, Databases etc.

Without MCP, an AI agent is limited to it's own training data. With MCP, it can reach out and do things — query a database, create a Jira ticket, fetch a GitHub repo, search documentation, trigger a deployment. The agent gains multiple working hands like an octopus.

MCP Servers expose a set of tools that the AI can call. Atlassian, for example, ships an MCP Server that gives Claude or Copilot direct access to your Jira and Confluence workspace. GitHub ships one that lets an agent read repos, list issues, and inspect pull requests and Terraform allows you to query the HashiCorp Registy and query providers like azurerm and modules. The agent calls these tools the same way it calls any other function — it just happens to be talking to a live system on the other end.

The key thing to understand about MCP is that it is capability. It answers the question: what can the agent do?

What is an Agent Skill?

An Agent Skill is something different. It is behaviour — a structured set of instructions, templates, and workflows that shapes how the agent does something.

A skill is typically a markdown file (or a small collection of them) that lives in your repository. When an agent reads it, it understands the rules for a particular task: what format to use, what steps to follow, what to check before proceeding, and what to never do. It's in essence a like a playbook for your AI Agent.

If MCP answers what can the agent do, Agent Skills answer how should the agent do it.

A skill on its own cannot post to Jira. An MCP Server on its own has no concept of a well-structured story format, a six-section template, or a rule that says "never post without user approval." They compliment each other, not replace each other

The Confusion

The mix-up usually comes from the fact that both are described as ways to "extend" your AI. That framing, while technically accurate, implies they are solving the same problem — and they are not.

MCP extends what the agent can reach. Skills extend what the agent knows how to do.

A useful analogy: imagine hiring a contractor. An MCP Server gives them access to your building — keys, tools, credentials, the ability to actually get work done.

An Agent Skill is the specification document that tells them exactly how you want the work done: the standards to follow, the sign-off process to respect, the output format you expect.

You would not hand someone the keys to your building with no specification, and you would not hand them a detailed specification with no tools to carry it out. Both matter and compliment each other when paired and used effectively.

A Real Example: The Jira Story Creator

A good illustration of this is a setup i have created for generating Jira stories with AI assistance.

The goal: Get assistance via an AI Agent to write a well-structured Jira user story and post it directly to our board — all within the conversation, no manual copy-pasting.

The MCP Layer

Two MCP Servers are in play here:

Atlassian MCP — connects the agent to Jira via OAuth, giving it the ability to create issues, search the board, link stories to epics, and update existing tickets. No API tokens, no credentials stored anywhere.
GitHub MCP — connects the agent to GitHub via the gh CLI, allowing it to read repository context before writing a ticket. The agent can inspect the README, browse open issues, and understand what the codebase is actually about.

These two servers give the agent the capability to reach both systems.

The Agent Skill Layer

The Jira skill provides the behaviour:

A strict six-section story structure (title, description, business justification, work to complete, additional information, acceptance criteria)
Formatting rules for Jira's Wiki Markup.
A self-validation checklist the agent runs before presenting anything to the user.
A hard rule that the agent must get explicit approval before posting.
Reference templates and examples of a well written Jira Story to hep the Agent see what a good example is like.

The Combined Workflow

When you ask the agent to write a ticket for a specific repository, it will:

Pull the repository context via GitHub MCP — understanding the project, existing issues, and current work patterns
Drafts a story using the skill's template and structure rules
Self-validates the draft against the checklist
Presents the draft and asks for approval
Posts directly to Jira via the Atlassian MCP
Returns the issue URL

The result is a Jira story that is grounded in real repository context, consistently formatted, reviewed before posting, and created entirely within the conversation. No scripts. No credentials. No context switching.

Why This Matters

The real value here is not that any single piece is clever — it is that the combination removes friction at every step.

Before this setup, writing a good Jira ticket required lots of context gathering (read the repo, understand the information via lots of reading documents online), formatting knowledge (remember Jira's markup syntax), process discipline (follow the template, write real acceptance criteria), and manual posting (copy the content, navigate to Jira, fill in the fields). Each step was small, but together they added up to enough friction and manual human hours that shortcuts got taken and context was missed.

With MCP handling the integrations and the skill handling the standards, the agent absorbs all of that overhead. The human stays focused on the requirement itself and can always add/take away small things they would like to change.

The Takeaway

MCP Servers and Agent Skills are not rivals. They occupy different layers of the same stack:

Layer	Technology	Answers
Capability	MCP Server	What can the agent access and do?
Behaviour	Agent Skill	How should the agent do it?

Use MCP to connect your agent to the systems it needs. Use Agent Skills to encode the standards and workflows you care about. Together, they turn a general-purpose AI into something that actually fits your team's way of working.

Neither one replaces the other. They are better together.

The Missing Piece: Distribution

So we have MCP handling capability and Agent Skills handling behaviour. Together they work well. But there is a practical problem that surfaces the moment you try to share any of this with someone else.

Skills live as files in your repository. Different tools expect them in different places — Claude Code reads from .claude/skills/, GitHub Copilot reads from .github/. If you want a skill to work with both, you are maintaining two copies of the same files. If you want to share a skill with another team, they are copying directories around manually and hoping they put everything in the right place.

This is the same problem the JavaScript had before npm, or Python before pip. The tooling works, but there is no standard way to package it, distribute it, or declare it as a dependency.

That is where APM comes into play.

What is APM?

APM stands for Agent Package Manager — an open-source tool from Microsoft that does for agent configuration what npm does for JavaScript or pip for Python dependencies. You declare what your project needs in a single manifest file called apm.yml, and APM resolves, downloads, and integrates everything.

Think of it this way: if MCP is the bridge to external systems and Agent Skills are the playbooks, then APM is the supply chain that gets those playbooks where they need to be.

The core idea is simple. You define your skills once in a standard location — .apm/skills/ — and APM handles the rest. It copies them into the right directory for whatever tool you are using, resolves transitive dependencies if your package depends on other packages, and generates a lockfile so everyone on the team gets the same setup.

One manifest. One install command. Every agent configured the same way.

This also works for Prompts and AI Agents you may define as well, in this particular example I have not used these but it's worth noting.

How APM Complements MCP and Skills

APM does not replace MCP or Agent Skills — it sits alongside them as a third layer in the stack.

Layer	Technology	Answers
Capability	MCP Server	What can the agent access and do?
Behaviour	Agent Skill	How should the agent do it?
Distribution	APM	How do skills get shared, installed, and kept consistent?

Without APM, you are manually copying skill files between repositories, maintaining duplicate directories for different tools, and employees are wasting time in package and run these.

With APM, a new developer clones the repo, runs apm install, and every skill is in place — correctly located for their tool of choice.

This matters more as the number of skills grows. One skill in one repo is manageable by hand. Ten skills across five repositories is not. APM turns that into a dependency declaration rather than a manual process.

What This Looks Like in Practice

We took the Jira Story Creator skill from earlier in this post and packaged it as an APM package. The structure looks like this:

agent-skills/
├── apm.yml
├── README.md
├── .gitignore
└── .apm/
    └── skills/
        └── jira-skill/
            ├── SKILL.md
            └── references/
                ├── story-template.md
                ├── good-story-examples.md
                └── jira-formatting.md

The apm.yml manifest is minimal:

name: agent-skills
version: 1.0.0
description: A collection of agent skills for AI coding assistants.

dependencies:
  apm: []

The skill itself — the SKILL.md, the templates, the formatting reference — lives under .apm/skills/. No more duplicating it into .claude/skills/ and .github/ separately. APM handles that at install time.

Installing It

Anyone can pull this into their own project:

apm install okaneconnor/agent-skills

APM clones the package, reads the .apm/skills/ directory, and integrates the skill into .github/skills/ where Copilot picks it up automatically. It also generates a lockfile and adds apm_modules/ to .gitignore — the same patterns you are already familiar with from npm or pip.

The full repository is here: github.com/okaneconnor/agent-skills

The Developer Experience

For a new team member joining a project that depends on this package, the workflow is:

git clone <your-project>
cd <your-project>
apm install

That is it. The Jira skill is integrated, the reference files are in place, and their agent is ready to use it. No manual file copying, no reading a setup guide, no guessing which directory things go in.

The MCP server still needs to be configured separately — you add the Atlassian MCP server to your tool's config and authenticate via OAuth. APM handles the skill distribution; MCP handles the live connection to Jira. Each layer does its job.

The Full Stack

Stepping back, the three layers now form a complete picture:

MCP gives the agent access to Jira, GitHub, and whatever other systems you need. It is the hands.

Agent Skills give the agent structured workflows, templates, and rules for how to use those systems well. It is the playbook.

APM packages those skills and distributes them consistently across tools and teams. It is the supply chain.

None of these layers is as useful in isolation compared to the way it is when combined with each other. An MCP connection to Jira without a skill produces inconsistent output. A skill without MCP cannot actually post anything. And both without APM means every developer is setting things up manually, differently, every time.

Together, they turn a general-purpose AI into a reliable, shareable, team-aligned tool — and that is where the real value sits.

Agent Skills and MCP Servers: Better Together, Not Interchangeable