The Integration Test: Do Your Remaining Tools Actually Work Together
You've audited your tools and eliminated the dead weight. You're down to six. The temptation now is to declare victory and move on. Don't. Having six tools is not the same as having a hex. A hex is six tools that work together as a system. Six tools that sit in separate browser tabs, producing output you manually copy and paste between them, is just a smaller collection. The integration test is how you find out which one you have.
The distinction matters because the value of the hex is not in the number — it's in the connections. A tool that connects to your other tools through MCP or an API is a multiplier. A tool that produces output you have to manually transfer is a bottleneck wearing a capability costume. The integration test exposes which of your six tools are multipliers and which are bottlenecks, and gives you the information you need to fix it or make a swap.
What Integration Actually Means
Integration, in the context of a hex, means one thing: can Claude use this tool without you switching tabs? That's the test. If Claude can access a tool through an MCP connector, that tool is integrated. If you have to open the tool in a separate window, do something manually, copy the result, and paste it back into your Claude session, that tool is not integrated — it's adjacent. Adjacent tools work. They just work slowly, with friction, and at the cost of your attention.
The practical difference looks like this. An integrated email tool means you say "draft a response to the last email from Sarah about the proposal" and Claude reads the email, drafts the response, and stages it for sending — all within the conversation. An adjacent email tool means you open Gmail in another tab, read the email yourself, copy the relevant parts, paste them into Claude, get a draft, copy the draft, go back to Gmail, and paste it in. Both produce the same output. One takes thirty seconds. The other takes three minutes and pulls your focus across four context switches.
At scale, across a full workday, the difference between an integrated hex and an adjacent collection is hours. Not theoretical hours — actual hours of context-switching, tab-switching, and copy-pasting that disappear when the tools talk to each other directly.
How to Run the Integration Test
The test takes about an hour and works like this. For each tool in your hex, attempt one real task that requires Claude to use that tool directly. Not a test prompt. Not "can you access my calendar." A real task you actually need done.
For your email tool: "Read the three most recent emails from [client name] and draft a summary of open action items." If Claude can read the emails through MCP, the tool passes. If you have to paste the emails in, it fails.
For your publishing tool: "Create a draft post with the title [X] and put it in my CMS." If Claude can create the draft directly in Ghost or WordPress or wherever you publish, it passes. If you have to export markdown and manually upload it, it fails.
For your knowledge tool: "Find the notes I took last week about [project] and pull out the three key decisions." If Claude can search your files or notes directly, it passes. If you have to go find the notes yourself and paste them in, it fails.
For your automation tool: "Check whether the [workflow name] ran successfully this week." If Claude can query your automation platform's status, it passes. If you have to open n8n and check manually, it fails.
Run this for all six tools. Score each one: pass (Claude can use it directly), partial (Claude can use it but with limitations — read-only when you need read-write, for example), or fail (requires manual intervention). Record the scores.
Reading the Results
If all six tools pass, your hex is integrated. This is the goal state. Claude can orchestrate your entire workflow without you leaving the conversation. You're done with the integration test and can move on to the 30-day trial.
If four or five pass with one or two partials, your hex is functional. The partials represent friction points — places where you'll occasionally need to do something manually — but the core workflow runs through Claude. Worth noting the partials and revisiting them quarterly to see if MCP support has improved.
If three or fewer pass, you don't have a hex yet. You have a tool list. The tools that failed the integration test need to be either replaced with alternatives that have MCP support or connected through a workaround — usually an automation tool that bridges the gap. This is where the hex gets real: you might need to swap a tool you love for a tool that's slightly worse at its core function but actually connects to everything else.
The Connection Beats Capability Principle
Here is the hardest lesson of the integration test, and the one most people resist: a worse tool that connects is more valuable than a better tool that doesn't.
The example I use most often is image generation. Midjourney, as of March 2026, produces arguably the best AI images for most use cases. It also has no MCP connector. You interact with it through Discord, of all things, or through a web interface that doesn't connect to anything. Using Midjourney in a hex means generating images in one place and manually downloading and uploading them in another. It's a great tool that's a terrible hex member.
DALL-E through GPT Image — or whatever image generation tool has an API and MCP support at the time you're reading this — might produce images that are 85% as good. But if Claude can generate, retrieve, and place those images directly into your publishing workflow through connected tools, the 85% tool produces more usable output than the 100% tool that requires manual handling. Connection beats capability because capability without connection creates manual steps, and manual steps are where workflows die.
This principle applies across every tool category. The best automation platform is the one that connects to your LLM and your other tools, not the one with the most features. The best note-taking system is the one Claude can search directly, not the one with the prettiest interface. The best email client — you get the pattern. When you're choosing between tools, especially during the hex elimination, weight MCP support and API connectivity at least as heavily as you weight the tool's core features.
The Workaround Layer
Sometimes you can't find an integrated alternative for a tool you genuinely need. The thing it does, nothing else does as well, and the MCP connector doesn't exist. This happens. When it does, the workaround is usually your automation tool.
Your automation tool — n8n, Zapier, Make, whatever holds that slot in your hex — can often serve as a bridge. An n8n workflow that watches a folder, processes new files, and pushes results to another tool can turn a disconnected tool into a semi-integrated one. It's not as clean as a native MCP connection, but it reduces the manual steps from several to one or zero.
The key is to be honest about the workaround's reliability. A workaround that runs automatically and never breaks is effectively integration. A workaround that breaks every other week and requires you to log in and fix it is technical debt, not a solution. If the workaround is fragile, you're better off either accepting the manual step as part of your workflow or, more likely, finding a different tool for that slot.
Testing Cross-Tool Workflows
Individual tool integration is necessary but not sufficient. The real test is whether your tools work together — not just whether Claude can access each one individually, but whether Claude can execute a workflow that touches three or four tools in sequence.
Design a test workflow that mirrors your actual work. If you're a publisher, it might be: "Check my email for the guest post submission from [name], pull the attached document into my files, reformat it for Ghost, create a draft post, and schedule it for Thursday." That workflow touches email, files, your CMS, and possibly your calendar — four tools in sequence. Can Claude do it start to finish without you switching tabs?
If you're a consultant, the test might be: "Look at my calendar for this week's client calls, pull up the project notes for each client, draft a pre-call summary for each, and email me the summaries as a single digest." That touches calendar, files, your LLM, and email.
If you're a developer, try: "Check the last three commits in [repo], summarize what changed, update the project documentation, and draft a changelog entry." That touches your code repository, your files, and your LLM.
Run the workflow. Time it. Note where Claude gets stuck, where you have to intervene manually, where a tool fails or behaves unexpectedly. These friction points are your integration debt — the places where the hex isn't fully connected yet. Each one is either fixable (better MCP config, better system prompt, an automation bridge) or structural (the tool genuinely can't do this). The fixable ones are your priority for the next week. The structural ones go on the quarterly review list as potential swap candidates.
The System Prompt Connection
Integration isn't just about MCP connectors. It's also about Claude knowing how to use your tools together. This is where your system prompt comes in.
A good hex system prompt tells Claude not just what tools are available, but how they relate to each other. "When I ask you to publish something, draft it first, then create it in Ghost. When I ask about a client, check both my email and my project files. When I ask you to schedule something, check my calendar for conflicts first." These are workflow instructions, not just tool instructions, and they turn isolated tool access into coordinated action.
The system prompt for a well-integrated hex is surprisingly short — usually 200 to 400 words. It describes the six tools, their roles in your workflow, and the standard sequences for common tasks. You'll refine this over the 30-day trial, but getting a first draft done during the integration test gives Claude the context it needs to actually orchestrate rather than just access.
When the Integration Test Reveals a Swap
Sometimes the integration test tells you that one of your six tools — maybe even one you love — needs to go. The tool is great at what it does, but it doesn't connect to anything, and the workarounds are fragile. This is painful. It's also the right call.
The hex is a system, and a system is only as strong as its weakest connection. A tool that forces you to manually handle its output is a weak connection. It doesn't matter how good the tool is in isolation — the isolation is the problem. Swapping it for a connected alternative that's 80% as capable but fully integrated will make your entire hex faster, not just the one slot.
Make the swap. Run the integration test again on the new tool. Verify it passes. Then move on. The sentimentality you feel about the old tool is real, but it's about your relationship with the tool, not about its value to your work. The hex is about the work.
This article is part of The Hex System series at CustomClanker.
Previous: The Elimination Method | Next: The 30-Day Trial