Agent skills vs MCP: an open-source repo keeps two grants apart

You need both, for two different jobs

The question people actually ask is whether they need both, and the answer starts with what each thing carries. The Model Context Protocol is an open standard for connecting AI applications to external systems: data sources, tools and workflows. MCP describes itself as a USB-C port for AI applications: one connector for many devices (MCP introduction). A skill is a directory containing, at minimum, a SKILL.md file, and the format exists to hand an agent the procedure for a task (Agent Skills specification).

One sentence is about reach. The other is about judgment. MCP standardizes the connection; it does not describe how a particular company does a particular job. That gap is where skills sit, and it is why the "MCP is dead" framing costs teams money. Retire the servers for a folder of instructions and the agent knows the procedure and cannot reach a single invoice. Add only servers and the agent reaches everything and still approves the wrong invoice.

More than 70 platforms have integrated Agent Skills, including ChatGPT, Cursor, GitHub Copilot and VS Code. As of October 2026 both standards live under one foundation. Anthropic donated Agent Skills, its name, logo, GitHub organization and the agentskills.io domain, to the Agentic AI Foundation (AAIF) under the Linux Foundation, which it co-founded with Block and OpenAI; the Model Context Protocol was donated there too (Anthropic). Two specifications, one home, two jobs. Kortix ships that arrangement: both mechanisms, each with its own grant, in one repo.

One invoice, one server, one skill

An accounts-payable agent shows the split faster than a diagram. Its connector is the billing system: list open invoices, read the line items, post an approval decision. A server exposing those three operations is where MCP earns its place, because one protocol lets any client call it instead of an integration per application.

The company's half is a skill; in a Kortix project a skill is skills/<name>/SKILL.md, and reference files can sit beside it. So the approval policy travels with the instructions that use it.

---
name: invoice-approval
description: Approve supplier invoices. Use when an invoice is queued for payment.
---

Match the purchase order and the receipt before you approve.
The AP lead approves under 2,500. The controller approves over it.
Reject a duplicate vendor invoice whatever its amount.

The two halves fail differently. Take away the skill and the agent still reads every invoice, then approves whatever the schema lets it approve. Take away the connector and the policy has nothing to read. The manifest keeps that apart:

kortix_version: 2
agents:
  accounts-payable:
    file: agents/accounts-payable.md
    connectors: [billing]
    skills: [invoice-approval]

Two keys, one list each. The connector decides which systems the agent may call. The skill decides whose procedure it loads.

What each mechanism costs in context

Skills were designed around a small, predictable bill. Metadata is about 100 tokens and loads for every skill at startup; the full SKILL.md body loads when the skill is activated, with under 5,000 tokens recommended; bundled files load only when read (specification). Forty skills in a repo cost roughly 4,000 tokens before anyone asks for work, and the skill that loads adds its body.

MCP pays in another currency. A client lists a server's tools and passes their names, descriptions and schemas to the model so it can choose one (architecture), and that listing is context a turn spends whether or not the task touches the server. Connect six servers and a turn can open with six catalogs.

The two numbers do not compare. A skill's 100 tokens buy a title. An MCP tool listing buys an interface, and no skill can query a database. What the budgets do say is about scope: many skills stay cheap, many servers do not, so grant few servers and write many skills.

That budget only holds if the host respects it. Kortix does not put skill bodies in every prompt. description is what the agent reads to decide when to load the skill; write when to use it, not only what it is.

Two grants, not one

This is the half most comparisons skip. Which skills an agent may load is a grant in kortix.yaml, set for each agent. A skill in skills/ is usable only when that agent's grant allows it. The same block carries connectors, which names the systems an agent may call, so the two mechanisms are granted in two keys of one file (read the docs).

That split is the governance argument in one line. Revoking a connection and revoking a procedure are different decisions with different blast radius. A system that fuses them into one switch makes both harder to review, which is how teams end up granting a billing connector so that an agent can read a style guide.

Skills are files a person reviews, and a change to one lands the way any other change does. Session work reaches main through a change request. Merge is default-deny for agents. kortix.yaml declares the machine image, connectors and triggers, and secret names and grants. Secret values never appear in the repo. Open source. Read it, fork it, audit it.

When a skill alone is enough

Plenty of jobs need no server at all: a review rubric, a document template, the house style for a support reply, the checklist a release needs. Write those as skills and stop. A connector with no system behind it is a permission with nothing to do.

The test cuts the other way too. When the job is lookup with no judgement in it, a read-only connector answers it and a skill adds nothing.

So the rule is one line. If the failure you fear is that the agent cannot reach the data, add a connector. If the failure is that it reaches the data and does the wrong thing with it, write a skill. Most real work carries both risks, which is why the two mechanisms are granted together and reviewed apart.