“Convert my OFO SVG logo to PNG.”
The FreeDesignStore image converter now publishes a machine-readable manifest and a browser API. An agent can provide the SVG file, request PNG at a specific width, and receive the generated file without clicking through the interface.
This conversion uses the browser canvas. It does not use an image-generation model. The agent still uses normal language-model tokens to understand and request the task, but the image bytes do not need to enter the prompt or model context.
MCP controls the job. A paired browser performs it.
An MCP server cannot safely take control of an arbitrary browser tab by itself. The browser must opt in through an OFO Runner, initially a browser extension or installed desktop companion. The runner opens an isolated tool page, checks its declared capabilities, invokes it, and transfers only the requested inputs and outputs.
One small protocol across every store.
Each compatible page publishes tool.json for discovery and exposes window.OFOTool.invoke(request) at runtime. The manifest describes schemas, permissions, privacy, deterministic behavior, and artifact output.
{
"id": "ofo.design.image-convert",
"privacy": "local-only",
"permissions": [
"input:provided-file",
"compute:canvas",
"output:create-file"
]
}The same contract can cover format conversion, image resizing, JSON formatting, document generation, audio processing, data cleaning, simulation runs, and other bounded browser tasks. Tools that require accounts, network APIs, payments, or sensitive data must declare those requirements separately.
Declared tools, explicit capabilities, bounded artifacts.
The first release should invoke only registered tool IDs with validated inputs. It should not expose a general “run JavaScript in my browser” capability.
Every runner belongs to a user account and device. Users choose ask-every-time, approve-this-tool, or approved-automation modes.
Run jobs in a fresh tab, iframe, worker, or browser context with origin checks, timeouts, input limits, and a verified manifest version.
Large files move through short-lived encrypted uploads or directly through the local bridge. MCP responses return metadata and a reference, not megabytes of base64 in the model conversation.
Record the requesting client, tool version, permissions, input hashes, result hashes, duration, and user approval without retaining private input content by default.
Desktop is reliable. Mobile needs honest constraints.
A desktop extension or companion can remain connected and process jobs while the browser is open. A phone PWA can pair, approve jobs, upload files, and run foreground tools, but mobile operating systems may suspend background browser work. Reliable unattended mobile execution therefore needs either an active foreground runner or an optional hosted ephemeral browser.
Voice is an input layer rather than a separate execution system: speak to Claude or another assistant, let it call the same MCP tool, approve on the paired device when required, and receive the result as a downloadable artifact.
A compact MCP surface can expose the whole ecosystem.
list_browser_tools- Search supported tools by capability, format, store, privacy, and device availability.
browser_tool_info- Return schemas, permissions, examples, limitations, and the tool version.
run_browser_tool- Submit validated inputs to a selected paired runner and return a job ID.
get_browser_job- Read status, approval requirements, logs, and artifact references.
cancel_browser_job- Cancel queued or running work.
list_browser_runners- Show paired desktop, mobile, or hosted runners and their current capabilities.
The goal is one MCP connection for OFO, not a separate MCP server configuration for every individual store.