| version-requirements |
|
|||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| version-last-verified | 2026-02-27 | |||||||||||||||||||||||||||
| measurement-claims |
|
|||||||||||||||||||||||||||
| status | PRODUCTION | |||||||||||||||||||||||||||
| last-verified | 2026-02-16 | |||||||||||||||||||||||||||
| evidence-tier | B | |||||||||||||||||||||||||||
| applies-to-signals |
|
|||||||||||||||||||||||||||
| revalidate-by | 2026-07-15 |
Source: Tenzir Blog - "We Did MCP Wrong" (Matthias Vallentin, January 2026) Evidence Tier: B (Production data from active project)
MCP (Model Context Protocol) and Skills represent two different approaches to extending Claude Code's capabilities. Production data shows Skills can be 50% cheaper than equivalent MCP implementations, though MCP may be faster. The choice depends on environment constraints and cost sensitivity.
SDD Phase: Cross-phase (architecture decision affecting all phases)
"When you're paying per token, 'slower but half price' wins." — Matthias Vallentin, Tenzir
Tenzir compared identical workflows delivered via MCP server vs Claude Code Skills:
| Metric | MCP | Skills | Winner |
|---|---|---|---|
| Duration | 6.2 min | 8.6 min | MCP (38% faster) |
| Tool calls | 61 | 52 | Skills (15% fewer) |
| Cost | $20.78 | $10.27 | Skills (50% cheaper) |
| Cached tokens | 8.8M | 4.0M | Skills (55% less) |
Key Finding: The Skills approach produced working output at half the cost of MCP.
MCP Server
├── Custom tools: run_pipeline, docs_read, run_test
├── Purpose-built infrastructure
├── Each tool call = interaction with custom server
└── 61 tool calls total
Characteristics:
- Heavy reliance on custom-built tools
- Each tool call involves MCP server round-trip
- Infrastructure must be maintained
- Optimized for specific domain (TQL in Tenzir's case)
Skills
├── Generic tools: Bash, Write, Read
├── Orchestration: Task, Skill, AskUserQuestion
├── Leverages Claude's native capabilities
└── 52 tool calls total
Characteristics:
- Uses mostly generic/native Claude Code tools
- Instructions loaded as context, not infrastructure
- No custom server to maintain
- Portable across projects
┌─────────────────────────────────────────┐
│ MCP SERVER APPROACH │
├─────────────────────────────────────────┤
│ │
│ Client ──► MCP Server ──► Tools │
│ │ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Custom infrastructure │ │
│ │ run_pipeline │ │
│ │ docs_read │ │
│ │ run_test │ │
│ └──────────────────────┘ │
│ │
│ Philosophy: Build tools that │
│ structure context FOR the AI │
│ │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ SKILLS APPROACH │
├─────────────────────────────────────────┤
│ │
│ Claude ──► Native Tools + Skill Docs │
│ │ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Generic capabilities │ │
│ │ Bash │ │
│ │ Read/Write │ │
│ │ Task (orchestration) │ │
│ └──────────────────────┘ │
│ │
│ Philosophy: Teach the AI HOW to use │
│ existing capabilities effectively │
│ │
└─────────────────────────────────────────┘
Key Insight: Instead of building custom tools that structure context, teach Claude how to use generic tools effectively via skill documentation.
| Scenario | Why MCP |
|---|---|
| Sandboxed execution required | MCP servers can run in isolated environments |
| Deterministic validation needed | Custom tools can enforce exact behavior |
| Local/constrained models | Models need more structured assistance |
| Pipeline orchestration | MCP excels at stateful multi-step workflows |
| Persistent connections | WebSocket-based MCP maintains state |
| Speed critical | 38% faster execution in benchmarks |
| Scenario | Why Skills |
|---|---|
| Cost-sensitive workflows | 50% cheaper per task |
| Cloud/frontier models | Models capable enough to use generic tools |
| Portable instructions | Skills work across projects without infrastructure |
| Rapid iteration | No server deployment, just markdown |
| Internet-connected workflows | Can leverage external resources |
| Maintenance burden concern | No custom infrastructure to maintain |
"Tools should match the environment." — Tenzir Team
| Environment | Recommendation |
|---|---|
| Claude Marketplace + frontier models + internet | Minimal Skills |
| Local models + constrained environment | Rich MCP servers |
| Mixed environment | Hybrid approach |
For teams with both needs, consider a hybrid approach:
┌─────────────────────────────────────────────────────────┐
│ HYBRID ARCHITECTURE │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ MCP Layer │ │ Skills Layer │ │
│ ├─────────────────┤ ├─────────────────┤ │
│ │ Sandboxed exec │ │ Workflow docs │ │
│ │ Validation │ │ Best practices │ │
│ │ State mgmt │ │ Domain knowledge│ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ └────────────┬───────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Claude Code │ │
│ │ Orchestration │ │
│ └─────────────────┘ │
│ │
│ MCP for: Execution, validation, state │
│ Skills for: Knowledge, workflows, practices │
│ │
└─────────────────────────────────────────────────────────┘
Key Principle: Use MCP for what it's good at (execution infrastructure), Skills for what they're good at (knowledge transfer).
Vallentin's March 2026 LinkedIn post extends the original "We Did MCP Wrong" thesis to a concrete situation that recurs across SaaS tools: the official MCP server is read-only, but the agent needs write access.
The worked example is Attio (a CRM). Attio's official MCP server lets an agent browse records but not create, update, or annotate them — a fundamental gap for a tool meant to let agents act. Rather than wait for the vendor to ship write endpoints, Vallentin built a CLI for the Attio API and paired it with a skill that teaches the agent when and how to invoke it.
| Step | Action | Tool |
|---|---|---|
| 1 | Take the published OpenAPI spec | Vendor docs |
| 2 | Generate a typed SDK | @hey-api/openapi-ts |
| 3 | Wire the SDK into a CLI | commander |
| 4 | Write a skill that documents when and how the agent should reach for the CLI | Markdown skill file |
Reference implementation: mavam/clattio — installable as npx skills add mavam/clattio, delivers complete read-write access to Attio without an MCP transport.
- The vendor's MCP server is missing write or admin operations you need.
- The vendor publishes a usable OpenAPI spec (the recipe is mechanical from there).
- The team is comfortable maintaining a thin CLI wrapper as a Unix-style binary (no transport layer, no server lifecycle).
- The skill that accompanies the CLI is what minimizes time-to-value for the agent — without it, the agent must discover the CLI by reading
--help.
Vallentin's framing isn't a one-off. By Q2 2026 multiple independent practitioners — and at least two database/data-tool vendors — had publicly described the same conclusion: for many integrations, a CLI shipped to the agent beats an MCP server, especially when the agent is already comfortable shelling out.
| Practitioner / vendor | Date | Source | What they shipped or argued |
|---|---|---|---|
| Matthias Vallentin (Tenzir) | 2026-03-17 | LinkedIn post + mavam/clattio |
OpenAPI → typed SDK → CLI → skill recipe for Attio |
| Hoyt Emerson | 2026-04-07 | LinkedIn post about Fletch CLI for ADBC data transfers | "A local CLI tool allows you to simply run commands and functions you normally would in the terminal, with the added support of using your agent to do this... if the CLI already handles auth locally... then why use an MCP server?" |
| Hex (referenced in Hoyt's post) | April 2026 | Product release | Shipped a CLI alongside their existing MCP server — same vendor offering both, with the CLI explicitly aimed at agent use |
| ClickHouse | 2026 | Futurum coverage | Built a CLI to make ClickHouse databases agent-native — vendor decision, not third-party wrapper |
| Jannik Reinhard | 2026-02-22 | Independent blog | Practitioner essay titled "Why CLI Tools Are Beating MCP for AI Agents" |
| OSS Insight | 2026-05 | "Agent-Native CLI Wave" | Trend piece: counts ≥6 major repos that launched in Q1 2026 with the premise "take existing software, give it a structured CLI for agents" |
Implication: The recipe and the underlying observation are not a Tenzir-specific commercial framing — they are reproducible enough that independent practitioners and at least two database/data-tool vendors arrive at the same conclusion. This strengthens the pattern claim (CLI + Skill works) without strengthening the categorical claim (MCP is bad). Multiple shops shipping the same pattern is evidence the pattern works; it is not evidence the alternative is wrong — note that Hex chose to ship both a CLI and an MCP server, treating them as complementary rather than as substitutes.
A second framing from Hoyt's same post — "agents should build their tools for themselves first" (agent self-tooling) — remains a single-practitioner observation with one emerging-tool data point (Browser Harness) and is not yet corroborated. Track separately.
Vallentin's company (Tenzir) builds agent-friendly data tooling, so the categorical claim that "MCP is a solution in search of a problem Unix solved decades ago" reflects commercial framing. Two parts deserve separate treatment:
| Claim | Status |
|---|---|
| "Attio's MCP server is read-only" | Verifiable observation about one vendor's implementation |
| "CLI + Skill > MCP for SaaS tools where OpenAPI exists" | Defensible pattern; reproducible recipe |
| "MCP is a solution in search of a problem" | Opinion — discount accordingly |
Import the recipe; don't import the categorical conclusion.
Need to give agent access to a SaaS tool?
│
├─ Vendor MCP exists AND covers the operations you need
│ → Use the vendor MCP (standard path)
│
├─ Vendor MCP exists but is read-only / incomplete
│ AND vendor publishes OpenAPI spec
│ → Build CLI + Skill (Vallentin recipe)
│
├─ No vendor MCP, no OpenAPI spec
│ → Either build MCP server (heavy) or wrap the SDK in a thin CLI + skill (light)
│
└─ Cross-vendor orchestration with stateful workflows
→ MCP server (state, transport, persistent connections justify the weight)
This pattern is complementary to the MCP-vs-Skills cost comparison above, not a replacement. The cost data ($10.27 vs $20.78) addresses workflows where both options exist; the CLI+Skill recipe addresses the case where the vendor MCP doesn't expose what you need at all.
Before optimizing, understand current usage:
## Tool Call Audit Questions
1. How many tool calls per typical task?
2. What percentage are custom MCP tools vs native tools?
3. Are custom tools doing things Claude could do natively?
4. What's the token cost breakdown (input vs output)?Move domain knowledge from MCP tool implementations to skill documentation:
| Before (MCP) | After (Skills) |
|---|---|
docs_read tool with embedded docs |
Skill with documentation links |
run_test with hardcoded patterns |
Skill explaining test conventions |
validate_syntax tool |
Skill with syntax guidelines |
Keep MCP for things that truly need custom execution:
- Sandboxed code execution
- External API integrations requiring authentication
- Stateful operations across requests
- Operations Claude genuinely cannot do natively
Track cost per task type and adjust:
## Cost Tracking Template
| Task Type | MCP Cost | Skills Cost | Approach Used |
|-----------|----------|-------------|---------------|
| TQL dev | $20.78 | $10.27 | Skills ✓ |
| Code review | $X | $Y | ? |
| Deploy | $X | N/A | MCP (required)|Problem: Routing all operations through MCP "because we built it" Symptom: 2x cost, maintenance burden, slower iteration Solution: Evaluate each workflow—many don't need custom tools
Problem: Dumping raw documentation into skills without organization Symptom: Claude overwhelmed, inconsistent results Solution: Structure skills with clear sections, examples, when-to-use guidance
Problem: Using same approach for local and cloud deployments Symptom: Either over-engineering (cloud) or under-supporting (local) Solution: Match tool richness to model capability and environment constraints
Problem: Not measuring actual costs per approach Symptom: Surprised by API bills, no optimization data Solution: Instrument and track cost per task type
If you have existing MCP infrastructure and want to reduce costs:
List all MCP tools and categorize:
- Execution tools: Actually run code, make API calls → Keep in MCP
- Knowledge tools: Return documentation, explain patterns → Migrate to Skills
- Validation tools: Check syntax, formats → Evaluate case-by-case
For each knowledge tool:
- Extract the documentation/knowledge it provides
- Create a skill with that knowledge as context
- Add usage examples and when-to-use guidance
Run identical tasks through both approaches:
- Measure cost
- Measure quality
- Measure duration
- Decide per-workflow
Don't rip out MCP overnight:
- Start with lowest-risk workflows
- Monitor for quality regressions
- Expand as confidence grows
| Pattern | Integration |
|---|---|
| Progressive Disclosure | Skills load only relevant context (token efficiency) |
| GSD Orchestration | Skills for knowledge, MCP for execution validation |
| Context Engineering | Skills = deterministic context, MCP = tool context |
| MCP Patterns | This pattern complements MCP security/architecture guidance |
| Factor | MCP | Skills |
|---|---|---|
| Speed | ✅ Faster (38%) | Slower |
| Cost | Expensive (2x) | ✅ Cheaper (50%) |
| Infrastructure | Requires servers | ✅ Just markdown |
| Portability | Project-specific | ✅ Cross-project |
| Maintenance | High | ✅ Low |
| Capability | ✅ Execution + Knowledge | Knowledge only |
Rule of Thumb: Default to Skills for knowledge transfer; reserve MCP for execution that Claude genuinely cannot do natively.
- MCP Patterns - MCP security and architecture patterns
- Progressive Disclosure - Token-efficient skill loading
- Skills Domain Knowledge - Embedding expertise in skills
- Context Engineering - Managing context effectively
Primary (Tier B):
- Tenzir Blog - "We Did MCP Wrong" - Matthias Vallentin, January 2026 — Cost economics (50% cheaper, 38% slower, 55% less cached tokens).
- Matthias Vallentin LinkedIn — "CLI + Skill > MCP" — March 17, 2026. Four-step CLI-ification recipe (
OpenAPI → @hey-api/openapi-ts → commander → skill); reference implementationmavam/clattio. Vendor-incentive caveat: Tenzir builds agent-friendly data tooling, so the categorical "MCP is a solution in search of a problem" framing aligns with commercial interest; the four-step recipe and the Attio-MCP-is-read-only observation are reproducible.
Supporting:
- Tenzir Claude Marketplace plugins (10+ production plugins)
- Internal cost analysis across workflows
Last updated: 2026-05-24
analysis/behavioral-insights.md[EXTRACTED (1.00)] — referencesAUDIT-CONTEXT.md[EXTRACTED (1.00)] — referencesINDEX.md[EXTRACTED (1.00)] — references