DrissionPage MCP Server: 69 Atomic Browser Tools for Codex and Claude Code

The gap between an MCP client and a real browser

An MCP client can reason about a page it has been shown. It cannot move a mouse. That is the gap this project fills. DrissionPage MCP Server is a local Model Context Protocol server that wraps DrissionPage, a Python web automation library built around direct Chromium/CDP control, and publishes its browser-facing operations as typed tools that Codex CLI/IDE, Claude Code, Claude Desktop and other MCP clients can call. The README states the design intent in one line: the model decides what to do, the MCP executes the requested browser operation exactly. That sentence is also the project's boundary. Version 0.8.8 exposes 69 typed tools, zero MCP prompts and one static optional-Skills catalog resource. There is no capability profile and no opt-in full mode; every tool loads by default. The intended user is someone already running an MCP-capable coding agent who needs that agent to observe and manipulate a live Chromium page rather than reason about a static snapshot. It is not a scraping framework, not a scheduler, and not a hosted service.

Two pointer profiles and what deterministic motion actually buys

The mechanism worth understanding is the pointer model. Tools accept a profile argument with two bounded values. The direct profile emits one exact move to the target. The natural profile emits a deterministic 24-step eased cubic path with reproducible 8-14ms intervals and exact final arrival. The README is emphatic that there is no jitter, no overshoot and no anti-detection logic: the same start, target and profile produce the same path. Pointer position is stateful, so a repeated call can begin from the previous endpoint. Why does a deterministic path matter when a single jump would do? Because some surfaces only respond to motion. Canvas controls, editors, maps and charts often have no reliable selector, and a control that tracks pointer movement needs intermediate positions. The README's own flow is screenshot, model identifies viewport coordinates, page_click_xy with profile natural, then observe the resulting state. A click is defined as the selected move profile, an optional caller-specified delay, press, release. Drag keeps one press across the selected path and ordered waypoints. Results are typed and report executed coordinates, button, step count and delay metadata, which means the caller can verify what happened rather than assume it.

Structured DOM first, coordinates when there is no other option

The project takes a clear position on target selection: use structured DOM targets when reliable selectors exist, and fall back to coordinates and explicit drag waypoints for visual-only surfaces. Selector handling normalises CSS and XPath into forms the model can produce more reliably. One detail suggests the authors have been burned by stale geometry: for selector-backed drag operations, selector geometry is resolved immediately before execution, so the drag targets where the element is now rather than where it was when the model planned the action. Input failure handling is also explicit. If execution fails after the press, a pressed pointer button is released, which prevents a stuck button from poisoning every subsequent interaction in the session. Version 0.8.8 adds correlated network-listener generations, explicit packet cursors, timeout evidence, cancellation recovery and tab-owned cleanup. Those are maintenance-facing features, not headline features, and their presence is a reasonable signal that the authors have dealt with long-running sessions rather than only happy-path demos.

Install and the Codex or Claude Code configuration

The README describes a pip install plus either a Codex TOML configuration or an MCP JSON configuration. The package name on PyPI is drissionpage-mcp. Python 3.10 or newer is required according to the badge in the README, and browser execution is powered by DrissionPage, so that dependency has to be present and working before any tool will do anything. The README lists separate setup sections for Codex CLI/IDE, Claude Code, Cursor and Claude Desktop, which is a reasonable indication that the configuration differs per client rather than being a single universal snippet. The README as supplied does not include the literal config blocks for each client, so treat the per-client sections in the repository as the source of truth for exact keys rather than guessing at them. There is also an interactive Browser Lab at drissionpage-mcp.vercel.app which the README says can replay bounded natural pointer motion, drag controls and observable state. That is a useful way to see the pointer profiles behave before wiring the server into an agent.

The core ships no site workflows, and that is the real limitation

The most consequential sentence in the README is the one about scope: the core does not provide challenge-specific or site-specific workflows. Component-specific target discovery, challenge observation, multi-click sequencing and login procedures are explicitly assigned to the client or to an optional Skill outside the distribution. If you were hoping for a tool that logs into a site and extracts a table, this is the wrong tool, and the authors say so. The trade-off is deliberate and defensible: keeping the server atomic keeps the tool registry stable and the behaviour predictable, but it pushes real work onto whoever integrates it. A second limitation follows from the first. Because the model identifies viewport coordinates from a screenshot, coordinate-based interaction is sensitive to viewport size, scroll position and any layout change between observation and action. The natural profile's determinism removes randomness as a variable but does nothing about a page that moved. Selector-backed operations mitigate this by resolving geometry immediately before execution, which is the right instinct, but it only helps where a selector exists. The project is also labelled beta in its own README badge, and the version history shows rapid iteration through 0.7.x and 0.8.x releases. That is a project still finding its edges.

How it differs from Playwright MCP and browser-use style agents

The obvious comparison is Playwright's MCP server, which also exposes browser control to MCP clients. The difference is the automation engine underneath and what that engine optimises for. Playwright drives browsers through its own protocol layer and is the default choice for cross-browser test suites, with first-class support for Firefox and WebKit alongside Chromium. DrissionPage is Chromium/CDP-focused and pairs direct browser control with requests-style HTTP session support, which is a different centre of gravity: the README describes the server as exposing DrissionPage's browser-facing capabilities, and the library's HTTP session side is not the part being published as MCP tools here. A second comparison point is agent frameworks that bundle their own browser loop. Those tend to ship opinionated, higher-level actions and the reasoning policy alongside them. This project does the opposite. It exposes 69 atomic capabilities and states that composition belongs to the client. If you want a framework that decides when to click, this is not it. If you want a thin, typed execution layer that your own agent drives, this is closer to that shape.

Maintenance, licence metadata and what to check before adopting

The repository's licence field reads NOASSERTION while the README carries an Apache 2.0 badge and links to opensource.org. Those two signals disagree, and the discrepancy is worth resolving with the maintainers before you build anything commercial on top of it. This is a factual observation about the metadata, not legal advice; if the licence matters to your organisation, read the LICENSE file in the repository and get your own answer. On maintenance, the project shows a CI workflow, a codecov badge and a stated 95% coverage floor enforced in CI, with unit, protocol, schema snapshot, response-contract, resource, release-metadata, security-policy and browser-integration checks. The README also mentions browser tests covering cross-origin OOPIF reads and DrissionPage-exposed closed Shadow DOM lookup without JavaScript piercing. Those claims come from the README; they are not independently verified here. Upgrade cost is the more practical concern. The README states that 0.8.8 keeps the tool registry stable while adding network-listener generations, packet cursors, timeout evidence and cancellation recovery, which suggests the 69-tool surface is intended to be the stable contract and the churn is in behaviour and internals. If you pin the package and the DrissionPage version together, you avoid the most likely upgrade failure, which is a DrissionPage change altering how a tool resolves or interacts with a page.

Editorial conclusion

Adopt it if your MCP client needs typed, atomic browser primitives and you are willing to own the site-specific logic yourself; the README is explicit that the core ships no challenge-specific workflows, so anything resembling a login sequence or a component-library procedure has to live in your client or an optional Skill. Skip it if you want a ready-made scraping pipeline or a hosted service, because this is a local server you configure and run. Before committing, verify three things: that your DrissionPage version matches what the server expects, that the 69 tools cover the interactions your target pages actually need, and what the repository's NOASSERTION licence metadata resolves to, since the README badge claims Apache 2.0 while the repository metadata does not.

Official sources

1. Issues
2. jumodada/Drissionpage-MCP-Server on GitHub
3. README
4. Releases