I just taught my app to talk to Claude — and it made me rethink the whole "flat list vs. messy whiteboard" problem I built UluP Spaces to so
Quick context: most project tools give you either a flat task list, or a whiteboard that turns into chaos past 20 items. I built UluP Spaces trying to solve both. Yesterday I shipped Ulupy — native MCP (Model Context Protocol) support, so Claude can create projects, add nodes, and manage tasks directly inside your account. No API key to copy, OAuth + Dynamic Client Registration handle the setup automatically. It's an open standard, so it's not locked to Claude specifically — any compatible AI client works.
Now the full breakdown — not just the pitch:
MCP / Ulupy (the new part): Claude connects via a standard OAuth flow, gets scoped write access (create project/node/task, mark complete — nothing else, no reading your private data), and works from a conversation, not a form.
Structure: Create a project — from scratch, from a built-in template, or from one shared by another user in the community library. Inside, you create nodes, each one a piece of the project. Add tasks inside a node: two tasks, complete one, the node hits 50%. Complete both, it turns green at 100%.
Focus Mode: Click any task and you're in its own focused space — notes, a Pomodoro timer, file attachments, all scoped to that one task.
Scale: Every node holds unlimited tasks. Every task holds its own notes/files. Unlimited nodes per project, unlimited projects. I've actually stress-tested this myself up to 100 nodes in one project and kept it fluid — tested and optimized, not just theoretical.
Present Mode: Turns the whole map into a walkthrough — arrow keys or mouse click to move node to node, each one previewing its tasks as you go. Built specifically so a project can explain itself to someone who wasn't there when you built it.
Search: Finds specific tasks and nodes across a project, not just node names.
Sharing (UluP Share): One click turns any project into a public, read-only page — no login required to view it. Pages are properly indexed (own SEO setup), and public profiles now have their own searchable page too.
Collaboration: Invite links, real member roles (viewer vs editor), real-time updates when someone else moves something.
Community templates: Anyone can submit a project as a reusable template — reviewed before going live, now with voting so the best ones surface.
Solo developer, built and tested all of this alone — including the OAuth/MCP layer from scratch last night. Happy to go deeper on any piece, technical or product, or hear where this breaks down for how you'd actually use it.
Nice that you went with native MCP support instead of a bespoke API layer; that's the right call now that assistants expect tools/resources over their protocol. Curious how you're scoping it, full CRUD on nodes and projects or a narrower tool surface so Claude can't do something destructive in a shared workspace? I ended up locking write actions behind an explicit confirm step when I hit the same tradeoff.
I have decided to split Claude's tasks. One task is to read the project, avoid duplicates, and provide you with a complete overview, while the other is to create the project, nodes, and tasks within it. It can also track the percentage of completion. Claude cannot read your personal profile or extract private information from it!
Splitting read and write into separate calls is the right instinct: one pass to ground the model in the current state and flag duplicates, and a second pass to actually mutate anything. I've run into the same issue when letting Claude do both in one go; it tends to talk itself into creating something because it forgot what already existed. Are the two tasks running as separate MCP tool calls in the same session, or fully separate invocations? That distinction usually matters more than people expect for how much context survives between them.
They're separate MCP tool calls, but within the same session. The first call is read-only: Claude gets the current project state and checks for existing nodes/tasks or potential duplicates. Only after that returns do we allow the write call.
Keeping them in the same session seems to work better because Claude still has the context from the first pass, while the explicit separation makes the mutation step much more predictable.
It's definitely been more reliable than letting a single tool call handle both discovery and mutation.
the scoped-write-only design (create/complete, no reading private data) is the detail I'd want to understand better, since it's a genuinely different trust model than most MCP integrations default to. most give the model broad read access "to have context" and then hope it behaves, you're doing the opposite, minimal access by default
curious how that plays out practically though, doesn't Claude need at least some read access to know a node already exists before creating a new one, otherwise the duplicate-node problem danielss raised above seems almost structural, not just a prompt-design issue. if the model genuinely can't see existing state, it's not "will happily create duplicates," it's "has no way to know it's duplicating." feels like there's a narrower read scope (just node titles, not full content) that could solve that without giving up the "no reading private data" guarantee
That's a really good point, and I think you're describing the exact trade-off I'm running into. The current design intentionally avoids broad read access because I didn't want the default trust model to be "give the model everything and hope it uses it correctly." But you're right... if Claude has zero visibility into the existing structure, duplicate detection can't be solved purely through prompt design.
A narrower read scope is probably the direction that makes the most sense — for example, allowing Claude to see lightweight structural metadata such as existing project and node titles or IDs, without exposing the full contents of private notes or other sensitive data. That would give it enough context to ask "does this already exist?" before creating something new, while keeping the principle of minimal access intact. So I don't think the answer is broad read access, but I do think "write-only" may be too restrictive as the product becomes more complex. This conversation is actually helping me define where that boundary should be.
glad it's useful, and "write-only might be too restrictive as it gets more complex" is a good, honest place to land, better to find that boundary through a real edge case like duplicate detection than to guess at it upfront. curious to see where you draw the final line between structural metadata and actual content
Teaching an app to talk to Claude is surprisingly easy technically but surprisingly hard in terms of prompt design. The API call itself is trivial — the real work is in structuring the context window so Claude has enough information without being overwhelmed. The flat list vs messy whiteboard framing is spot on — structured data is easier to validate but harder to adapt, while freeform context is flexible but unpredictable.
Exactly. The API call was actually one of the easier parts for me too — the harder question was deciding what Claude actually needs to know about the project at each step. That's also why the structure of Spaces matters so much to the MCP integration. A node-based project gives Claude something more explicit to reason about than an unstructured canvas, while still keeping the flexibility of a visual workspace. I'm still experimenting with how much context to expose for each operation. Too little and Claude doesn't understand the project; too much and you just bury the useful information.
The MCP integration is really interesting. I like the idea of being able to manage the project directly from Claude instead of constantly switching between tools. The scoped permissions are also a nice touch.
Thanks! That was exactly the goal with the MCP integration — being able to work on the project from Claude without constantly jumping back and forth between tools. I also wanted the permission scope to be explicit, so the user stays in control of what Claude can actually change.
The MCP + OAuth/DCR piece is the part I'd lean on hardest — skipping the "copy your API key" step is exactly why most integrations die before the second session. One thing I'd watch: scoped write access from a chat means Claude will happily create near-duplicate nodes when a user rephrases the same request, so some idempotency or a "did you mean this existing node?" check will save you support pain. Also, Present Mode sounds like the sleeper feature here; a project that explains itself is a much easier thing to sell than "another whiteboard."
That's a really good point about duplicate nodes. I haven't solved that layer yet, but it's definitely something I'll need to address as MCP usage grows. An idempotency check or suggesting an existing node instead of blindly creating another one makes a lot of sense. And I agree on Present Mode. I initially built it as a presentation feature, but I'm starting to see it as something bigger — the project can actually explain itself instead of just being another canvas.
The scoped write-access design is the right call. The value of connecting AI to a project tool is creation and update, not reading back everything you have ever typed. Most integrations get this backwards and end up giving the AI too much context it doesn't need and users don't trust it with.
The MCP approach is interesting because the bottleneck in most AI-assisted productivity tools isn't the AI's capability. It's the quality of the structure it's working within. If someone's project structure is already unclear, Claude making nodes and tasks faster doesn't solve that. Worth thinking about whether the onboarding helps people structure projects well before bringing AI in.
I completely agree with this. Giving an AI more power doesn't really help if the underlying project structure is already messy, it just makes the mess happen faster.
That's actually one of the things I'm thinking about now: making the structure itself easier to build and understand before bringing AI into the workflow. MCP should amplify a good project structure, not try to replace it.
The structure creation UX is the real product then. Not the AI layer on top. Most tools rush to the AI features because that demos well, but the actual value is what happens before the AI enters the picture. If the structure is solid, almost any AI layer works. If it isn't, no amount of AI intelligence rescues the output. What does 'easier to build structure' look like for UluP Spaces?
I’ve implemented an AI-driven structure to speed up project organization. Instead of manually adding nodes and tasks, this approach saves time while still allowing you to make changes later. Plus, AI-generated projects can be shared via "Ulup Share," which creates a link accessible without logging in or downloading anything; the project can then be reused by anyone with the link, or submitted for review and published on the community template board, where other users can preview it and use it as a starting point for their own projects. What do you think?
The Focus Mode idea makes sense to me. Most project systems lose useful context when an idea comes up outside the task list. Then you have to reopen the whole project just to save one sentence. I built DictaFlow around that same problem for writing. Getting the thought into the right place quickly matters more than making the capture screen clever. It might be worth testing a fast way to add a voice note or rough thought directly to the focused task.
That's exactly what I was trying to solve with Focus Mode. I really like the idea of a quick voice note or rough thought directly on the focused task. The goal is to make capturing something before it gets lost as frictionless as possible. Definitely something I'll experiment with.
One implementation detail that caused more trouble than expected for me was streaming. A normal response can look compatible while streamed tool calls, usage metadata, and error handling behave quite differently.
I now test the same request in both streaming and non-streaming modes before treating an integration as complete. Did you run into any differences between Claude's content blocks and the format your app used before?
Yeah, streaming was one of the trickier parts to think about. I tested the actual Claude, MCP, UluP flow end to end, including tool calls and error handling. I haven't run into a major content-block mismatch so far, but I haven't done a dedicated streaming vs non-streaming test yet. That's a really good suggestion — I'll add that to my test cases.
The interaction model matters less than whether people can see which connections are current and which are just exploration. A whiteboard becomes useful when it helps a team decide what changes next, not when it stores every thought. I would test that with one real project and measure how often people can resume work without reconstructing the last discussion.
That's a sharp distinction, and honestly the one I hadn't fully separated in my own head — "can create things" vs "helps you know what's still true." Right now Spaces shows completion state per node, but you're right that it doesn't yet distinguish "settled decision" from "still exploring this." I like your test framing — "can someone resume work without reconstructing the last discussion" is a much better bar than "does the canvas look organized." I'm going to actually try that with one of my own real projects this week and see where it breaks. Appreciate the push to think about it that way instead of just adding more surface area to the canvas.
Interesting update, Manu. The MCP release seems to have added a very different dimension to Spaces.
The way you’ve described the new version makes me curious to see where you take it next.
Thanks, Aryan! Yeah, MCP ended up being a bigger shift than I expected too — going from "canvas I organize" to "canvas something else can act on" changes the whole feel of it. Still figuring out where it goes next, but appreciate you following along.
This comment was deleted 10 days ago
Link to try it: https://www.ulupspaces.com + live demo map in the comments: https://www.ulupspaces.com/share/32a63a89-f392-47fa-ae74-a758c029202d