Stop Picking a Winner: Skills, MCP, and Agents Are a Stack

TL;DR

MCP is how the model reaches your warehouse and tools. Skills are the playbook: how your team does EDA, QA, and reporting. The agent is the worker that uses both. Data teams do not pick a winner. They stack access, playbook, and worker. Without the first two, an "agent" is a chatbot with a longer job description.

---

In workshops I keep hearing the same fork: "Should we invest in MCP, in skills, or in agents?" That question is how you end up with a shiny connector, a folder of prompts nobody runs, or a chatbot that invents revenue.

The useful framing is the one I already teach: Access + Context + Instructions. MCP is access. Skills are how you encode instructions (and a lot of context) so the work is repeatable. The agent is the thing that actually does the job. Stack them or you are paying for theater.

The Problem: "MCP vs Skills vs Agents" Is the Wrong Fight

MCP without a playbook is a model that can touch tables and still join the wrong grain. A skills repo without access is a PDF of good intentions. An agent without either is ChatGPT in a trench coat.

I have watched teams enable a warehouse MCP, ask "what is NRR," and ship a number finance will not sign. The protocol worked. The job failed. Reach is not judgment.

The other failure mode is collecting "agent skills" like trading cards. A skill that says "do EDA" does nothing if the model cannot see your warehouse and does not know that finance excludes trials. You have a playbook with no field and no roster.

The Solution: Stack Access, Playbook, and Worker

Treat the three as layers, not vendors to bake-off.

1. MCP = Access

MCP (Model Context Protocol) is the path to the work: warehouse, git, docs, BI, ticketing. It is how you stop dumping CSVs into a prompt.

• Goal: The model can reach the systems a senior analyst would open, with the same boundaries
• Action: Wire MCP servers to the warehouse and the repos that hold definitions — not a one-off schema paste
• Outcome: Query and retrieve work. The model still does not know which table is allowed to answer "revenue"

Access without the other two is a security and quality problem.

2. Skills = Playbook

Skills are how you want the work done: investigation order, QA checks, "never use this table for that question," output format, when to stop and ask a human. In Cursor they look like reusable skills. In delivery they look like a versioned playbook.

I keep a public starting point at data-analytics-skills — the same repo on this site as Data Analytics Skills. That is not "the agent." It is the playbook an agent can follow once it has access and context.

• Goal: EDA, QA, and reporting run in the order your team already trusts
• Action: Version skills like code. Point them at your definitions, not a generic "analyze the data" prompt
• Outcome: The worker stops improvising your close process

3. Agent = Worker

The agent is the production worker that uses access and the playbook. It pulls from the warehouse, follows metric rules, and hands back something a stakeholder can use. It is not a tools-directory listing and it is not a 40-message chat.

If you want the longer version of that distinction, read Data Agents for Analytics Teams. The short version: would you let this thing run a weekly sanity check with the same rules you would give a new analyst? If not, you still have a chatbot.

• Goal: Bounded analytics work that matches how the business already measures things
• Action: Point the agent at MCP paths and skills. Add a human check before a number hits a dashboard
• Outcome: SQL access stops being mistaken for a trustworthy metric

How to Put Them Together

1. Give the model a path (MCP) — warehouse and git, governed, not a paste.
2. Give it a playbook (skills) — EDA, QA, reporting, as you actually do them. Start from data-analytics-skills and make it yours.
3. Put a worker on that stack (agent) — one boring first job: SQL QA, a weekly pipeline brief, or EDA that already knows the schema.
4. Keep a human on the number — context plus instructions plus a check. Access alone will invent a metric.

Skip a layer and you will pick a "winner" that does not hold up in production. Stack them and the argument goes away.

---

Explore the Agentic Workflow Workshops or the variety of Service packages.