“Most people are using MCP wrong,” said MCP’s co-creator, David Soria Parra.

I agree. Because I made the same mistake.

Engineers would do the obvious thing: wrap each REST endpoint as an MCP tool and shove them into a custom registry.

The result? Zero value over just calling the APIs directly.

Worse than zero, honestly. We added latency, an extra hop, and now had a registry to maintain. The agent didn’t behave any smarter. It just had a fancier way to call /v1/customers.

So I wrote MCP off completely. Filed it under “hype cycle, will pass.”

Then David took the stage at @aiDotEngineer and reframed the whole thing.

MCP isn’t dead because of Skills or CLIs. We were just using it wrong.

His mental model: the best agents work across 4 layers.

• User interfaces: chat UI, IDE, internal tools, Slack
• Agent harness: runs the LLM, decides when to use tools
• Connectivity: Skills, MCP, CLI
• Backends: APIs, databases, internal systems, file systems

The connectivity layer has 3 legs. Each is good at a different thing.

1. Skills (domain knowledge)

A skill is just a markdown file, or a small set of files, that teaches the model how to think about a problem. How your team writes SQL. Your incident response playbook. The shape of your warehouse schema. The naming conventions in your codebase.

They’re:

• Reusable across agents
• Lightweight (no servers, no auth, no infra)
• Easy to update (it’s a git commit)

Skills are the cheapest way to make an agent feel like it knows your business.

2. CLI / computer use (cheap local execution)

If your agent is writing code, you don’t need MCP for git, grep, ripgrep, pytest, npm. The model already knows how to use these tools. Give it a sandbox and let it run commands.

CLI wins on:

• Latency (no network round trip per tool call)
• Token cost (one bash command beats five typed tool calls)
• Composability (pipes, scripts, your existing tooling)

This is why coding agents have largely converged on shell access plus a sandbox. There’s no schema to maintain because the OS already has one.

3. MCP (rich semantics)

MCP earns its keep where the other two don’t. Specifically:

• Typed tools with strict schemas
• Resources (read-only data the agent can pull on demand)
• Long-running tasks (ETL jobs, deploys, migrations)
• Auth, scoping, audit trails
• Governance (who can call what, when, with what limits)
• Platform independence (one server, many clients)

The boring enterprise stuff. The stuff that actually matters once you’re past a demo.

So where did engineers go wrong?

The mistake wasn’t using MCP. It was treating MCP like a REST wrapper.

If your MCP tool is get_customer(id) and underneath it’s just GET /api/customers/{id}, you’ve built an expensive proxy. The model gains nothing it didn’t have from a plain HTTP call. You’ve moved the same problem to a new place and added a server to babysit.

MCP servers should be products.

Design them the way you’d design an internal app for a teammate. Start from user journeys, not endpoints.

Wrong question: “What FHIR resources does our EHR expose?” Right question: “What does finance need to close the books, and what does clinical ops need from the chart each day?”

The answers look like:

• Reconcile last month’s failed treasury payments against the general ledger
• Produce the CFO pack with consolidated books and variance commentary
• Approve a prior authorization for a high-cost procedure with the right policy checks
• Investigate why claim denials spiked for a given payer this quarter

Each of those is one tool from the agent’s perspective. Underneath, it’s orchestrating 5 to 15 API calls, applying business logic, handling edge cases, and writing to an audit log. The MCP server owns the domain. The agent doesn’t have to.

This also fixes the context problem. If you expose 80 tools as one-to-one wrappers, the model spends most of its budget figuring out which one to call. Five well-designed tools that map to actual workflows are cheaper to reason about and easier to evaluate.

Design around domains, not vendors:

• finance-mcp (owns billing, AR, payment processors, and the GL)
• healthcare-mcp (owns EHR read/write, claims, eligibility, and prior auth workflows)

Use resources for the read-heavy stuff: the patient roster, the payer remittance file, and the management reporting pack configuration. Use tasks for the long-running stuff: the reconciliation, the month-end close, the claims backfill. Stop thinking in CRUD.

This is how you actually build production agents.