TaskFlow + WebMCP integration — feedback on runtime-backed tool design

[정성우]

Hi everyone,

I’ve been experimenting with integrating WebMCP into a real application (TaskFlow), and I’d really appreciate feedback on the architectural direction.

You can try the live app here: https://taskflow.manifesto-ai.dev

This is not a demo built specifically for WebMCP. The app already had a client-side runtime (Manifesto) that defines domain state, actions, and legality, and WebMCP is used to expose that existing runtime contract to the browser.

What I built

TaskFlow is a task management app where:

• All state and transitions are defined in a runtime (Manifesto)
• The UI renders directly from runtime snapshots
• Actions (create_task, move_task, etc.) are explicit and domain-level
• Lineage tracks history and causal changes

With WebMCP, I exposed the same runtime-backed capability surface as tools:

• Reads: get_taskflow_context, task_brief_list
• Writes: create_task, move_task, delete_task, etc.
• Context: search_lineage, inspect_hovered_target

Tool execution happens against the same client-owned runtime that the UI uses, so UI, agent, and history stay in sync automatically.

Key design choice

Instead of exposing UI-level actions (click, select DOM nodes), I only expose semantic, domain-level intents.

So the browser host never interacts with DOM state directly — it operates on the same domain contract the app uses.

Why I chose this approach

From my experiments, exposing runtime-backed tools seems to avoid several common issues:

• No duplicated state between UI and agent
• No need to interpret DOM → domain
• Tool semantics are already well-defined
• UI updates naturally from the same snapshot

Questions / looking for feedback

I’d love feedback from others working with WebMCP:

1. Does this “runtime as source of truth + WebMCP as exposure layer” approach align with how you see WebMCP evolving?
2. Are there cases where exposing lower-level UI/DOM actions would actually be preferable?
3. For complex apps, do you see risks in binding tool surfaces tightly to domain semantics like this?
4. How would you approach multi-tab or cross-site scenarios with this model?

If helpful, here’s the implementation doc:

https://github.com/manifesto-ai/taskflow/blob/main/docs/CHROME-WEBMCP.md

Happy to share more details or test scenarios if useful.

Thanks!

[Alex McManus]

I think this approach seems consistent with the intent of WebMCP based on my understanding. In my experimentation, I also considered where the UI should navigate to, in order for the user to see what the agent is doing and perhaps to continue interactively. I also provided a means for the user to see a separate history of task executions. The transparency provides some (limited) mitigation to risk of the agent misbehaving.

Cheers, Alex.

[Sungwoo Jung]

Hi Alex,

Thank you for the detailed feedback and for sharing your experimentation insights. I really appreciate it.

I completely agree that UI visibility and providing a separate task execution history are important for transparency and mitigating the risk of the agent misbehaving.

That said, TaskFlow is currently designed as a single-page web app, so I hadn’t deeply considered multi-page navigation scenarios. In real-world usage, 

however, most users operate across multiple pages. Because of this, I’m currently thinking about how to properly maintain domain context during navigation.

One idea I’m exploring is injecting explicit domain-specific hints or structured context from outside the UI to help the agent avoid unnecessary reasoning steps when moving between pages.

I’d love to hear your thoughts on this approach. Have you encountered similar multi-page context challenges in your experiments? Do you think combining UI transparency with external context injection would work well in multi-page environments?

Looking forward to your perspective.

Cheers,

Sungwoo Jung