I hosted a live debate on MCPs vs Skills with Jon Tiritilli (Principal Engineer, Domo) and community members from the Domo User Group. The conversation went deeper than I expected — we covered security, context rot, authentication, and whether the "vs" framing even makes sense.
What MCPs Actually Are
MCP stands for Model Context Protocol — Anthropic's 2024 specification for how LLMs discover and call tools on external systems. Someone called it "the USB-C for AI agents." The core idea: Claude generates JSON (a function call), the MCP server receives it, executes the function, and returns the result.
An MCP server is just a collection of tools — functions with descriptions that Claude reads to decide which one to call. You can build one with fastmcp, define your tools, and Claude figures out the rest.
The Security Question
This is the one people don't think about enough. When you give credentials to a remote MCP server, you're authorizing it to act on your behalf. If you're using Domo's hosted MCP, you're passing them your access token. If you're using some random MCP on the internet, you're giving that server your GitHub credentials, your email credentials, whatever.
Local MCPs (running on your machine) are safe. Cloud-hosted MCPs are a different story. You should understand what the MCP is capable of — can it delete data? Create users? Send emails? Every week there's a story about someone's GitHub repo getting deleted or someone spending $10K on API calls because they gave an agent unfettered access.
MCPs have solved this with OAuth and refresh tokens — you're not storing raw credentials in the config anymore. But the fundamental question remains: who holds your credentials, and what can they do with them?
Context Rot
As you add more MCP tools, Claude's context window fills up with tool definitions. Every tool description, every parameter spec — it all counts against your token budget. The more tools you register, the less room Claude has for actual reasoning.
Skills solve this with lazy loading and progressive disclosure. A skill is only loaded when it's needed. You can have 50 skills and Claude only sees the ones relevant to the current task. MCPs don't have this yet — every connected tool is always in context.
The Overlap: Same Function, Different Wrapper
Here's where the "vs" framing breaks down. The same function can be a skill or an MCP tool. The logic is identical. The only difference is the wrapper:
- As a skill: a markdown file in
.agents/skills/that Claude reads when needed - As an MCP tool: a function decorated with
@mcp.tool()that Claude calls via the MCP protocol
Jon and Elliot both made this point: it's an implementation decision, not an architectural one. You choose the wrapper based on how you want to distribute and access the tool.
When to Use What
MCPs make sense for:
- Exploratory analytics — "Hey Claude, put a dashboard together for me"
- Non-technical users who can't write code but can ask Claude to do things
- Platform integrations — one MCP per external system (Domo, GitHub, Slack)
- Getting a first draft of a data product without starting from scratch
Skills/runbooks make sense for:
- Repeatable DevOps workflows — upsert user, manage roles, configure allow lists
- Scheduled operations you'd waste tokens asking Claude to regenerate
- Personal workflows that are hyper-specific to how you work
- Team-shared SOPs that need to be version-controlled and auditable
The hybrid approach:
- Use MCPs for platform integrations (one MCP per external system)
- Use skills for personal workflows and local development
- Use runbooks for team-shared processes that need to be consistent
Strong Opinions Held Loosely
I started by building MCPs for everything. Then I switched to skills for everything. Then I wrote runbooks for everything. Now runbooks are breaking on me too. The honest answer is that the ecosystem is still evolving, and the right tool depends on the use case.
Jon's framing is the right one: strong opinions held loosely. Have a position, but be willing to change it when the technology or your use case evolves.
Guests
- Jon Tiritilli — Principal Applied AI Engineer, Domo (LinkedIn)
- Elliot — Domo community member
- Alec, Jeff, Jake — community attendees
Video chapters:
- 0:00 — Intro and housekeeping
- 2:30 — What's your experience with MCPs?
- 5:45 — Elliot: MCP vs skill is an implementation detail
- 7:00 — Jae and Jon introduce themselves
- 10:15 — What is MCP?
- 12:05 — Security: passing credentials to MCP servers
- 14:25 — MCP architecture: Claude → JSON → MCP → API
- 15:05 — Building an MCP server with FastMCP
- 17:00 — Tools that wrap multiple APIs
- 21:15 — Context rot: 500-900 tokens per tool definition
- 25:30 — MCPs vs Skills: always load vs progressive disclosure
- 27:00 — Progressive disclosure explained
- 29:40 — Domo's MCP: Java-based, lazy loading coming this summer
- 32:45 — Jae's take: skills as runbooks, MCPs as platform wrappers
- 34:20 — Webinar runbook walkthrough
- 38:05 — Cross-domain workflows belong in skills, not MCPs
- 39:20 — Jon: don't write local MCPs, use company-hardened ones
- 41:30 — The Figma/LinkedIn example: write a skill that knows the MCP exists
- 42:25 — Token cost concern: 40+ tools in a company MCP
- 43:30 — Jae's YouTube automation: functions + runbooks, not an MCP
- 44:50 — The water heater analogy: tool belts and lazy loading
- 45:55 — When MCPs make sense: exploratory analytics, not repeatable DevOps
- 47:25 — Code Engine MCPs: sharing across a team
- 49:40 — Full circle: MCP works for some things, skills for others
- 50:10 — What do you hate doing?
- 51:35 — Alec: first drafts of data products, refactoring dashboards
- 53:25 — Alec: skills are local, MCPs are external — is that right?
- 54:30 — The overlap: skills can do remote things too
- 55:45 — Same function, different wrapper: skill vs MCP tool is implementation
- 57:30 — Teaching Claude to update data flows, swap join tiles
- 58:40 — Strong opinions held loosely
- 59:40 — Community Q&A: what don't you know to ask?
- 1:01:00 — Outro and next session
This was a Domo User Group webinar. Join the conversation at domousergroup.slack.com.
