ZennoPoster: browsers of running tasks MCP server

English | Русский

Connecting the ZennoPoster and ZennoDroid MCP servers to your own LLM client

The MCP servers are published as self-contained win-x64 binaries via GitHub Releases in the shared repository https://github.com/ZennoLab/zennoposter-mcp/releases. Each server has its own release line (its own tag prefix):

• ProjectMaker (editor) — tags mcp-projectmaker-v*, archive MCP.ProjectMaker-v*-win-x64.zip
• Instance (browser control, dual-mount) — tags mcp-instance-v*, archive MCP.Instance-v*-win-x64.zip
• ZennoPoster (task runner) — tags mcp-zennoposter-v*, archive MCP.ZennoPoster-v*-win-x64.zip
• Android (ZennoDroid device) — tags mcp-android-v*, archive MCP.Android-v*-win-x64.zip

PublicApi documentation (the OpenAPI contract rendered with Redoc, the integrator guide, error codes, versioning policy) lives at https://zennolab.github.io/zennoposter-mcp/ (the pages are published from the docs/ folder of this repository).

These servers talk to ZennoPoster 7.9.3 and newer and to ZennoDroid 2.6.1 and newer. MCP.Instance applies to ZennoPoster only and MCP.Android to ZennoDroid only; MCP.ProjectMaker and MCP.ZennoPoster apply to both. Which server version goes with which product and contract version: https://zennolab.github.io/zennoposter-mcp/compatibility.html.

Install buttons for Cursor and VS Code and the Claude Code commands for every server: https://zennolab.github.io/zennoposter-mcp/install.html.

The model: your own MCP instance with your own key

The product itself starts internal MCP servers for its built-in AI chat — they live on the internal port band 6107–6113 (on ZennoDroid everything is shifted by +10), receive a least-privilege service key from the host, and ignore the Authorization header of incoming requests. This is internal infrastructure: connecting to it from outside is not supported (permissions there are defined by the service key, not yours), and its ports must not be occupied — a foreign process on a port from this band prevents the built-in server from starting (the product logs an error, but its AI stack is left without that server).

Those internal servers have no console of their own, so the product copies everything they write to their output into its own log, each line prefixed with the process name (MCP.ProjectMaker, Orchestrator, …). Ordinary start-up chatter is tagged Debug and never reaches the log at all; only what the server itself reports as a warning or a failure, and the exit code of a server that dies unprompted, actually get written. That is the place to look when the built-in chat loses one of its servers.

Those internal servers also expect a per-machine secret that the product hands only to its own AI processes, so being able to reach the port is no longer enough to use one: a call without it is refused with `401`, and the refusal is written to the product's log as ingress refused. The same goes for the built-in chat's own API on 6113. If you were calling those ports from your own client, run your own copy on the public band instead, as described below.

For your own LLM client you run a separate copy of the MCP server from the public package: it listens on a public port (the tables below) and talks to the same product PublicApi, but with your ApiKey — with the scopes/tier you chose when issuing the key. Both copies run side by side without interfering with each other.

On ZennoDroid the two servers that serve both products listen +10 higher — MCP.ProjectMaker on 6217, MCP.ZennoPoster on 6220 — the same shift the product applies to its internal band. That way a machine with both products installed can run both sets at once. MCP.Android exists only on ZennoDroid and keeps 6211: nothing on ZennoPoster occupies it.

Default ports, one table per product. A server takes its listen port and BaseUrl from the appsettings.json next to its exe; the ports marked ¹ have no such defaults and are passed on the command line together with the matching BaseUrl (and Target), as in the examples of step 3.