Introduction
Every month, someone on our team was doing the same thing: pulling data from a handful of systems, assembling it into a document, and writing up a summary before it could go to the client. The work was not complicated. It was just slow, repetitive, and easy to get wrong.
That monthly report was not an isolated case. We’ve built a few internal tools around the same pattern: a repetitive workflow, data sitting in one or more external systems, and a human who needs to stay in the loop at the right moments. Each time we reach for a solution, we face the same question: how much infrastructure does this actually need?
In this post, we will look at the characteristics of a workflow that fit this lightweight approach (a Claude Code skill paired with an MCP server), how you divide the work between the two pieces, when you would reach for something heavier instead, and how we applied the pattern to cut that monthly report’s production time to less than half of what it used to take.
When this pattern fits
There are plenty of ways to automate a repetitive workflow, and each comes with a different cost. A Claude Code skill paired with an MCP server is a low-infrastructure option, which means it fits some problems well and others poorly. In our experience, it is a good fit when three things are true about the workflow.
The first is that the workflow is well-defined, bounded, and repetitive. There is a clear starting point, a predictable sequence of steps, and an expected output. That does not mean it is simple in content (the monthly report we will describe later involves synthesizing data across three external systems), but the shape of the process does not change from one run to the next. If the steps are not clear enough to document before you build, the automation will inherit that ambiguity rather than resolve it.
The second is that the data sources are known and bounded upfront. Before you write a line of code, you can name every system the workflow needs to read from and what it needs from each one. The MCP server connects to those sources, nothing more. This is different from workflows where the data discovery is itself part of the work (where the right sources depend on runtime conditions, or the scope shifts from one run to the next). When you do not know what you are reading until you are already running, the MCP server’s role becomes harder to define and the pattern starts to strain.
The third is that user input along the way is acceptable, and often welcome. The skill walks Claude through a structured process with the person running it, collecting context and surfacing decisions at key moments. This is a feature, not a constraint: it keeps a human in the loop without requiring a custom interface to manage that interaction. If the workflow needs to run fully autonomously, triggered by an event with no one present, a skill is the wrong tool.
What the skill and MCP server each do
It helps to be clear about what each piece does, because the pattern only works when both are present and the responsibilities stay separate.
The skill is the workflow intelligence. It is a set of instructions that tells Claude what to do, in what order, and what to ask the person running it along the way. It holds the domain knowledge about the process: which steps come first, what context to collect, when to pause for input, and what the finished output should look like. On its own, a skill is just a well-structured prompt with no direct connection to your data.
The MCP server is the data layer. It exposes a defined set of tools and resources: specific queries, specific API calls, scoped reads from specific systems, and nothing else. We build these servers as read-only by design: each one connects only to the systems the workflow requires, with credentials scoped to exactly what it needs. There is no general-purpose database access, no ability to modify records, and no reach beyond what was deliberately wired up. For workflows that touch client data, this matters. The person running the skill gets exactly the data the process requires, and nothing more.
Neither piece works well without the other for these kinds of workflows. A skill with no MCP server has to rely on whatever context the user provides manually, which means the repetitive data-fetching work stays manual. An MCP server with no skill gives Claude access to data but no guidance on what to do with it, which produces inconsistent results and a lot of back-and-forth. The pairing is what makes the workflow repeatable: the skill provides the structure, the MCP server provides the grounding.
We have written before about how to write a Claude Code skill if you want to go deeper on the mechanics of the skill side, and about building a blog MCP server with FastMCP and pgvector for a closer look at what goes into the data layer.
Skill + MCP vs. a custom agent
When people recognize a workflow that could benefit from AI, the instinct is often to reach for a custom agent. Agents are flexible, can handle complex tasks, and can call tools and access external data. They would work here. But a custom agent needs a place to live, an interface for users to interact with it, user management, an orchestration layer to coordinate its steps, and ongoing maintenance as the workflow evolves. For a problem that fits the three characteristics above, that is more than the problem requires.
A skill and MCP server sidestep most of that infrastructure. There is no custom interface to build because Claude is already the interface, and no user management because access to the plugin is access to the tool. There is no orchestration layer because the skill’s instructions are the orchestration. Amanda Bizzinotto described this tradeoff well in AI Assistant for Our Blog Writing Process : the entire thing (MCP server, data pipeline, and skills) took about ten hours to put together, specifically because of everything she left out.
That said, the “lighter” option has real limits. We built a different kind of automation for our quarterly maintenance reports at FastRuby.io, described in Automating Quarterly Reports with AI . That system uses a Python pipeline with explicit curator and reviewer components: structured prompts, JSON outputs, and a sequence of LLM calls that runs without a human watching. It is more complex to build and maintain, and it should be. The problem it solves involves a richer review process and no expectation of human input mid-run.
The decision comes back to the three characteristics. If the workflow is well-defined and repetitive, the data sources are known upfront, and a human in the loop is acceptable, a skill and MCP server will likely be cheaper to build, easier to maintain, and good enough for the job. If any of those conditions do not hold (the workflow branches in ways that are hard to anticipate, data discovery is part of the work itself, or it needs to run autonomously at scale), reach for something “heavier”.
Automating a monthly report
The example we described at the start of this post checks all three boxes. The report covers LLM usage, error rates, and product funnel metrics for a client. It comes out monthly. The data lives in three systems, all of which were known before we started building. And someone always needs to be in the loop to provide context and sign off on the narrative before it goes anywhere.
Before the automation, producing the report meant querying each system manually, stitching the results together in a document, and writing the narrative by hand. Each step introduced its own delay and its own chance for something to go wrong: a query run against the wrong date range, a metric copied from an older export, numbers that did not add up because they came from different points in time.
The MCP server connects to all three sources: Phoenix for LLM trace spans, Sentry for error events, and the client’s own product database for funnel metrics. Phoenix is the observability platform we use to instrument AI-powered applications (for background on why tracing matters for LLM systems, see Why do LLM Applications Need Tracing? ). Spans are fetched day-by-day with concurrency and cached locally, so historical days are never re-fetched on subsequent runs, and only new data comes in. Credentials for the product database are scoped to exactly the tables the report needs. Access is read-only, and nothing is written back.
With the data layer handled, the skill takes over. It is a prompt, not code, that tells Claude which tools to call and in what order. The sequence covers the full lifecycle of the report: gathering data for the period, walking through an interview with the person present to capture context, drafting the narrative, and producing and storing the finished output. The skill also encodes the edge cases: what to do when a number is missing, how to handle a first-month baseline with no prior period to compare against, how to present maintenance work that does not produce visible output metrics. Tone and style come from a separate voice.md file the skill references, so the writing guidelines live in one place and can be updated without touching the workflow. Being able to list those edge cases upfront was a good sign the workflow was ready to automate.
The result is a report that used to take the better part of a working morning and now takes less than half that time, with less mental load and more consistent results.
Conclusion
A Claude Code skill and MCP server will not solve every automation problem, and it is worth being honest about that. When the workflow is a good fit, it is a low-cost way to take that repetitive work off people’s hands, without building infrastructure you will later have to maintain.
The monthly report was a good fit because we could describe every step, name every data source, and anticipate the edge cases before writing a line of code. The skill captures that knowledge and applies it consistently. The MCP server makes the data available in a controlled, read-only way. Neither piece is especially clever on its own. Together they make the workflow repeatable in a way that manual execution never quite was.
If you are looking at a workflow in your own team and wondering whether this pattern fits, the three questions to ask are: Can I describe every step before I start building? Do I know exactly where the data comes from? Is a human in the loop acceptable? If the answer to all three is yes, you probably do not need anything more than a skill and an MCP server. If you are still earlier in the process, working out which workflows in your business are worth automating at all, Finding the Right Problems to Solve with AI is a good place to start.
Got a repetitive workflow that seems like a good fit? Let’s talk.