Anthropic Skills, OpenAI Apps, Gemini Extensions — the same problem, three shapes

Every major model provider now has a way to give the AI more "hands." Anthropic calls them **Skills** and **Agent SDK plugins**. OpenAI calls them **Apps**, fresh out of DevDay. Google calls them **Gemini Extensions**. MCP — the vendor-neutral protocol — sits underneath all three at different depths of adoption. If you're building on more than one model, you're already staring at the same feature with three different UX contracts, three different manifest formats, and three overlapping stores. Here's what actually matters, filtered through what we've shipped this year from a small research lab. ## What each one is, in one line - **Anthropic Skills** — versioned bundles of instructions plus optional tools that Claude discovers on demand. Markdown-first, code-adjacent. - **OpenAI Apps** — full app surfaces (custom UI plus tool calls plus auth) that live inside ChatGPT and expose your product to its users. Full-fat SDK. - **Google Gemini Extensions** — first-party integrations for Google's own surfaces (Workspace, Search) plus a developer path for third-party ones. - **MCP (Model Context Protocol)** — the open protocol that any of the above can ride on. Anthropic ships MCP servers as first-class. OpenAI's SDK can consume MCP tools. Google's roadmap includes broader MCP support. ## Where the friction actually is All three answer roughly the same question — "how do I add a tool the model can call?" — but they answer it at different levels of the stack. **Anthropic Skills** live at the *instruction* level. You are teaching Claude what to do more than adding new capabilities. **OpenAI Apps** live at the *product* level. You are building a mini-product inside ChatGPT — its own UI, its own auth, its own approval flow. **Gemini Extensions** live at the *integration* level. You are wiring a third-party into Google's surfaces. If you pick the wrong altitude, you will fight the framework for a week. ## Our take from actually shipping We run a small AI-native research lab. Two of our tools — Forgecast (content agent) and Job Hunt Automation (Claude Code plugin) — expose functionality via MCP. That gives us one manifest that any vendor's presentation layer can point at, and lets us skip re-implementing the same tool surface three times. The pattern we settled on: 1. **Write the tool once as an MCP server.** Vendor-neutral. Runs anywhere. 2. **Wrap the MCP server with each vendor's presentation layer.** A Skill wrapper for Anthropic, an App shell for OpenAI, an Extension manifest for Google. 3. **Keep the business logic in step 1.** Only the presentation moves. This has saved us at least one refactor per model migration. ## When to skip MCP MCP is right when you have real capabilities that generalize across models. It is overkill for: - One-shot prompt tricks. That is a Skill, plainly. - UIs that only make sense inside one host. That is an App, no shame. - Google-only Workspace glue. Extension, closed loop, done. Do not force a protocol on work that does not need one. ## What to watch next - **OpenAI Apps SDK approval flow** — currently the biggest surface-area difference between the three. Skills self-serve. Apps need review. - **Gemini Extensions opening beyond Google surfaces** — if this ships broadly, MCP becomes the obvious lowest-friction bet. - **The Anthropic Skills registry** — the ergonomic layer above raw MCP that the other vendors have not fully copied yet. ## The one takeaway If you are building a tool you plan to use across models: **write it as an MCP server first**, then wrap. If you are building a product that only makes sense inside one host: use that host's native app surface and do not overthink it. The stack matters less than knowing which layer you are operating at.