“If it’s a single function — hey, I’m gonna ask you a question, you send me a response — then API is going to be way faster. If there are a lot of different ways to retrieve and sort and search, then MCP works well, because then it’s one connection for multiple services. And a skill lets you give people access to your IP without showing them the code — you can hide the IP behind the API.” — Lou, 2026-05-21
Session context: 2026-05-21_Mastermind — Dirk asked whether AIM members should be packaging their offerings as MCP servers that clients connect to their own Claude instances. Lou responded with the full decision framework: MCP, API, and Skill are three different patterns for exposing your knowledge to someone else’s AI, each with distinct tradeoffs.
Core Idea
There are three viable patterns for putting your expertise inside someone else’s AI workflow. Choosing between them is not a technology decision — it is a decision about what you are exposing and how you want it consumed.
API (direct programmatic access). You expose endpoints. The client’s agent calls them. Fastest path for a single-function transaction — “ask a question, get a response.” No protocol overhead, no interpretation layer between the question and the answer. The cost is integration: the client (or their agent) has to know your API contract, handle auth, manage retries. Right choice when the use case is narrow and the consumer is technical enough to integrate directly. Also the right choice when you want to hide your IP — APIs expose responses, not the logic that produced them.
MCP (Model Context Protocol). You expose a connector. The client adds your MCP server to their Claude / Cursor / Cowork configuration once, and from then on their agent can call any of your services without per-call integration. Right choice when you have many related services (retrieve, sort, search, store) and the client is going to use them across many sessions. The tradeoff is that MCP calls have more overhead than raw API calls — Lou’s rule of thumb on the call was “API is about 10 times faster than MCP because it doesn’t have to go through as much thinking.” MCP wins on breadth and convenience; API wins on speed and isolation.
Skill (installed bundle). You ship a folder of prompts, instructions, and optionally code that the client installs into their own Claude. The client now has your process, not just your responses. Right choice when the value is the workflow, not the data — when what you are really selling is “this is the right way to do X, here are the prompts and steps.” The cost is the most expensive in terms of IP exposure: the skill is readable, so the client can see (and copy) your methodology. The mitigation is to wrap the skill around an API call — the visible skill handles the orchestration and UX, while the actual IP lives behind an endpoint the client cannot see into.
The three patterns are not mutually exclusive. The mature pattern is all three at once: an API that holds the core IP, an MCP that wraps the API with a multi-service connector, and a Skill that wraps the MCP/API in a workflow the client can install and run. The client picks the level of integration that matches their technical sophistication. Lou explicitly named this on the call — “Gears” uses a skill that wraps an API; “Janssen” uses an MCP; they could have used either pattern. The right choice depends on the audience and the IP-protection requirement.
Why This Matters for Knowledge Entrepreneurs
The platform decision is upstream of every distribution decision. If you are selling a workflow to non-technical clients, a skill they can install in their existing Claude is the lowest-friction path — and you accept that they can read your methodology in exchange for the ease of adoption. If you are selling a queryable knowledge product (a curated dataset, a continuously-updated expert lookup), an API + MCP wrapper lets sophisticated clients integrate and lets less-sophisticated clients install a skill that uses both. If you are selling a single transactional service — “answer this kind of question” — a plain API is faster and easier to monetise per call.
The forward-looking framing from the session: design for agents, not for humans. In the near future, the consumers of your interfaces will mostly be other agents — your client’s Claude calling your MCP, or your client’s skill calling your API. Agents do not need a UI. They need clear contracts and fast endpoints. This is the practical implication of Insight - Your Expertise Becomes an Interface — How Clients’ AI Accesses Your Intelligence Layer: stop building UIs for users who will not see them, and start building well-typed interfaces for the agents that will.
The IP-protection layer matters more than people realise. A skill is readable; an API is opaque. If your moat is what you know, an API in front of your model preserves it. If your moat is how you work, a skill makes the workflow visible — which can be a feature (clients trust what they can read) or a liability (the workflow gets copied) depending on your business model.
Practical Application
Use this decision tree the next time you are deciding how to expose a piece of expertise to a client’s AI:
- What is the unit of value? A single answer per call → API. A workflow → Skill. A multi-service connector → MCP.
- How technical is the consumer? Engineering team → API direct. Power user in Claude / Cowork → MCP. Non-technical end-user → Skill.
- How sensitive is the IP? Trade-secret methodology → API only, wrap in skill/MCP if you must. Methodology is the product → Skill is fine; the readability is the trust signal.
- What is the call volume profile? High-volume single-function → API for speed. Sporadic multi-service → MCP for convenience. One-shot workflow installs → Skill.
- Can you stack? Almost always yes. Build the API first (it is the core IP), wrap in MCP for connector-style adoption, wrap that in a Skill for non-technical install. The cost is not 3x — each layer is a thin orchestration over the one beneath it.
Coaching question: “If a client asked me to make my expertise available to their Claude tomorrow, would I default to MCP because it sounds impressive, or would I pick the pattern that actually matches my IP-protection requirement and their integration capability?”
Related Insights
- Insight - Your Expertise Becomes an Interface — How Clients’ AI Accesses Your Intelligence Layer — The conceptual framing under which “design for agents” makes sense; this insight is the implementation layer.
- Insight - Build a Living Prompt Library Behind an MCP Server — A specific MCP-pattern application; this insight gives the broader decision context.
- Insight - Persistent AI Memory via MCP - Building a Cross-Session Intelligence Layer — Another MCP-specific application.
- Insight - Skills Encode Judgment Into Persistent, Composable Intelligence — Why skills are sometimes the right answer even though they expose IP.
- Insight - Self-Host Your AI Stack to Own Your Knowledge Product — The ownership posture that informs which pattern to choose.
Evolution Across Sessions
Builds on Insight - Your Expertise Becomes an Interface — How Clients’ AI Accesses Your Intelligence Layer and Insight - Build a Living Prompt Library Behind an MCP Server, both of which established MCP as a valid distribution channel. The new development is the decision framework itself — naming the three patterns side-by-side, the speed/IP/audience tradeoffs that distinguish them, and the stacking pattern (API as core, MCP as connector, Skill as install wrapper) that lets you serve all three audiences from one core asset.
Source
- 2026-05-21_Mastermind (Dirk asked whether MCP was the right pattern for client offerings; Lou walked through the full three-pattern framework)