Stephan's MCP workbench
Late convert to MCPs. Two jobs: deeper context when building features, and digging through logs when production sticks. My Cursor stack and what each connection is for.
4 min read
Background
I’m a late convert to MCPs. I dragged my feet, felt like another connector fad. I was wrong.
What got me: the agent can sit with more moving parts than I can. I still make the calls. It just doesn’t tap out when logs live in three places, or when something breaks between DNS, an edge function, and a deploy I forgot about.
Two jobs, mostly.
First, building something new. I want the prompt to actually understand what I built, not guess from filenames. Sentry so it can see which events fire. Supabase so it can read the schema. Log tail or Sentry history so it can follow how data moves. Give it that depth around a specific ask and the answer gets a lot more nuanced.
Second, unsticking production. Bottlenecks, broken flows, “it worked yesterday.” Same hooks, different panic. It can stay in the mess longer than I can before I lose the thread.
OK, so what’s plugged in.
Cloudflare is less about emergency DNS and more about background I’d forget to mention. Subdomain records, an R2 bucket for files, where certain things live. Miscellaneous context about my setup so the agent isn’t working from generic docs.
Supabase I reach for when I’m adding a feature, not just debugging. I know the model will make stuff up to make me happy. If I make it start from live schema first, or set a rule that says understand what’s already there before you code, I get subtler answers, fewer file changes, and features that actually match what I built.
Postmark is my mail delivery engine, but the MCP gives me more than send status. What signatures am I using? What layouts do the templates have? Which templates are tagged for which parts of the code? So when I ask Supabase to change an edge function that sends email, the agent can see both sides: what I’m asking for in the prompt, and what Postmark is actually set up to expect. Sometimes it looks at past sends and catches a broken link I would have shipped.
Sentry is the magic addition to this stack. It’s my observability layer, and I use all of it: events, milestones, source maps, the works. I have a rule that says when we’re building code, don’t make me come back later and ask for observability. Wire it in as we go. Hooking Sentry into MCP probably tripled or quadrupled my productivity, because the agent gets a longer history: what’s already been shipped, how the code actually runs in production, how often it gets called, what patterns show up. Code alone doesn’t tell you that.
The last non-intuitive piece is GitHub. I store issues there, but I also want the agent to look backwards at changes. New feature, no commits around it yet, fine, it knows this is greenfield. Existing feature, sometimes I want it to pull the history of how this area changed, so it understands why I’m moving in a direction or what I’m reacting to. Marry that with Sentry and it stops being just code. You get use case, usage, and the story of how you got here.
Google Analytics I use in a surprising way. I think of it as long-tail context. I tell my Cursor agents to only go into GA when they’re missing the pattern, when the narrow tools haven’t explained what’s going on yet. Analytics is the broad brush. Sentry tells you what broke. GitHub tells you what changed. GA tells you how people actually moved through the thing over time.
Finally, Telora. Experimental project from my friend Jeremy, and it’s a different lane entirely. More about AI intent than implementation. I use it with Claude, mostly, not Cursor when I’m in this mode. It lets me back way out of deterministic “just write the code” thinking. Big context window, pulling from GitHub, Sentry, Postmark, meshing that together so I’m not jumping straight to a solution. I’m in the problem space first, trying to see it the way a customer would.
I’m still working through all of this. It’s a work in progress. If you want to understand how I think about securing MCP so it doesn’t do more damage than good, see How I secure my MCP connections.
It’s good to remember AI agents are not human. They are way better with high data complexity than we are. To use them correctly we need to give them focused context.