This will sound extreme. I am fine with that. My current rule for evaluating a new tool is simple: if I cannot connect it to Claude Sonnet via MCP, webhook, or a well-documented API, I probably will not use it in my stack. Not because I am precious about automation for its own sake, but because the real productivity in an AI-augmented workflow comes from the connections, and anything that lives in a silo creates a tax that compounds across every project.
This post explains the logic behind that rule, what it costs me in terms of specific tools I have passed on, and why I think it applies more broadly than just my own setup.
The actual productivity gain is in the seams, not the features
Every major productivity tool now markets some version of AI. Most of it is local: a drafting assistant, a smart search bar, an auto-formatter. Useful, but not what moves the needle. The real gain in an AI-augmented workflow is being able to hand a decision or a task across multiple systems without manually bridging them. That only happens when the systems can talk to each other, and they can only talk to each other if they expose a real interface.
Claude is my working environment for reasoning, drafting, strategy, and the kind of work that requires judgment. Everything it can reach via MCP or API is, in practice, part of that environment. Everything it cannot reach is outside it. When I am in flow on a deliverable and need to pull data from a tool that has no interface, I break the session to go get it manually. That break is not free.
What the rule costs me
There are tools I like in isolation that I have moved away from because they sit behind closed walls. Specific examples:
- Proprietary analytics dashboards with no export or API. If I cannot query the data programmatically, the insight lives in the tool and does not travel. I have replaced several of these with solutions that can surface data via API even if the UI is less polished.
- "AI-native" project management tools that lock the data model. If Claude cannot read or write tasks on behalf of a workflow, the tool is a destination, not a participant. I have found that most serious project management needs either use open APIs or allow webhook integrations that are good enough.
- Scheduling and intake forms that cannot pass structured data downstream. If a booking confirmation arrives as an unstructured email with no hook, connecting it to anything else requires manual work or brittle parsing.
In each case, the tool was genuinely good at its primary job. The problem was not the feature set - it was the interface layer.
The MCP factor, specifically
Model Context Protocol is what makes tool connections feel native rather than bolted on. When a tool has an MCP server, Claude can interact with it the same way a human would through the UI, but programmatically and at the speed of thought. The list of tools with real MCP support is still limited, but it is growing fast, and the difference in workflow between a connected tool and an unconnected one is large enough that I now treat connectivity as a first-order criterion rather than a nice-to-have.
The practical effect: when I evaluate a new tool, the first question I ask is not "what does it do" but "how does it expose what it does." A great feature that lives behind a closed interface is a feature I will use less, recommend less, and eventually replace.
Where this gets complicated
There are real tradeoffs. Some of the best purpose-built tools for specific jobs have weak or nonexistent APIs, and some of the most interoperable tools are mediocre at their core function. I do not always choose interoperability over capability. But when two tools are roughly equivalent in what they do, the one that connects wins every time, and I increasingly find myself putting the integration question first rather than second.
There is also a cost to being an early adopter of MCP and API-first tooling: less polish, more setup, occasional breakage. I accept that cost because the compounding return on a well-connected stack is larger than the upfront friction. This is a considered tradeoff, not a casual one.
What this means for clients
When I audit a client's marketing stack, one of the first things I look for is the silo count: how many tools hold data or run processes that cannot be reached programmatically. Every silo is a place where manual work accumulates, where reporting requires a human bridge, and where AI augmentation hits a wall. Reducing silo count is often more valuable than adding a new capability, and the audit almost always finds tools that could be replaced with something equally capable and significantly more connectable.
The rule is simple and the logic behind it is not complicated. Connect to Claude or get replaced by something that does.
If you want a fast read on how connected your current stack actually is, the marketing audit will surface it in the first pass.
