The Hex vs. The Stack: Why This Isn't Just Another Tool List
You've heard someone describe their "tech stack" at least fifty times. At a networking event, on a podcast, in a Twitter bio. "My stack is Claude, Notion, Zapier, Midjourney, Ghost, and Loom." They list the tools like trading cards — each one a signal of how modern and capable they are. The list sounds impressive. It tells you nothing about whether any of those tools talk to each other, whether any of them run without the person manually switching between tabs, or whether the person has produced a single thing this month that required more than two of them working together. That's a stack. A hex is something different.
A Stack Is a List. A Hex Is a Circuit.
The distinction is connection, not collection. A tech stack is a set of tools that happen to be on the same credit card. You use Notion for notes. You use Zapier for automations. You use Claude for drafting. You use Midjourney for images. They sit in separate browser tabs, they don't know about each other, and the only integration layer between them is you — copying text from Claude, pasting it into Notion, downloading an image from Midjourney, uploading it to Ghost, checking Zapier to make sure the automation ran. You are the middleware.
A hex is a circuit. The tools are connected through MCP, orchestrated by Claude, and designed to operate as a system. When you tell Claude to "draft the article, generate a featured image, and publish it to Ghost," Claude doesn't hand you three separate outputs to manually assemble. It does all three, in sequence, using the MCP connections you've wired up. The information flows through the circuit. You're not the middleware — you're the operator.
This sounds like a semantic distinction. It's not. The practical difference between a stack and a hex is the difference between doing work and managing tools. In a stack, a significant portion of your time is spent bridging the gaps — the copy-paste, the tab-switching, the "let me download this and upload it there." In a hex, that bridging is handled by the infrastructure. Your time goes to deciding what needs to happen, not making it happen across seven different interfaces.
The Stack Mentality
The stack mentality is: "I use these tools." It's a statement of possession. You have a Claude subscription. You have a Notion workspace. You have a Zapier account. Each tool is evaluated independently — is this a good notes app? Is this a good automation platform? — and collected based on individual capability. The question is always "what's the best tool for X?" and the answer is always another item on the list.
The stack mentality produces a specific behavior pattern. You spend a lot of time evaluating tools. You read comparison articles. You watch demo videos. You try free tiers. You migrate from one notes app to another because the new one has a feature the old one doesn't. Your tool list changes every six months, but your output doesn't change at all — because the output was never limited by the tools. It was limited by the gap between the tools. And the stack mentality doesn't address gaps. It addresses individual tools.
The most telling sign of stack mentality is the answer to "show me your workflow." Stack users describe their tools. "I use Claude for drafting, Notion for organizing, Zapier for automating." Hex users describe their process. "Claude reads my content calendar, drafts the next article, generates the image, and publishes it to Ghost. I review the draft and approve the publish." One is a list of nouns. The other is a sequence of verbs. The verbs are where the value lives.
The Hex Mentality
The hex mentality is: "Claude orchestrates my email, calendar, files, and publishing through MCP." It's a statement of connection. The focus isn't on individual tools — it's on what happens between them. The evaluation question shifts from "is this a good tool?" to "does this tool connect to my hex?" A tool that's 20% better in isolation but doesn't connect via MCP is less useful than a tool that's adequate and wired in.
This evaluation shift is counterintuitive for people coming from the stack mentality. It feels wrong to choose a slightly worse tool because it has better MCP integration. But the math bears it out. A tool that's 80% as capable but fully integrated into your hex saves more time than a tool that's 100% capable but requires manual bridging for every interaction. The integration eliminates entire categories of work — the tab-switching, the format conversion, the copy-paste loops — that the marginally better standalone tool doesn't touch.
The hex mentality also changes how you think about new tools. In a stack, every new launch is a potential addition. "Should I add this?" In a hex, every new launch is a potential swap. "Is this better than what's currently in slot three?" The question is constrained, the evaluation is comparative (not open-ended), and the default is to keep what you have. New tools have to earn their way in by being meaningfully better than what they'd replace. Most don't. The result is stability, and stability produces fluency, and fluency produces output.
The Integration Test
Here's a concrete way to tell whether a tool is in your hex or just in your stack. Ask one question: "Can Claude use this tool without me copy-pasting between tabs?"
If the answer is yes — Claude can access the tool through MCP, read its data, write to it, and perform actions within it — the tool is in the hex. It's part of the circuit. Information flows through it automatically.
If the answer is no — you have to manually export from one place, paste into another, download and re-upload, or switch between interfaces — the tool is in the stack. It's on the list, but it's not in the system. You're still the middleware.
Some tools genuinely don't need MCP integration to be useful. A design tool you open once a week for a specific task doesn't need to be wired into your hex. A reference app you check occasionally is fine as a standalone. The integration test isn't "every tool must connect." It's "the tools you use daily for your core workflow should connect." The daily-use tools are your hex. Everything else is periphery.
Run this test on your current tools. You might find that your "essential" tools include three that Claude can access natively and four that require manual bridging. That tells you something about your actual hex versus your perceived stack. The three connected tools are your hex. The four manual tools are candidates for either MCP-connected alternatives or deliberate acceptance that they'll live outside the system.
What Happens When You Upgrade
The transition from stack to hex — from a collection of independent tools to a connected system — produces a specific set of changes in how you work.
Less tab-switching. This is the most immediate, most tangible difference. When Claude can access your email, calendar, and files directly, you stop bouncing between Gmail, Google Calendar, and Finder. You stay in one interface and let Claude reach into the others. The cognitive cost of context-switching — loading a new interface, finding what you need, switching back — drops to near zero for tasks the hex handles.
Less copy-pasting. The universal tax of the stack mentality. You draft in Claude, copy to Ghost. You download from Midjourney, upload to Ghost. You export from Notion, paste into an email. Every copy-paste is a seam in your workflow where errors can enter, formatting can break, and time leaks out. In a hex, the information moves through MCP connections. Claude drafts the content and publishes it. No intermediate clipboard.
More "Claude, handle this." The biggest shift is what you start delegating. In a stack, you delegate individual tasks to individual tools — "Claude, draft this" or "Zapier, run this trigger." In a hex, you delegate workflows. "Check today's calendar, draft a summary email of my meetings, and send it to my assistant." That's three tools, one instruction. The hex turns multi-step, multi-tool processes into single requests. The complexity is handled by the connections, not by you.
More output. This is the bottom line. Connected tools produce more output than disconnected tools because the friction between steps is lower. Every reduction in friction — one less tab to switch, one less copy-paste, one less manual handoff — translates into more iterations, faster completion, and higher throughput. The tools haven't gotten better. The work flowing through them has gotten smoother.
The MCP Advantage
Here's why this argument is specific to 2026 and wasn't possible two years ago. Before MCP, the idea of "connect your tools into a system" meant: use Zapier, learn APIs, write custom code, or accept that your tools don't talk to each other. Constraint-based frameworks existed — the hex concept isn't new — but the infrastructure to make them real was fragile, expensive, or developer-only.
MCP changes that equation. The protocol is open. The connectors are community-built and growing. The architecture runs locally, which means it's reliable and private. And it's maintained by Anthropic, which means it improves alongside the model that uses it. For the first time, a non-developer can connect their core tools into a system that an AI can orchestrate — without writing code, without paying for middleware, without depending on third-party services that might shut down next quarter.
The hex framework is built on MCP because MCP is the first infrastructure that makes the hex viable for normal people. Not developers. Not automation engineers. The person who uses Gmail, Google Calendar, and a publishing platform — and wants those tools to work together without becoming a systems administrator. MCP is the plumbing. The hex is the blueprint. Together they produce something that neither a tool list nor a willpower-based constraint can produce alone: a system that actually runs.
This is part of CustomClanker's Hex Explained series — you downloaded the hex, here's context.