Model: openai/gpt-5.4
Generated: 2026-04-01
Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead
Chapter: 10 — Oh-My-OpenCode’s Innovations
Token Usage: ~3,900 input + ~980 output

10.7 Skill-Embedded MCPs

OMO’s skill-embedded MCP design is a significant extensibility innovation because it collapses what are often three separate things—prompt guidance, packaged capability, and external tool connectivity—into one portable unit. The relevant implementation lives around src/features/skill-mcp-manager/, supported by tools like skill_mcp and integrated with the broader plugin loader system.

To appreciate why this matters, it helps to recall what MCP is for. Model Context Protocol gives agents a standard way to talk to external tools, resources, and prompts. In many systems, MCP servers are configured globally or at the project level. Skills, meanwhile, are just prompt assets or instruction bundles. OMO bridges these worlds by allowing a skill to embed its own MCP server definitions.

That means a skill can carry not only instructions about how to do a task, but also the machine-accessible capabilities needed to do it.

The architecture is three-tiered.

First are OMO’s built-in MCPs, including remote integrations such as Context7, Exa/Websearch, or grep.app-style services. Second is the Claude Code compatibility layer, which can import MCP definitions from .mcp.json. Third is the genuinely distinctive layer: skill-embedded MCPs. This third tier is what makes OMO stand out.

The SkillMcpManager class shows the core responsibilities. It handles connection pooling, pending-connection tracking, retry and reconnect logic, step-up authentication flows, idle cleanup, and per-session client identity. It supports both stdio transport and HTTP transport. That dual support is important. Stdio means a local process communicates over standard input and output streams; HTTP means the tool is exposed as a remote network service. OMO can treat both as first-class MCP backends for skills.

This is not a trivial convenience feature. It solves a packaging problem. Suppose a skill teaches the agent how to use a certain service or workflow. In a weaker system, the user must separately install and configure the needed external tools, then hope the prompt and tooling line up correctly. In OMO, the skill can arrive with its own MCP declaration, reducing mismatch between instructions and capability.

In effect, the skill becomes an executable knowledge package.

This also improves portability. If a team shares a skill, they can share the operational surface with it. That is much closer to dependency packaging in software engineering than to traditional prompt snippet sharing. The skill is no longer just advice. It is advice plus attached machinery.

The manager’s design also shows engineering seriousness. It keys clients by session, skill name, and server name. It retries operations, handles “not connected” states through forced reconnection, and exposes listing and invocation methods for tools, resources, and prompts. That means OMO is not merely stuffing MCP metadata into skill files; it is providing lifecycle management robust enough for real use.

There is a strategic implication here as well. OMO is moving toward a model where extensibility is content-centric rather than platform-centric. Instead of saying “all capabilities must be installed into the platform globally,” it says “capabilities can travel with the skill that teaches them.” This resembles the way modern software ecosystems increasingly bundle code, configuration, and metadata together.

Compared with Claude Code and basic OpenCode setups, this is unusual. Both can certainly use MCPs, and Claude Code has its own MCP configuration story. But the explicit integration of MCPs inside reusable skill artifacts is much more distinctive in OMO.

The trade-off, of course, is complexity and security surface. If skills can bring executable capability with them, then skill loading becomes much more sensitive. Trust, review, and cleanup become essential. OMO’s architecture therefore becomes more powerful but also more supply-chain aware.

Even so, the direction is compelling. Skills are far more useful when they can do more than speak. MCPs are far easier to use when they are bundled with the context that explains them. OMO’s skill-embedded MCP architecture unifies those two facts.

For future coding agents, this may prove to be an important design pattern: treat skills not as static prompt files, but as capability capsules containing instructions, conventions, and tools in one deployable package.