You wire up a new tool and you want Claude to work with it. Analytics, error monitoring, your deploy pipeline. So you go looking for an MCP server, or you find one and spend an afternoon running it, authenticating it, keeping it alive. And when there isn't one, you fall back to what you were doing before: clicking around the dashboard, rebuilding the same funnel from memory every time you want to check it.
Both of those are more work than the job needs.
Here's what I keep coming back to instead. Most of the time, integrating a tool with Claude is three steps, and none of them is a server. Prepare a script. Wrap it as a skill. Then get out of the way and let the signals combine.
And you hand-write none of it. You describe what you want, Claude drafts the script and the skill, you review and accept. The judgement is yours; the typing is its.
The script is boring on purpose
Step one is a single CLI call, or a few lines that hit the tool's API. PostHog has a query endpoint. Sentry has a CLI. Vercel and Turso ship their own. Nobody is building anything clever, and you are barely building at all: you ask, Claude writes it. One correct answer out of one tool, in your terminal, as plain text.
This is the part people overthink. They reach for an integration layer when a curl and a bit of JSON parsing would do. The script is meant to be boring. Boring is what makes the next step cheap.
The skill is the actual move
Step two is where it stops being a one-off. That script becomes a named Claude Code skill. /onboarding-funnel. /last-errors. /deploy.
Now the question is text. It lives in your repo, it diffs in git, and it reruns identically next month when you've forgotten how it worked. The tricky part of any real query, which events to join, which flag to pass, which grouping avoids the bug, gets solved once and given a name. You don't rederive it every time you're curious. You just call it by name.
A dashboard is state you maintain by hand. A skill is a version-controlled question. That difference sounds small until you have twenty of them.
And that's the whole point
Because step three isn't a step you do. It's what happens once two skills exist.
One tool tells you what. Two tools tell you why. PostHog says users dropped at onboarding step three. On its own, that's a shrug. Sentry says a component threw there, on Safari only. The deploy log says it shipped an hour before the drop started. You don't have three dashboards any more. You have a diagnosis, and the skill that reads it sits next to the skill that fixes it: open the PR, run the migration, roll back the deploy, without leaving the terminal.
This is the half of Claude Code nobody demos. It's sold as an agentic coding tool, and it's a good one, but writing the code was never the scarce part. The hours go into holding your tools' signals and actions in one place and asking the question, or issuing the command, that spans them. Skills get each one to the table cheaply. Claude is what joins them.
When you actually want the MCP
I'm not against MCP. It exists for good reasons. If you're shipping an integration other people will use, if it needs live two-way state, if the people on the other end aren't running Claude Code against their own repo, then a standard protocol with real discoverability beats a folder of your personal one-liners.
But that's a product decision. Wiring your own tools to your own terminal is not that. For the read-mostly, ask-it-when-I-need-it questions a solo builder actually has, a script and a skill are lighter, they're yours, and they don't rot in a running process you forgot you were paying for.
There's one honest catch. Scripts lean on CLIs and APIs, and schemas move. A query that silently drifts out of date is worse than a clunky dashboard, because it looks like it's still working. So the skills need the occasional check. That's the tax for owning the thing outright.
The series
This is the pattern. The rest of the series walks it one tool at a time, with the real scripts and the real skills, from reading signals to driving actions.
Same loop every time. A script, a skill, and something you can act on.
The tools are just where the signals come from. The value shows up where they meet.
