We just shipped MCP support!
I was losing too much time switching between tools. Building a feature in Cursor, jumping to Supernormal to generate the client update, then back to my editor.
Supernormal already turns meetings into completed work - PRDs, proposals, follow-ups, specs. But I don't always want to leave my editor or my Claude Projects to create that output.
So, we built MCP support. Now you can use your meeting context to generate deliverables directly in Claude, Cursor, ChatGPT, or any MCP-compatible tool.
What this unlocks:
→ In Cursor? "Write a technical spec for the auth flow based on the client kickoff call." Done, without leaving my editor.
→ In Claude Projects? "Draft a proposal using the discovery meeting and our pricing discussion." All my meeting context is right there with my codebase and docs.
→ In ChatGPT? Generate client updates, PRDs, or follow-ups using actual meeting context, not memory.
One command to set up. Then try: "Create a project for the redesign and add all the client calls to it."
No more switching tools to create client work. Your meeting context works wherever you work.
This solves a real hidden tax — context switching between where knowledge is created and where it gets turned into output. MCP support basically turns meeting context into an execution layer instead of a reference layer.
What I find interesting is how this changes the definition of ‘source of truth’ — it’s no longer the tool, it’s the context graph across tools.
Curious though — how are you handling versioning and drift when the same meeting context is used across different outputs (specs vs PRDs vs client updates)? That’s usually where consistency starts to break at scale.
I’ve seen some builders pair this with small, high-intent workflow experiments (fixed scope, limited steps, strong output constraints) to validate which context actually matters most before automating everything — surprisingly effective for reducing noise.
Feels like MCP makes that whole loop much more powerful. Have you seen users converge on specific workflows yet?
This is a strong direction—because the real problem was never “writing docs,” it was always losing context between tools.
MCP here feels like a practical step toward collapsing that fragmentation: meeting context becomes portable, and execution happens where the work already lives instead of being reconstructed in every app.
If this holds up in real usage, the impact is less about speed and more about reducing interpretation overhead—the gap between “what was decided” and “what gets built” shrinks dramatically.
The hard part will be keeping context clean and trustworthy as it accumulates over time.
Reducing context switching while turning meetings into executable output is a big win. This feels like a meaningful step toward truly integrated, context-aware workflows.
This comment was deleted 5 months ago