← Pluno WebMCP for AnythingCONTENT HISTORY

Update to Pluno WebMCP for Anything

Snapshot Oct 24, 2026 · 13:37 UTC · version 0.1.22

Collection source: downloaded plugin package.

WHAT CHANGED

First saved snapshot

No earlier snapshot is available to establish a change.

Save Pluno WebMCP for Anything and check future changes in Following.

Up to 10 plugins free · no card required.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Use whenever doing anything in a browser. Prefer the callable tools injected into external Chrome and build reusable WebMCP tools when they are insufficient.",
  "included_files": [],
  "name": "webmcp-for-anything",
  "skill_md_contents": "---\nname: webmcp-for-anything\ndescription: Use whenever doing anything in a browser. Prefer the callable tools injected into external Chrome and build reusable WebMCP tools when they are insufficient.\n---\n\n# WebMCP for Anything\n\nThe Pluno extension can inject tools only into the user's external Chrome browser. Built-in agent browsers that do not support extensions cannot expose `globalThis.__PLUNO_WEBMCP_TOOLS__`. When the task can use external Chrome, prefer it because the injected tools make browser operations faster, more reliable, and more token-efficient than UI automation.\n\nUse tools in this order:\n\n1. Use native WebMCP tools when the browser exposes them to Claude/Codex.\n2. In external Chrome, use the fallback registry in the page context:\n\n   ```js\n   const registry = globalThis.__PLUNO_WEBMCP_TOOLS__;\n   const tools = (await registry.getTools()).map(({ name, description }) => ({ name, description }));\n   const tool = await registry.getTool(name);\n   const result = await tool.execute(input);\n   ```\n\n   Use the compact `tools` list to choose an exact name. Then inspect `tool.inputSchema` and its other metadata, construct matching input, and call `execute()`. Only `execute()` evaluates and caches the implementation. If execution fails with `error.code === \"PLUNO_WEBMCP_PAGE_EXECUTION_BLOCKED\"`, repeat the exact same registry call through the external-browser debugger connection already controlled by Claude/Codex, enabling `allowUnsafeEvalBlockedByCSP` when raw CDP options are available. Do not rewrite or regenerate the implementation.\n3. If neither path is available or sufficient, use ordinary browser inspection and automation to complete the task while gathering the evidence needed to build the missing reusable tools. Do not treat completing the task through ordinary browser automation as the end of this workflow.\n\nDo not report that no tools exist merely because `document.modelContext` is absent. Check the Pluno registry separately in external Chrome.\n\nIf the tools are insufficient or no tools exist yet, determine how the page owner would have implemented native WebMCP tools for the task while performing it in a way that gathers implementation evidence. Perform relevant actions through the UI and capture the page's network activity. Identify the exact first-party request flows: methods, endpoints, query parameters or bodies, persisted GraphQL operation names and hashes, pagination, required non-secret headers, response fields, and error behavior. Inspect the relevant page source and existing injected tool code in `globalThis.__PLUNO_WEBMCP_TOOLS__` as needed.\n\nDesign an API-backed tool whenever the page itself has an API path. Internal or undocumented endpoints, persisted GraphQL operations, opaque non-secret request constants, possible frontend changes, and reliance on the browser's existing authenticated session are normal implementation details—not reasons to choose DOM scraping. Reproduce the observed first-party request from page-context code and let the browser apply its live session at runtime, such as through same-origin `fetch` with `credentials: \"include\"` or the page's own runtime authentication mechanism. Treat credential values as opaque: never read them merely to copy them, and never hard-code, serialize, return, or include cookies, authorization values, CSRF tokens, account identifiers, or other session-specific data. The tool code should obtain any required runtime authentication the same way the page does without exposing it.\n\nPrefer general inputs, structured outputs, and pagination that let the tool perform the action independently instead of parsing only what is currently rendered. Use DOM extraction only after inspection demonstrates that no reproducible request path exists; do not choose it merely because the available API is private, undocumented, authenticated, or may change. If the request contract later changes, a future tool update can change with it.\n\nAfter implementing and exercising a complete tool definition, add it to the page registry so it is immediately callable and remains available for that origin:\n\n```js\nconst registry = globalThis.__PLUNO_WEBMCP_TOOLS__;\nconst tool = await registry.addTool({\n  name,\n  description,\n  inputSchema,\n  annotations,\n  code,\n});\n```\n\nUse `addTool()` for both new tools and full replacements; a matching name replaces the existing registry entry. The `code` value must be a self-contained async function string that runs in page context. Verify the added tool by calling `await tool.execute(input)` with representative input before finishing the task.\n\nNEVER include personal data, credentials, cookies, authorization headers, private raw payloads, or user-specific values in any tool definition. Generalize and sanitize everything.\n"
}

SHA-256 of public snapshot: 4857190d14e51dff2dd47ebef6fc4dd4ad8bdfdd9812d05dbe95128897f9310d