The MCPs That Earned Their Keep

The number in my bio is 244. That's the claude-code-plugins-plus catalog, a GitHub repository of Claude Code plugins I built for distribution. It's a product I ship. It says nothing about what I run.

The number currently connected and authorized in claude.ai is somewhere over a hundred. Connected means I approved the OAuth handshake at some point and haven't revoked it. The list doesn't get shorter when I stop using something. There's no churn signal.

Catalogued Is Not Called

A tool archaeology I ran in April 2026 verified every platform in the stack and landed on roughly thirty tools mastered and active at any time. Thirty, against a hundred connected and 244 in the catalog. That number came from counting what I reached for without thinking, not what I'd technically authorized.

The gap between connected and mastered is the gap between "I can access this" and "I reach for it when the task comes up." A hundred-plus MCPs are connected because connecting is cheap. Find a relevant server, click authorize, it goes in the list. That's thirty seconds and a decision I haven't revisited.

The April archaeology also surfaced the pattern that explains the thirty-to-three gap: most of the connected tools have a use case, but not a recurring use case. Supabase is in the active stack. I work in it weekly. But I reach it via dashboard and direct API, the MCP surface hasn't found a task that needs it yet.

Three Got Called

In the last thirty days, three MCPs were called in production sessions and produced something real. The rest produced OAuth records.

Base44 first. Every session involving a production app went through this MCP. SparkAcademy, Involuer, the AI Setup Audit tool, Velo, create entities, query records, update schemas, manage custom domains. Four or more sessions in the window, multiple calls per session. This is the app layer. No other MCP in the connected list touches more of the actual product.

Make second. One week old. Two live webhooks created in the first session: the lead capture automation for audit.abstrekkt.com and the newsletter trigger for this series. The Make MCP had a scope issue during setup, scenarios_create came back "No approval received." It said why and where to fix it. Fixed in ten minutes. One week in and it already has two artifacts pointing to its endpoints.

HubSpot third. One session. Called search_crm_objects, got back real data, four contacts, three deals. Did what it was called for. One session doesn't make a daily driver. It worked on the first call, which is a lower bar than the other two met.

The One That Was Supposed to Run the Stack

n8n MCP.

This was the expected automation control plane. Sixty-five workflows in the instance. The MCP was supposed to mean: list what's running, check execution counts, build new scenarios from a conversation. That was the plan going in.

Throughout every session in the thirty-day window, n8n MCP returned CONNECTION_ISSUE. Not an auth error with a specific fix. CONNECTION_ISSUE. No scenarios_create. No scenarios_get. No connections_list. The MCP designed to introspect and manage the automation layer couldn't be introspected itself.

The migration audit that led to moving from n8n to Make, sixty-five workflows parsed, nine kept, thirty-eight archived, was executed via a Python script against exported JSON files.

n8n is capable automation software. This is about its MCP connector during one window. That line gets hard to hold when the only way I reach a tool is through a control surface that doesn't work. Part of why I moved to Make is that its MCP worked and n8n's didn't.

What Earns the Status

The pattern across the three that ran: each is in the direct path of a high-frequency task.

Base44 sits in the path of every production app session. There's no session involving a client-facing app that doesn't need entity operations. When the task happens every time you open Claude, the MCP calls happen automatically. Make sits in the path of the active automation work, live webhooks for current client pipelines. HubSpot sits in the path of the sales cycle.

The ninety-seven-plus connected but never called MCPs aren't bad tools. Most of them probably work fine. What they don't have is a high-frequency task they sit in the path of. The alignment between tool and recurring task is what generates calls. Without that alignment, the OAuth record just sits there, looking like a capability.

Connecting a tool doesn't make it a daily driver. Being reached for does: when the task comes up, not once, and not because nothing else was available. Three times a week. Automatically. Before you've thought about it.

A hundred-plus connected, three ran. That gap is the load test.