gemini-skill: driving Gemini's web UI over CDP as an MCP server
gemini drawing MCP & skill through browser, can be used in openclaw or any agent that supports MCP. Gemini画图 MCP和sill,支持龙虾或任何agent使用٩(๑>◡<๑)۶
At a glance
- What is it?
- gemini-skill exposes Gemini's consumer web interface as MCP tools by attaching to a real Chrome or Edge session over the Chrome DevTools Protocol. It is a browser automation harness, not an API client, and that distinction decides whether it fits your stack.
- Who is it for?
- Adopt gemini-skill if you already have a logged-in Chrome profile and want Gemini image generation reachable from an MCP client without an API key; skip it if you need headless CI runs, per-seat isolation, or a stable contract.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 46 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: Gemini's image generation has no MCP surface
Gemini's consumer web app can generate images from a prompt, accept a reference image, and download full-size output. None of that is exposed as a tool an agent can call. gemini-skill's README states its purpose plainly: controlling the Gemini web version through CDP to automate image generation, conversation, and image extraction. The target user is someone running an agent that speaks MCP (the README names openclaw and any MCP-capable client) who wants Gemini image generation as a callable tool rather than a manual browser tab. The repository is JavaScript, MIT licensed, and its last push is dated 2026-08-01. No releases are listed, so versioning appears to live in the README changelog rather than in tagged artifacts.
Architecture: MCP protocol layer, operation layer, connection layer, daemon
The README's architecture diagram shows four tiers. An MCP client talks stdio JSON-RPC to mcp-server.js, which registers the tools and orchestrates calls. That hands off to index.js and browser.js, the connection layer, where ensureBrowser() either finds a running daemon or starts one, then attaches directly over CDP. The daemon is a separate background process (daemon/server.js, with engine.js, handlers.js and lifecycle.js) that talks HTTP to the MCP side for acquire and status, and WebSocket CDP to Chrome or Edge pointed at gemini.google.com. The documented responsibilities are separated deliberately: mcp-server.js handles protocol, gemini-ops.js handles operations, browser.js handles connection, daemon/ handles process management. The design choice worth noting is that the browser is not owned by the MCP call. It outlives it. The README says the browser stays open after an MCP call finishes and is only released after 30 minutes of inactivity, and that a missing daemon is started automatically on demand. Stealth is handled with puppeteer-extra-plugin-stealth, which the README lists as the anti-detection measure.
Getting it running: clone, install, set env vars, point at a logged-in browser
Prerequisites from the README: Node.js 18 or newer, and Chrome, Edge or Chromium installed (or a path supplied through BROWSER_PATH). The browser must already be signed in to a Google account, because Gemini requires login. Installation is git clone https://github.com/WJZ-P/gemini-skill.git, cd gemini-skill, npm install. Configuration runs through environment variables or a .env file, and the repository ships a .env template at the root. The documented precedence is process.env, then .env.development, then .env, then code defaults. The README notes that .env.development is not tracked by git, which makes it the right place for a machine-specific BROWSER_PATH. Beyond the browser variables, the README documents an Atlas Cloud provider section that adds an OpenAI-compatible API path alongside the browser automation, covering model enumeration, plain chat, and streaming verification, without changing the existing Gemini automation chain. If you would rather not install Node at all, the README points to Bloome, a hosted agent platform, as a zero-setup route.
The selector contract is the real maintenance surface
This project automates a UI it does not control. Every capability depends on CSS selectors and custom element names inside Gemini's front end, and the README's changelog is effectively a list of breakages. v1.1.0 adapted to the 2026-05 UI: the plus-panel button (gem-icon-button[arialabel="上传和工具"]), the send button (gem-icon-button.send-button), a download full-size button (download-generated-image-button), upload completion detection via .gem-attachment-content.loading, and status checks that tolerate the new gem-icon-button wrapper. v1.1.1 followed with model enumeration moving from pro/quick/think to pro/flash/flash-lite, reading the current model from .picker-primary-text innerText, and switching models by iterating menu items and matching label text so the logic survives localisation. Thinking depth also gained getThinkingDepth() and setThinkingDepth('standard'|'extended'), exposed as the gemini_set_thinking_depth tool. The README says old-UI selectors are kept as fallbacks so both versions work. That is a sensible hedge, but it also means the codebase accumulates dead branches that nobody can safely delete without knowing which Gemini build each user is on. If Google ships a UI change, expect a gap between breakage and a fix, and expect the fix to be a selector patch rather than a versioned migration.
Where the browser-in-the-loop design fails
The daemon model is convenient on a workstation and awkward everywhere else. A 30-minute idle window means a shared machine keeps a logged-in Google session alive long after the agent stopped calling tools. There is no documented per-user isolation: the automation drives whatever profile the browser is started with, so two agents on one host share one identity and one conversation history. Headless server deployments are not addressed in the supplied material, and since the whole mechanism is a visible web UI with stealth patches, treat unattended container use as unverified rather than supported. There is also no documented retry or backoff policy for the case where Gemini changes a layout mid-session, and no release artifacts to pin against, so a fresh git clone is always the newest code. If your requirement is a stable, quota-metered, auditable image generation endpoint, this is the wrong shape of tool. The README's own Atlas Cloud section is the admission that an API path exists and is worth having alongside the browser path.
Alternatives: a provider API versus automating the consumer UI
The honest alternative is calling an image generation API directly instead of driving a browser. The difference is not speed, it is what the contract is made of. An API gives you a request schema, an error taxonomy, and a quota you can reason about; gemini-skill gives you a selector list and a browser session. The repository itself demonstrates the contrast by shipping an OpenAI-compatible Atlas Cloud provider that the README describes as minimal-intrusion and separate from the browser automation chain, supporting model enumeration, chat, and streaming. That provider path is the one to pick when you want predictable failure modes. Pick the browser path when the thing you actually need is Gemini's web-only behaviour: the specific image output, the full-size download button, the watermark removal step the README lists among the features, or the reference-image upload flow. Those are UI affordances, and no API wrapper reproduces them by definition.
Licence, upgrades and what to verify before adopting
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; the automation itself still operates under Google's terms for the Gemini web app, and the README does not discuss that relationship, so check it yourself rather than assuming MIT settles it. Upgrade cost is dominated by the selector contract described above. There are no published releases, so you cannot pin a version and there is no changelog outside the README, which means the only way to know what changed is to read the diff. Before adopting, verify four things: that your Node version is 18 or newer, that BROWSER_PATH resolves to a browser you have already logged into Google with, that the model names your Gemini account exposes match pro/flash/flash-lite, and that the 30-minute daemon idle timeout fits how your agent schedules calls. If any of those four fails, the first tool invocation is where you will find out.
Editorial conclusion
Adopt gemini-skill if you already have a logged-in Chrome profile and want Gemini image generation reachable from an MCP client without an API key; skip it if you need headless CI runs, per-seat isolation, or a stable contract. Before wiring it in, verify that your installed browser matches the selectors the repository targets (the README documents a v1.1.1 update for the 2026-05 model menu, which replaced pro/quick/think with pro/flash/flash-lite), and confirm the daemon's 30-minute idle teardown is acceptable for your call pattern.
Community notes