I keep seeing MCP, Agent Skills and APIs discussed as though they are competing ways to connect AI to a business.
They are not.
I ran into this distinction while building relatively ordinary agent workflows around tools such as YouTrack, n8n and calendars. Sometimes I was writing a script against an API. Sometimes I was giving an agent a reusable Skill. Sometimes an MCP server looked attractive because it could expose the same capability to multiple AI clients.
At first, these choices can look interchangeable.
They become much easier to reason about once you realise they sit at different layers.
The API provides the capability. MCP provides a standardized interface to that capability. A Skill provides the operating knowledge for using it.
That sounds like semantics until you start building real systems. Then it affects cost, reliability, security and how much work an agent has to rediscover every time it runs.
An API is the thing that actually does the work
Start at the bottom.
If I want to create an issue in YouTrack, send something into a CRM, query an accounting system or add an event to a calendar, there is usually an API somewhere underneath the integration.
The API defines what the software lets another piece of software do.
There might be an endpoint to:
- create an invoice;
- retrieve a customer;
- update an opportunity;
- create a calendar event;
- search a project;
- upload a document.
The exact implementation could be REST, GraphQL or something else. That detail matters to the developer, but the architectural point is the same.
The API is the actual machine interface.
An agent can call that API directly through code. A Python script can call it. n8n can call it. An MCP server can call it.
MCP does not make the underlying API disappear.
This matters because I sometimes see MCP described as if it is the new replacement for APIs. In most cases, it is sitting on top of them.
If an accounting platform already exposes an API, an MCP server might translate a model-friendly tool such as create_customer into several API requests behind the scenes.
The API remains the execution layer.
MCP solves a different problem: interoperability
The problem with direct APIs is not that they are bad.
The problem is that every integration is different.
One service has one authentication method. Another has another. One returns a certain JSON structure. Another calls the same concept something completely different.
Traditionally, every application has to learn those interfaces individually.
MCP changes the shape of that problem.
Instead of every AI client inventing its own integration format, an MCP server can expose standardized primitives such as tools, resources and prompts that compatible AI applications know how to discover and use.1
That is why I think of MCP less as an API replacement and more as an adapter layer for agents.
The latest MCP specification, released on July 28, 2026, pushes this further. The protocol moved to a stateless core designed to work more naturally with standard HTTP infrastructure, alongside formal extensions for capabilities such as long-running Tasks and MCP Apps.1
That evolution matters because MCP is moving beyond the original picture of “connect Claude Desktop to a local tool.”
It is increasingly infrastructure.
The interesting part is portability.
If I expose a business capability through MCP correctly, I may be able to make it available to different compatible agent environments without building a bespoke integration for every one of them.
That is valuable when the same capability needs to serve several agents.
It is less valuable when I have one simple automation that already works.
A Skill solves the problem MCP cannot solve
Then there is the third layer.
Suppose I give an agent access to an accounting system.
The API tells it:
You can create an invoice.
MCP tells it:
Here is a
create_invoicetool, what arguments it accepts, and how to call it.
Neither necessarily tells it:
Before creating the invoice, confirm the customer exists. If the customer does not exist, create the customer first. Use our internal naming convention. Never post an invoice without validating the tax code. For quotations above RM50,000, require human approval.
That is procedural knowledge.
That is where Skills become interesting.
Agent Skills package reusable instructions, resources and potentially executable scripts so an agent can discover the right workflow when it encounters a particular kind of task.2
OpenAI describes Skills as reusable workflows that can include instructions, examples and code, while Anthropic’s Agent Skills model uses a SKILL.md file with supporting scripts and resources.23
Both now support the open Agent Skills format, which is an important development in its own right.23
The distinction I find useful is simple:
MCP tells an agent what tools exist. A Skill teaches it how I want those tools used.
That is a very different job.
Access is not the same as competence
This distinction becomes clearer if I stop talking about AI for a moment.
Imagine hiring someone into a finance department.
Giving them login credentials to SQL Accounting does not teach them the company’s month-end process.
The software is the capability.
The login is access.
The SOP is the operating knowledge.
AI agents need roughly the same separation.
If I connect an agent to ten MCP servers, I have dramatically increased what it can do.
I have not necessarily improved its understanding of what it should do.
This is one reason tool-heavy agents can still feel surprisingly unreliable.
We keep adding capability when the missing layer is procedure.
The agent can access Gmail.
It can access Calendar.
It can access the CRM.
It can create documents.
It can update the project tracker.
And then we expect the model to reconstruct our business process from scratch every time.
A good Skill can encode that process once.
OpenAI makes a similar distinction in its agent tooling: Skills package repeatable multi-step patterns so an agent does not have to continually rediscover the workflow, and a Skill bundle can itself contain supporting materials such as API specifications.4
That last point is important.
Skills and APIs are not mutually exclusive.
A Skill may literally teach an agent how to use an API.
Sometimes I would still choose the API directly
MCP is attractive enough that it is tempting to put everything behind MCP.
I don’t think that is always necessary.
Suppose I have one n8n workflow that receives a paid order and creates a customer record in another system.
The integration is deterministic.
The inputs are known.
The API is stable.
There is no reason an LLM needs to discover the tool dynamically.
Calling the API directly may be the simpler architecture.
I would generally start there when the workflow looks like:
event → known transformation → known action
Adding an MCP server in the middle could give me standardization, but it also gives me another component to deploy, secure, maintain and debug.
Standardization is valuable when there is something worth standardizing.
For a single pipe between two applications, there may not be.
MCP becomes more useful as the number of agents grows
The economics change when multiple agents need the same business capability.
Imagine I eventually have:
- a sales agent;
- a customer-service agent;
- an operations agent;
- a finance agent;
- an internal assistant.
Several of them may need access to customer information.
If every agent contains its own bespoke API integration, I now have five places to maintain authentication, schemas, error handling and permissions.
An MCP layer starts making considerably more sense.
I can expose a controlled set of business tools once and allow compatible agents to consume them through a common interface.
That is the architectural leverage MCP gives me.
And the current direction of the protocol is clearly toward larger production deployments. The August 2026 MCP roadmap puts further emphasis on agentic messaging, HTTP-native transport, agent identity, enterprise security and better SDK ergonomics.
MCP is becoming less interesting because it is fashionable and more interesting because there may eventually be enough compatible clients to justify building a common interface.
Skills become more useful as the business process becomes specific
There is another scaling dimension.
The more peculiar my business process becomes, the more valuable Skills become.
An API can tell the agent how to create a lead.
It cannot know that I classify a lead as KIV after two unanswered follow-ups.
MCP can expose an update_lead_stage tool.
It still does not know my commercial philosophy.
A Skill can say:
When a qualified lead replies but is not ready, move the opportunity to KIV and record the next follow-up date. Do not mark it closed-lost merely because the purchase is delayed.
That is business knowledge.
And unlike putting everything into one giant system prompt, Skills can be discovered when relevant rather than forcing every instruction into every conversation. Anthropic describes this as progressive disclosure: lightweight Skill metadata can be available first, while the full instructions and resources are loaded only when the Skill is needed.3
That architecture becomes especially useful as an agent accumulates dozens of capabilities.
The useful stack is often all three
Once I stopped treating these as competing technologies, the architecture became much cleaner.
A mature business agent might look something like this:
API The accounting platform exposes customers, invoices and payment data.
↓
MCP server
It turns those underlying APIs into agent-friendly tools such as find_customer, get_outstanding_invoices and create_quote.
↓
Skill It teaches the agent when to use those tools, which checks to perform, what exceptions require human approval and how the company’s process actually works.
↓
Agent The model reasons about the user’s request and applies the appropriate Skill using the available tools.
That is much more interesting than MCP versus API.
Each layer removes a different kind of friction.
The API removes the barrier between software systems.
MCP removes the integration differences between agent environments.
Skills remove the need for the agent to reinvent operating procedure.
For SMEs, I would build upward only when necessary
There is a tendency in AI engineering to start with the most sophisticated architecture available.
For an SME, I would usually go in the opposite direction.
Start with the business problem.
If a deterministic workflow can solve it, use the API directly through normal software or an automation platform.
If agents need reusable access to the same business capabilities, consider exposing those capabilities through MCP.
If the agent keeps making inconsistent decisions despite having the correct tools, the missing layer may be a Skill.
That gives me a fairly simple test:
Need to make software do something? Think API.
Need different agents to access that capability consistently? Think MCP.
Need the agent to follow a particular way of working? Think Skill.
And very often, the final system contains all three.
The mistake is asking which technology wins.
The more useful question is: