GitHub Copilot Skills vs. MCP Servers: What to Use in July 2026, and What Not

Microsoft rolled out GitHub Copilot Skills in June 2026 as a new function layer, alongside the established MCP ecosystem. At first glance, both look like toolboxes for AI agents. At second glance, they are two competing answers to the same question: how does an agent get at procedural knowledge and external tools? Mid-sized companies that decide in the next weeks which of the two worlds enters their workflow implicitly decide on three years of platform lock-in.

What Copilot Skills are, and what they are not

Copilot Skills are curated, reusable instruction sets that live as markdown files in a GitHub repository. They are loaded into the prompt on demand, interpreted by Copilot, and passed on as instructions to the agent. Skills encapsulate workflows, code conventions, coding practices, or compliance rules. They are declarative, not executable. A typical skill bundle in July 2026 contains five to twelve markdown files plus a manifest that governs selection.

The decisive difference from classic Copilot custom instruction setups: skills are versioned, project-specific, and selected by the agent at runtime. If the repo has a skill for "refactoring legacy Python 2 code", it is only loaded when the agent recognises that the request fits. That is resource-efficient and controlled.

What MCP servers are, and what they are not

Model Context Protocol servers are small services that expose tools which an agent can call at runtime. An MCP server for an internal Jira instance exposes methods like "create_ticket" or "search_issues"; the agent calls them via JSON-RPC, the result flows into the next prompt. MCP servers are code. They are run, versioned, authenticated, and audit-logged. According to Anthropic tracking, the MCP ecosystem in June 2026 has around 10,000 public servers, with 9,652 entries in the official registry and 97 million monthly SDK downloads.

The decisive difference from skills: MCP servers execute actions and return results. They are tools, not instructions. If you have a Jira MCP connection, the agent can create tickets. If you have a Jira skill, the agent knows how the agent should create tickets, but has no Jira access.

Three use cases where Skills are clearly better

1. Coding conventions and code style. Which architectural patterns apply in the project, which test conventions, which naming standards. These rules can be expressed declaratively in markdown, without triggering external actions. Anyone using MCP here builds a server that returns "lint_check", which is overhead without value.

2. Compliance and security instructions. Which data must not flow into the LLM, which code paths are off-limits, which reviewers must be notified before merge. Skills are the natural format because they are read by the agent before it acts. Anyone building an MCP server for this that offers "policy_query" pushes logic into infrastructure that belongs as markdown next to the code.

3. Domain-specific workflow descriptions. Which steps belong to our release process, what our incident response playbook looks like. Skills carry knowledge that the agent needs to generate instructions, not data it needs to act on.

Three use cases where MCP servers are clearly better

1. Live data from internal systems. Jira, Confluence, GitHub Enterprise, internal databases, observability stacks. Anyone who wants to give an agent access to their own Jira cannot avoid an MCP server. A skill can describe the Jira workflows but cannot read the actual tickets.

2. Writing actions with authentication. Teams that want the agent to create tickets, open pull requests, or trigger deployments need an MCP server with authentication. Skills can describe the action but cannot execute it.

3. External data sources with rate limits. Web search, weather APIs, exchange rates, regulatory databases. MCP servers encapsulate the rate-limit handling, caching, and error handling. Skills would burden the agent with these operational details every time.

What concretely gets decided in July 2026

Microsoft pushes Copilot Skills strategically because they play to Microsoft's data and compliance advantage. Anyone working in VS Code gets skills out of the box, without running their own MCP server. For Microsoft-centric mid-sized companies, that is the path of least resistance.

MCP remains the open standard, supported by Anthropic, OpenAI, and other providers. Anyone building skills-only locks themselves to Microsoft. Anyone building MCP-only carries their own infrastructure footprint that costs operation and maintenance. The question is not "Skills or MCP", but "which tasks do I solve with which technology".

How centerbit uses the combination

In our projects we follow a simple heuristic: if the agent only needs knowledge to decide the next step, it is a skill. If the agent does something in the real world or reads real data, it is an MCP server. Concretely that means: coding standards as skills, Jira access as MCP, incident response playbook as skills, observability data as MCP, compliance rules as skills, internal database access as MCP.

This separation has two effects: the number of MCP servers stays small and manageable, usually three to five per project, and the skills become a living part of the code repository, versioned with the code, reviewable in the pull request.

Recommendation

If you decide in the next four weeks: run a skill inventory to see what conventions, instructions, and playbooks already live in the repo. Teams that already had Confluence pages with coding standards can often transfer them one-to-one into skills. Teams that then set up MCP servers do it for the two to three core integrations the team actually needs, not for an entire ecosystem.

The question is not Skills versus MCP. The question is whether you keep procedural knowledge in the repo or outsource it into external infrastructure. The answer depends on how much you want to control yourself.