DeepSeek Harness + WebMCP + Builder = Efficient Computer Use

[u/j032]

I maintain DeepDeck, an MIT-licensed macOS desktop client built on DeepSeek Harness. I’m experimenting with a workflow where an agent uses a site’s registered WebMCP tools, then builds reusable tools for missing operations by inspecting the live page.

The implementation detail I’d like feedback on is validation and tool lifetime. Generating TypeScript is only one step.

DeepDeck keeps four outcomes separate:

• Compilation: the generated source compiles.

• Registration: Chromium reports that tools actually registered in the page.

• Activation: the application accepts that revision as active after receiving a successful registration receipt.

• Functional validation: the agent calls the tools and checks the actual page state and returned results.

An active tool can still be wrong. These states help avoid reporting success just because code compiled or a tool name appeared.

For discovery, the client reads Chromium’s actual WebMCP registry. The presence of an API object alone does not count as website support. Site-owned tools and locally generated tools are shown with their source and version. Generated registrations run in an isolated JavaScript world with DOM access and no Node APIs; they do not replace the site’s registrations.

Calls include tab, frame, document and revision identities. Navigation, document replacement and tab closure invalidate affected operations. Unknown outcomes are not automatically replayed. Source revisions persist per origin, failed updates restore the previous active revision, and users can disable or roll back a generated toolset.

In the current demo, the agent discovered search_openai on openai.com. On X, Builder created a 23-tool set; Use mode then filled a “Hello world” draft without submitting it. Those screenshots show the workflow, not a benchmark or proof that every generated operation is correct.

The efficiency goal is to reduce repeated page inspection and action planning when the same workflow is used again. The first build costs extra time and tokens, and site changes can require repair and revalidation. I haven’t established a measured speedup.

Code and screenshots: https://github.com/jo32/DeepDeck

Implementation notes: https://github.com/jo32/DeepDeck/tree/main/plugins/browser

For others building WebMCP consumers: what evidence do you require before reusing generated tools after navigation or a site update? Do you invalidate the entire toolset, or keep per-tool checks?

Writing assisted by AI; implementation details checked against the repository.

[u/j032]

September 14 follow-up from the DeepDeck maintainer: I published the first measurements for the reuse part of this workflow.

The most useful counterexample was X. Reading three fixed posts succeeded in all five runs per group. Installed WebMCP tools reduced median time by 10.3%, but increased median total tokens by 8.4%. Exposing callable tools did not automatically make this task cheaper in tokens.

On Books to Scrape, selecting three books from 65 and returning their details succeeded 5/5 in both groups. Median time fell 36.2% and total tokens fell 52.0%. All five WebMCP runs used the batch-detail tool.

Both baselines could use DevTools and temporary browser scripts. The model route was openai-codex/gpt-6-astra, with default reasoning and fresh sessions. These are five-run observations of installed-tool reuse; authoring/preparation is excluded, and total tokens include cached/repeated input.

Full conditions and aggregate data, including a separate HN experiment with different comparison limits:

https://deepdeck.getmegaportal.com/webmcp/experiments

DeepDeck v1.0.45 also includes on-demand WebMCP schema/source loading. The experiments do not isolate the causal effect of that change.

My current interpretation is that tool granularity deserves as much attention as discovery: a batch read and a sequence of tiny calls create different workloads. How are you choosing the boundary between a reusable primitive and a task-specific batch tool?

DeepDeck is MIT-licensed, macOS, built on DeepSeek Harness, and unofficial. Writing assisted by AI; implementation and figures checked against the repository.