Day 3: Building my first MCP app
Is MCP the future of integrations?
Today I approached the day very differently. Instead of my usual scattered tutorial-watching, I decided to set out a clear goal for myself and only watched the tutorials that were relevant to achieving that goal.
I've been hearing a lot about Model Context Protocol (MCP) as an integration pattern, and I was keen to try it myself and understand if MCP is actually the future of app integrations.
The goal: Build an app using MCP.
The problem space I've been exploring is project management, so I wanted to build an app that would use MCP to take action in a project management context. Not wanting to spend too much time on the idea, I decided to build an app that would take in meeting notes as the input, automatically extract action items, and then create them as tasks in Asana using Asana's MCP.
Check out my demo here:
Tutorials I watched
What I learned
This was a massive learning experience and generated a lot more "questions" I'm keen to explore as I go along.
It’s hard to capture a lot of the iterative learnings, but here’s a few that come to mind (both tactical and high level):
Context7 is a useful MCP to install that automatically has access to the docs of many popular developer tools and frameworks.
Using AI for prototyping is really invaluable. One of the big questions I'm grappling with moving forward is what should you work on first—the front-end or the backend? Conventional wisdom would say work on the backend and validate that the functionality works, then finesse your front-end. But here's the thing: the front-end is then usually the part that feels rushed.
It feels like right now we're living in a world where almost everything is possible in the backend, and good design matters so much. I think likely the correct answer is a hybrid of the two, and Figma still has a big place for iteration - especially when we’re dealing with new AI design patterns. I guess I'm really feeling the tension of this question as I'm giving myself tight timelines to create something, which means if I leave the design for the end, that is the part that will be rushed.
Claude Code is very TDD (test-driven development) oriented which is nice, although it does mean more waiting around time.
My takeaways
Is MCP a good standard for production-grade integrations? I don't know enough to answer just yet, but I will say my experience with integrating with MCP was that there are two areas where I felt MCP kind of fell short:
Authentication: It's not clear how seamlessly you can combine MCP with user authentication if you’re using it inside your own app. I bypassed this in the end by using Zapier’s MCP integration, where I could authenticate my Asana with Zapier instead.
Tool use guardrails. I haven't figured out how you can place very tight guardrails on what specific actions the agent is allowed to take with a particular MCP. I know that you can limit it at the MCP server level, but how do you reliably ensure that your agent is only using the correct tools for the correct action and also isn't hallucinating tools? I know prompt engineering is the answer, but it feels like using more tightly defined API integrations would just be more reliable.
Questions I want to explore further
Is it better to do the UI first and then wire up the backend, or make the functionality first and then style it? Case in point: how generic the UI of my final app looked. But, it could be argued that testing the functionality makes it more clear what needs to be part of the UI.
What are best practices for using Claude Code inside of Cursor? Currently the terminal doesn't save chats like Cursor does with its agent chats.
How do I get better at breaking down tasks into chunks and committing things more regularly? I can see how a codebase can become extremely complex quickly, and I'd like a way to keep track of and understand it.
How to provide docs for Claude Code to reference in the same way you do in Cursor?
How should you prompt Claude Code to only write minimal and clean code?