Skillz is an MCP server that exposes Claude Code SKILL.md files as callable tools inside any MCP-compatible agent — Codex, Copilot, Gemini CLI, Cursor, and others. Instead of reimplementing a skill for each tool, you author it once in the standard SKILL.md format and Skillz surfaces it wherever you have an MCP client. It appeared on Hacker News as 'Use Claude Skills in Codex/Copilot via MCP' ([HN id=45649295](https://news.ycombinator.com/item?id=45649295)).

Mother MCP is an aggregation layer that orchestrates multiple MCP servers and skills under one connection, letting you route skill calls across Claude, Codex, and other runtimes from a single config file. It surfaced on HN ([id=46692102](https://news.ycombinator.com/item?id=46692102)) as a way to unify the fragmented 'skill for each tool' problem. Its primary use case is teams that want one canonical skill library without per-tool install scripts.

Can I use Claude Code skills in Cursor without MCP?

Partially. Cursor reads .agents/skills natively, and Claude Code reads .claude/skills natively. If you symlink one to the other, the SKILL.md file itself travels fine — but tool-specific metadata (allowed-tools, bash hooks) may not trigger the same way in each runtime. The Skillz bridge is cleaner for skills that depend on Claude-specific execution semantics.

Do skills need to be rewritten to work via Skillz?

No. Skillz reads the standard SKILL.md format and wraps it as an MCP tool. Your existing Claude Code skills work without modification, with the caveat that any skill using bash scripts or Claude-specific hooks will only execute fully in a Claude Code session — the bridge exposes the instructions and description surface, but the host tool decides what to execute.

Is this the same as installing the skill natively in each tool?

Not exactly. Native install gives the tool full context integration — path scanning, implicit trigger on description match, progressive loading. The Skillz/MCP bridge is an explicit call layer: the agent invokes the skill as an MCP tool rather than discovering it implicitly. Both approaches work; the native path is smoother for skills you own, the bridge is better for sharing across org members using different tools.

Run Claude Skills in Any Agent: Skillz, Mother MCP, and the Cross-Tool Bridge

# Run Claude Skills in Any Agent: Skillz, Mother MCP, and the Cross-Tool Bridge You wrote a skill that works great in Claude Code. Then a teammate uses Codex. Another uses Copilot. Now you have three skill directories to maintain instead of one. That problem has two working solutions. Skillz and Mother MCP are both MCP-based bridges that let Claude Code skills run across tools without reimplementing them per agent. This page explains how they work, where they fit, and what they can't do.

Why the problem exists

The SKILL.md format is converging across tools — Claude Code, Codex, and Goose all read it natively. The format is portable. The discovery paths are not. Claude Code reads .claude/skills. Codex reads .agents/skills. Goose reads both (with compatibility bridges). Cursor and Copilot have their own conventions. A skill you author for Claude Code does not automatically show up in Codex unless someone creates the mirrored directory and keeps it in sync. At five skills, that's manageable. At fifty, it's a maintenance job. The deeper problem is execution semantics. Claude Code skills can use allowed-tools, bash hooks, and progressive loading. When a Codex session reads the same SKILL.md, it applies Codex's own execution model. The skill text travels; the Claude-specific behavior doesn't.

How Skillz solves it

Skillz wraps your existing skill library as an MCP server. Any agent with an MCP client can call the skills as tools — Codex, Copilot (with Copilot Extensions), Cursor, Gemini CLI. The flow:

You run Skillz pointing at your ~/.claude/skills directory (or .agents/skills).

Skillz reads the SKILL.md files and exposes each as an MCP tool with the skill's description as the tool description.

Any connected MCP client sees the skill as a callable tool. Implicit trigger matching — the description-based activation that Claude Code uses — is preserved because the tool description carries the skill's description field.

When the tool is called, Skillz serves the skill's full content as the response.

The key constraint: Skillz serves the skill content, but the host tool executes it under its own runtime. A skill with a scripts/ folder runs those scripts only if the host agent supports bash execution. Codex supports it. Copilot does not (as of mid-2026). Design skills with this in mind: put logic in the instruction text, not in shell scripts, for the broadest portability.

How Mother MCP solves it

Mother MCP operates at a higher level. Rather than exposing one skill library, it aggregates multiple MCP servers and skill sources under a single connection endpoint. A typical use case: your team uses Claude Code, Codex, and Cursor. You have three separate MCP configs, three separate skill directories, and three sets of update pain. Mother MCP lets you declare one config file that lists all three skill sources plus any other MCP servers. Every agent connects to Mother MCP as a single endpoint and receives the full combined tool surface. The practical difference from Skillz: | | Skillz | Mother MCP | |---|---|---| | What it exposes | One skill library as MCP tools | Multiple skill sources + MCP servers, aggregated | | Primary use case | Single-library cross-tool access | Unified config for multi-tool teams | | Config complexity | Low — point at a directory | Medium — declare all sources in a manifest | | Best for | Individual developer, one skill repo | Teams with multiple tool preferences | Both use MCP as the transport, so they compose: Skillz can be one of the servers Mother MCP aggregates.

The native-install alternative

Before adding a bridge, consider whether you actually need one. The /topic/agent-skills-cross-tool page documents the three sane strategies for multi-tool teams without a bridge: canonical source in .agents/skills with symlinks into .claude/skills, or a simple install script that copies files at project setup. If your team is small, your skill library is stable, and you don't need real-time sync, a symlink or copy is lower operational overhead than running a persistent MCP server. The bridge approaches (Skillz, Mother MCP) earn their complexity when:

You have a large skill library that's updated frequently

Team members use 3+ different agents

You want changes to the canonical library to propagate to all agents without anyone re-running install scripts

You want to share skills across repos without committing them per-project

What still doesn't travel

Two things the bridge cannot fix: 1. Claude-specific execution hooks. Skills that use allowed-tools: Bash and depend on Claude Code's permission model will show up as MCP tools in other agents, but those agents decide whether to honor the execution scope. A skill that runs npx tsc --noEmit via bash works in Claude Code and Codex. The same skill in a Cursor ask-mode session may present the instruction text without running the script. 2. Claude-specific trigger semantics. Claude Code's implicit skill activation — where writing "review this PR" automatically triggers a skill whose description mentions "pull request review" — relies on Claude's own reasoning in the system prompt. Via MCP, other agents see the tool description and decide whether to invoke it based on their own routing logic. The match quality varies. If your skill relies on either of these, it's a Claude-first skill. Document that, and use the native-install path for Claude Code deployments.

Authoring skills for portability

A few changes at authoring time make skills more portable across all of these routes. Keep the instruction text self-contained. Don't assume the agent executing the instructions has access to a specific bash tool or knows Claude Code's hook model. Write instructions that work as pure text directions. Use description as the trigger surface and keep it precise. Both Skillz and native discovery use the description for implicit matching. A vague description means the skill fires at random. The /topic/skill-description-engineering page has the rules for this. Separate the cross-tool core from the Claude-specific shell. If a skill has a broadly portable instruction layer (the logic) and a Claude-specific execution layer (the bash hooks, the allowed-tools scope), split them. Publish the core as a portable skill and the Claude-specific part as a CLAUDE.md addition or a hook config. Before publishing to RuleSell, run the /topic/skill-security-checklist pass — especially for skills you're distributing via a bridge, since the skill will execute in runtimes you don't control.

Sources

Hacker News. "Skillz: Use Claude Skills in Codex/Copilot via MCP". The Show HN thread documenting Skillz as a cross-tool bridge for SKILL.md files.

Hacker News. "Mother MCP: aggregate MCP servers and skills across agents". The Show HN thread for Mother MCP as a unified config layer.

Anthropic. Extend Claude with skills. Claude Code's native skill discovery and execution model.

OpenAI. Agent Skills for Codex. Codex's skill path conventions and execution model.

Goose. Using Skills. Goose's bridging of both .agents/skills and .claude/skills paths.

VoltAgent. awesome-agent-skills. 23.6k-star skill catalog documenting compatibility across Claude Code, Codex, Antigravity, Gemini CLI, Cursor, Copilot, OpenCode, and Windsurf.