NodeCraft

Inspiration

AI assistants are getting much better, but I kept noticing the same gap. Most of the time I am still talking to an AI about the application I am using instead of letting the AI actually work with me inside it.

I wanted to explore a simple question: what if I and an AI agent could work on the same live application state?

I chose architecture diagrams because they make this easy to see. I can move a component myself, ask the agent to continue working, and the agent should be able to understand what is on the canvas now instead of starting from a separate representation.

That idea became NodeCraft.

What it does

NodeCraft is an architecture canvas where a human and an AI agent can work together.

I can create, move, remove, and organize components directly on the canvas. At the same time, NodeCraft exposes capabilities through WebMCP that a compatible AI agent can discover and use.

The agent can inspect the canvas, create components, connect or disconnect them, arrange the architecture, remove components, and flag something for design review.

The key part is that there is no separate AI version of the diagram. My actions and the agent's actions update the same application state.

For example, I can ask an agent to add an API service, Postgres database, Redis cache, and payment service. The agent can discover NodeCraft's WebMCP tools and create those components directly on the live canvas. I can then manually change the canvas and the agent can work from the updated state.

I also added undo and redo, local persistence, editable human and agent names, an activity feed showing who did what, JSON import and export, and a simple way to start a new canvas.

How I built it

I built NodeCraft with React and HTML5 Canvas.

The application registers seven WebMCP tools using document.modelContext.registerTool():

• get_canvas_state
• create_canvas_node
• connect_nodes
• auto_layout_nodes
• remove_node
• disconnect_nodes
• flag_for_review

I tried to make the tools describe useful actions rather than low level UI operations. An agent should be able to ask NodeCraft to connect two components. It should not need to know how I draw the connection on the canvas.

The tools that modify the canvas update the same React state used by the normal human interface. get_canvas_state gives the agent a structured view of the nodes and connections that currently exist, and I marked it as read only.

This is really the core of NodeCraft. I can make a change manually, the agent can inspect the current canvas, make its own changes through WebMCP, and I can continue working from there.

I also added cleanup for registered tools, duplicate connection protection, human and agent action tracking, undo and redo, local browser persistence, and versioned JSON import and export.

I experimented with WebMCP's cross origin model too. The flag_for_review tool is set up so that it can be selectively exposed to an authorized reviewer origin.

WebMCP is important to the project because I did not want to build another chat box connected directly to an LLM. NodeCraft exposes what the application knows how to do, and a compatible agent can discover those capabilities and use them. The agent and the application do not have to be designed as one tightly coupled system.

Challenges I ran into

One of the first challenges was deciding what the agent should actually be able to do.

I could have exposed low level actions that imitate how a human uses the interface, but that did not feel useful. If the user wants the API connected to Postgres, the agent should express that intent and NodeCraft should handle the visual details.

Shared state was another challenge. I wanted agent actions to affect exactly the same state as my manual actions. I did not want to maintain a second representation of the architecture just for AI.

There were also a lot of smaller problems that showed up while building: preventing duplicate directed connections, removing connections when a node is deleted, making sure WebMCP handlers have the latest React state, tracking whether an action came from the human or agent, safely importing project files, and cleaning up registered tools correctly.

Testing was interesting too. At first I could manually execute individual WebMCP tools, which proved the tools worked, but that was not the experience I was trying to build.

I then tested NodeCraft using the Chrome Model Context Tool Inspector with an actual agent. I gave it a natural language request to build part of an ecommerce architecture. The agent discovered the tools exposed by the page and created an API Service, Postgres Database, Redis Cache, and Payment Service directly on the canvas.

That was the moment the idea became much more real to me.

Accomplishments that I'm proud of

I am most proud that NodeCraft got beyond simply registering a WebMCP tool and showing that it could be called.

Seeing an agent discover the tools from the page and create components on the same canvas I was editing manually was the main thing I wanted to prove with this project.

I am also happy with the state reading side of it. get_canvas_state means the agent has a way to understand what currently exists instead of only having actions it can execute.

I spent time on the rest of the application as well because I did not want the result to feel like only a tool calling demo. The canvas survives a refresh, actions can be undone, human and agent activity is visible, projects can be downloaded and imported again, and a new canvas can be started without manually clearing browser storage.

For a hackathon project, I feel like I ended up with both a WebMCP experiment and something that feels like an actual small product.

What I learned

My biggest learning was that designing tools for an agent is different from adding AI to an existing interface.

The agent does not need the same interface that I need as a human. I care about dragging boxes and seeing connections on a canvas. The agent needs capabilities such as create_canvas_node, connect_nodes, and get_canvas_state.

I also underestimated how important reading state would be.

Giving an agent actions is useful, but giving it a way to understand what the human has already done makes the collaboration much more interesting. It means the agent can continue from the current application instead of treating every request like a new task.

I started the project thinking mostly about WebMCP tool calls. By the end, I was thinking about WebMCP more as an agent facing interface to the application itself.

That is probably the biggest thing I will take away from this project.

What's next for NodeCraft

There is a lot I could take further.

For NodeCraft, I would like to explore richer architecture semantics, multiple saved projects, cloud collaboration, architecture validation, and agents that can reason about architectural constraints rather than only manipulate the diagram.

I also think the idea applies beyond architecture diagrams.

Workflow builders, visual editors, planning tools, dashboards, and other applications already have structured state and actions that humans interact with through a UI. WebMCP creates an interesting opportunity to expose those capabilities to agents as well.

NodeCraft is my first experiment with that idea, and I would like to keep exploring what applications look like when humans and AI agents can work inside the same product together.

Built With

• agentic
• ai
• chrome
• html5
• humanai
• javascript
• react
• vercel
• visual-studio
• webmcp