TaskDrop

• 

  Hero Image

• 

  workspace page

• 

  landing page

Inspiration

Before WebMCP, TaskDrop was a handoff layer. With WebMCP, it became a workspace.

TaskDrop started as a way to move working context between AI clients. Different AI tools are good at different things, but their context is usually trapped inside individual conversations and applications. TaskDrop originally addressed this with temporary, versioned Markdown Handoffs that AI clients could read and update through MCP.

That worked for AI-to-AI transfer, but it exposed a bigger limitation: the human was still mostly outside the shared working state.

A Handoff could move from one AI to another, but there was no first-class place where a human could inspect what was being transferred, correct stale assumptions, refine missing details, or collaborate with a browser agent before the next AI continued.

TaskDrop started as a way to move working context between AI clients. WebMCP transformed it into a shared human-agent workspace where that context can be inspected, refined, corrected, and safely committed before the next AI continues.

What WebMCP changed

WebMCP changed TaskDrop from a handoff transport into a shared human-agent workspace.

Before WebMCP, TaskDrop could move committed context between AI clients. With WebMCP, that Handoff becomes a visible workspace where the human and browser agent can inspect and refine the same Working Draft.

When the agent updates the Working Draft, the change appears immediately in the editor the human is already looking at. The human can continue editing, correct the agent, or discard the Draft.

Human + WebMCP agent
          ↓
     Working Draft
          ↓
    explicit Commit
          ↓
  Immutable Revision
          ↓
 Remote MCP clients

The Working Draft creates a clear boundary between work in progress and shared state. Human and agent edits remain local until an explicit Commit creates the next immutable Revision. Once committed, another MCP client can immediately continue from that state.

WebMCP also makes TaskDrop's shared memory more transparent. The workspace exposes Revision history and records whether a committed Revision came from mcp, human, or webmcp.

And when another client commits a newer Revision while the browser is still editing, TaskDrop preserves the local Draft and lets the human decide how to proceed instead of silently overwriting either state.

Before WebMCP, TaskDrop moved context. With WebMCP, humans and agents can work on that context together.

How we built it

We kept TaskDrop's immutable Handoff model and added a lightweight, browser-owned collaboration layer on top of it.

The core architectural rule is simple:

Browser owns unfinished collaborative work. Server owns committed immutable Handoff state.

The Working Draft therefore lives in browser-session storage. Human edits and WebMCP edits modify the same local Draft, while the server continues to store only immutable, append-only Revisions.

Remote MCP and the browser workspace use different interaction surfaces, but both ultimately operate on the same Handoff application logic:

Remote MCP ──────┐
                 ▼
        Handoff Application
                 ▲
Browser API ─────┘
     ▲
Web UI + WebMCP

We also designed the WebMCP tools as page-scoped capabilities. The browser agent operates on the Handoff already open in the workspace instead of receiving the user's underlying Space Key as a normal tool parameter.

That gave us another principle we want to preserve:

The agent should receive capability, not credentials.

These choices let us add meaningful human-agent collaboration without turning TaskDrop into a full collaborative document platform.

Challenges and what we learned

The biggest challenge was not exposing TaskDrop through WebMCP. It was deciding what should become collaborative, and where that collaboration should live.

TaskDrop originally assumed that committed Handoff state moved between AI clients through MCP. Once a human and a browser agent could both participate, that model was no longer enough.

We needed a place where both sides could safely inspect and refine the same state without turning every intermediate edit into a server Revision.

That challenge led directly to the Working Draft model.

The same principle also helped us handle concurrency. If another MCP client updates the Handoff while the browser is editing, TaskDrop preserves the local Draft and asks the human how to proceed instead of silently overwriting either version.

Credential handling taught us a similar lesson. An agent should operate within the application context the human has already opened, rather than being handed the credentials that created that context.

Together, these challenges changed how we think about WebMCP itself.

With Remote MCP alone, TaskDrop was good at moving state between AI clients, but there was no natural shared surface where a human and an agent could work on that state together.

WebMCP fills that missing layer.

Remote MCP
AI Client A
     ↓
  Handoff
     ↓
Human + WebMCP agent
  Working Draft
     ↓
   Commit
     ↓
  Handoff
     ↓
Remote MCP
AI Client B

It allows the agent to participate directly in the application state the human is already seeing.

MCP helps agents connect to services. WebMCP helps agents enter the human's application workflow.

For TaskDrop, that difference turned an AI-to-AI handoff layer into a place where humans and agents can inspect, correct, refine, and commit shared working context together.

Built With

• chatgpt
• codex
• docker
• mcp
• node.js
• typescript
• webmcp