Explore WebMCP support for agent-native interaction

[tomcasaburi]

Summary

Investigate exposing seedit functionality as structured tools via WebMCP, so AI agents can interact with communities, posts, and comments deterministically instead of scraping DOM or using screenshot-based heuristics.

This is exploratory and very low priority. Track for when the ecosystem matures.

---

Context

There are two relevant projects both called "WebMCP":

1. W3C Community Group spec (webmachinelearning/webmcp) — a browser-native API proposal (navigator.modelContext.registerTool(...)) backed by Microsoft and Google engineers. Currently a draft spec, not implemented in any stable browser.

2. webmcp.dev library (webmcp.dev) — an open-source JS library that works today via a widget + npx MCP bridge. No browser flags needed. Separate project from the W3C spec.

Either could be viable depending on which matures first. The W3C spec is the long-term bet; the JS library is usable now but less standardized.

Reference video: https://www.youtube.com/watch?v=xQAYZBDV5jg

---

Why seedit is a good fit

seedit is highly structured — communities, posts, comments, votes — which maps cleanly to tool schemas. If AI agents become mainstream web actors, WebMCP would let them:

• Browse communities and posts deterministically
• Create posts and comments via defined schemas
• Vote on content without DOM interpretation
• Navigate using structured tools instead of heuristics

Why WebMCP over raw plebbit-js?

An agent could use plebbit-js directly for headless protocol interaction. WebMCP adds value in a different scenario: in-browser, human-in-the-loop workflows where the agent sees what the user sees, shares the same session, and acts within the existing UI. Think browser assistants helping users compose posts, not autonomous bots.

---

Example tool mapping

Route	Tools
Community page	listPosts, createPost
Post page	replyToPost, votePost
Home page	listCommunities, searchCommunities

Tools would wrap existing UI logic, not bypass it.

---

Implementation approach (when/if picked up)

• Imperative registration (preferred for SPA): define tools in a webmcp.ts adapter, register on route load, unregister on navigation
• Clean adapter layer: Core logic → plebbit-react-hooks → WebMCP adapter
• WebMCP remains a browser-layer interface only — no protocol layer changes

---

Risks

• Spam vector: seedit is adminless and decentralized. Exposing createPost / replyToPost as structured agent tools could facilitate spam. Any implementation must inherit existing anti-spam measures (captchas, rate limits from the plebbit protocol layer), not bypass them.
• Ecosystem maturity: The W3C spec is a draft. The JS library is functional but niche. Neither has broad adoption yet.
• Security review needed: Tool exposure to untrusted agents requires careful scoping of what's exposed and what permissions are needed.

---

Non-goals

• Do NOT modify the plebbit protocol layer
• Do NOT introduce Chrome-only dependencies into core logic
• Do NOT block roadmap work for this
• Do NOT assume adoption — this is speculative
• Do NOT rely on WebMCP for any critical functionality

---

Priority

Very low. Keep as a forward-looking enhancement in case WebMCP matures and agent-native browsing becomes standard.