Somewhere between the first MCP server and the first Agent Skill, the question stopped being “how do I connect my assistant to things” and became “did I just back the wrong one?”
You can watch it happen in the questions people ask. A year after the protocol shipped, that shows up as “What is replacing MCP servers?” and “What is better than MCP servers?” The category is questioning itself in public.
For course creation specifically, the answer is less dramatic than the question. Skills and MCP are not two attempts at the same thing. One is a connection; the other is a package. You will almost certainly want both, and the useful question is which one does which half of the work.
Try Mini Course Generator free – connect your assistant, or export a graded activity into the LMS you already run.
Key Takeaways
- MCP is a live connection between an assistant and a system it can act inside. Agent Skills are self-contained packages of capability the assistant writes and hands you. They are not substitutes.
- For course creation the split is clean: MCP builds and runs the whole course inside a platform. A Skill produces one portable, graded activity that runs anywhere, including an LMS that has never heard of your AI vendor.
- Skills do not need an account with the vendor whose Skill you are using. MCP does, because it is acting inside your workspace on your behalf.
- “Is MCP obsolete” comes from comparing a protocol to a file format. The real trade is live state and permissions (MCP) against portability and zero integration (Skills).
- Mini Course Generator ships both, which is why this comparison can be honest about where each one loses.
What MCP Actually Is, in Course Terms
The Model Context Protocol is an open standard for letting an AI assistant reach systems outside its own chat window. A server exposes a set of actions; a client – Claude, ChatGPT in Developer Mode, Cursor, Manus – connects to it and can then call them.
Strip the vocabulary away and what you get is permission plus state. When you connect an assistant to a course platform over MCP, three things become true that were not true before:
It can act, not just answer. “Create a five-lesson course from this policy document, add a quiz to each lesson, and publish it” ends with a live course at a URL. Without a connection, the same prompt ends with text in a chat window that somebody has to rebuild by hand.
It knows the current state. It can read what already exists – which courses are live, how a quiz is performing, who has not finished – because it is looking at the real workspace rather than a description of one.
It is bounded by your permissions. The connection is authorized with OAuth, and the assistant works through your account. It cannot reach anything you cannot. That constraint is the whole security model, and it is worth understanding before you connect anything to anything.
The cost of all that is a dependency. MCP is a connection to a specific system, and the value lives in that system. If you want to know what this looks like without the jargon, we wrote a plain-English explainer for L&D teams.
What Agent Skills Actually Are
A Skill is a package. It tells an agent how to produce a particular kind of thing, and what comes back is a self-contained artefact you own.
For training work that artefact is usually an interactive activity: a role-play conversation, a branching scenario, a graded document review. The agent writes it, and you get a file. In Mini Course Generator’s Agent Skills, that file is SCORM 1.2 – the packaging standard corporate learning systems have imported for two decades.
Which produces the property that matters:
A Skill’s output does not need the vendor. A SCORM package built by a Skill drops into Cornerstone, Moodle, Canvas, TalentLMS, Docebo, Brightspace, Absorb, 360Learning, SAP SuccessFactors or Workday Learning and reports its score back through the same cmi.core.score.raw field every SCORM course has used since the early 2000s. Nobody has to add an integration. Nobody has to buy anything. The LMS does not know or care that an AI agent wrote the activity.
The trade is that a Skill has no idea what happened next. It produced an activity; it is not watching your learners. It cannot notice that everyone is failing question three, because it is not connected to anything that would know.
The Decision Table
| MCP server | Agent Skill | |
|---|---|---|
| What it is | A live, authorized connection to a platform | A package the agent writes and hands you |
| What you end up with | A course inside a workspace, at a URL | A file – with MCG’s Skills, a SCORM 1.2 bundle |
| Where it runs | The connected platform | Any LMS that imports SCORM, or standalone in a browser |
| Needs an account with the vendor | Yes | No |
| Knows current state | Yes – reads live data and acts on it | No – it produced an artefact and stopped |
| Integration work required | Connect once, then nothing | None at all |
| Model | Whatever your assistant runs on | Bring your own: Claude, GPT, Gemini, or self-hosted |
| Best at | Building and running a whole course | One graded activity inside a course that lives elsewhere |
| Worst at | Producing something portable | Anything that depends on knowing what learners did |
“Is MCP Obsolete?” – The Honest Answer
No, and the question is a category error worth unpacking, because it is being asked seriously by people who are about to make architecture decisions.
The argument runs roughly: if a Skill can package up the instructions for calling an API, and an agent can execute those instructions, why maintain a server at all? The Skill is simpler, has fewer moving parts, and nothing has to be hosted.
That reasoning holds right up until the agent needs three things a package cannot carry:
Live state. A Skill is written once and is identical every time it runs. A connection reads the system as it is right now. “Which of my courses has a quiz question everyone gets wrong” is not a question a package can answer, because the answer changes hourly and lives somewhere the package cannot see.
Delegated permission. OAuth exists so a system can let an agent act as you, within your limits, without you handing over a password. A packaged instruction set has no equivalent. It either has credentials embedded in it – which is a bad idea – or it cannot act on your behalf at all.
A stable contract. When a platform changes, an MCP server updates its actions and every connected assistant gets the change. Instructions distributed as files go stale in the field, individually, on everyone’s machine.
What is genuinely true is that Skills absorbed a class of work MCP was being used for badly. If the “integration” was really just a procedure – do this, then this, then format it like that – a package was always the better shape, and a server was overhead. That is a real correction, and it is why the question is being asked at all. It is not a replacement.
Four Course-Creation Scenarios and the Right Answer for Each
Abstractions get you halfway. Here is where each one actually lands.
“We have documentation and no training. Turn it into courses.”
MCP. This is the case it was built for. Your assistant is already connected to Confluence or Notion or Drive; connecting it to a course platform closes the loop, and one prompt goes from a documentation space to a published course. We walk through the whole thing in the Confluence recipe, which is the version of this that most teams start with.
“We run Cornerstone. Corporate will not approve another platform this year.”
A Skill. This is the scenario where MCP loses and it is not close. You are not going to get a new vendor through procurement to add one role-play exercise to an existing compliance course. A Skill produces a SCORM package, you upload it the way you upload every other SCORM package, and no part of your stack changes. Nobody has to approve anything.
“We want reps practising a discovery call, and we want the scores.”
Either, and it depends on where the scores need to live. If the practice should sit inside a course you are already building, MCP keeps it in one place and the results are visible with everything else. If the scores need to land in the LMS of record next to every other completion, use the AI Role-play Skill and let SCORM carry the score home. The activity is comparable; the reporting destination decides.
“The course is live. Now keep it good.”
MCP, and only MCP. A package cannot do this at all. Reading how the quiz is performing, hardening the question everyone passes without thinking, rewording the lesson people abandon, emailing the learners who have not finished – every one of those requires seeing live data and acting on it. This is the half of the job most AI course tools do not have an answer for, and we made a whole piece out of it because it is where the difference shows up.
Using Both, Which Is the Common Case
The two combine more naturally than the framing suggests, because they operate at different layers.
A team building a customer-onboarding academy connects their assistant to the platform over MCP and builds the programme there – lessons, quizzes, structure, publishing, and the ongoing maintenance. Then, separately, they need one role-play exercise inside a compliance module that lives in the corporate LMS, because that module is audited and is not moving. They generate it as a Skill, export the SCORM package, and upload it.
Same team, same week, same assistant. One connection, one package, two different problems.
For a hands-on tour of what’s actually installable rather than the architecture argument, see Claude Skills for course creators. If you are wiring this into a wider stack, the mechanics of getting completion data where it needs to go are in our LMS integration guide – the answers differ depending on which of the two produced the activity.
What Each One Can’t Do
Both directions have a limit that is easy to miss until you have committed.
MCP needs a compatible client. Claude, ChatGPT in Developer Mode, Manus, Cursor and other assistants that support remote MCP servers. If your organisation has standardised on an assistant that does not, the connection is not available to you, and no amount of wanting it changes that.
MCP’s value is inside the connected system. The course lives there. Most platforms worth using – ours included – export SCORM and PDF so the content is not trapped, but the live course, the analytics and the ongoing loop are properties of the platform, not of the protocol.
A Skill cannot see anything. It produced an artefact. It does not know whether anyone opened it. Every “and then the agent noticed…” story requires a connection.
A Skill is one activity, not a curriculum. It is very good at the piece that is hard to build by hand – a graded, branching, conversational exercise – and it is not a course. Something still has to sequence, deliver and track the whole programme.
The Short Version
Skills versus MCP is a comparison between a connection and a package, and those are not competitors.
Use MCP when the assistant needs to act inside a real platform with live state and your permissions: building a whole course from documents you already have, publishing it, and then keeping it good using data only the platform has. Use a Skill when you need one graded, interactive activity that has to run somewhere else entirely, with no integration and no new vendor.
The question “is MCP obsolete” tends to come from teams looking for a single answer to adopt. There is not one, and the good news is that the choice is cheap. A Skill costs you nothing to try because it needs no account, and a connection takes about a minute to set up and can be revoked as fast.
If you want the connected half, the MCP server for course creation is where to start, and it takes one prompt to see whether the output is worth the connection.
Frequently Asked Questions
What is the difference between Skills and MCP?
MCP is a live, authorized connection between an AI assistant and a system it can act inside – it reads current state and takes actions through your account permissions. A Skill is a self-contained package the agent produces, which runs on its own afterwards. MCP is a connection; a Skill is an artefact.
Are Agent Skills replacing MCP servers?
No. Skills absorbed a class of work that never needed a server – procedures that were really just instructions. But anything requiring live data, delegated permissions, or a contract that updates centrally still needs a connection. The two coexist because they solve different halves of the problem.
Which is better for creating an online course?
MCP, if the course should live in a platform that will also deliver and track it. A Skill, if you need one interactive activity to drop into a course that already exists somewhere else. Most teams doing this seriously end up using both for different pieces of the same programme.
Do I need an account to use an Agent Skill?
No. That is the main practical advantage. A Skill’s output is a self-contained SCORM package that runs in your existing LMS or standalone in a browser, with no account and no integration with the vendor whose Skill produced it.
Can a Skill update a course after it is published?
No. A Skill has no connection to where its output ended up, so it cannot see learner results or make changes. Post-publish work – hardening quiz questions, rewording lessons, nudging learners who stalled – requires an MCP connection to the platform holding the data.
Does using MCP lock me into one platform?
Partly, and it is worth being clear about which part. The live course, its analytics and the ongoing agent loop are properties of the connected platform. The content itself does not have to be trapped: check that any platform you connect to exports SCORM and PDF before you commit to it.
