dolphin-anty-mcp

Run the cookie robot

run_cookie_robot

Warm up a browser profile by sequentially visiting URLs and saving all resulting cookies. Requires paid plan and desktop app.

Instructions

Warm up a profile by visiting a list of URLs in a short-lived browser and saving every resulting cookie to that profile. Runs sequentially through the URLs. Paid plans only, and requires the desktop app. Progress is reported over Socket.IO, which this server does not subscribe to — the call returns as soon as the robot has started.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "browserProfileId": "<browserProfileId>",
      "data": "<data>"
    },
    "name": "run_cookie_robot"
  }
}

Input Schema

Name	Required	Description
`data`	Yes	Absolute URLs to visit, in order.
`headless`	No	Run without a GUI.
`imageless`	No	Skip image downloads — much faster.
`browserProfileId`	Yes
`browserProfilePassword`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 1, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses critical behavioral details: visits URLs in a short-lived browser, saves cookies, runs sequentially, and importantly that progress is reported via Socket.IO but the server does not subscribe, so the call returns immediately after starting. This goes significantly beyond the annotations (readOnlyHint=false, openWorldHint=true) by explaining the async fire-and-forget nature and requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise, front-loaded sentences with no fluff. Each sentence earns its place: purpose, execution order, and async/requirements. The format is highly scannable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with this complexity, it covers purpose, execution model, prerequisites (paid plans, desktop app), and return behavior (returns immediately). The lack of an output schema is compensated by clarifying that progress is not tracked by this server, so the agent knows not to expect completion status.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 60% of parameters. The description adds context for browserProfileId ('that profile') and data ('a list of URLs'), reinforcing their roles. It does not add new information for browserProfilePassword or headless/imageless beyond what the schema already states, but the overall meaning is clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: warming up a profile by visiting URLs and saving resulting cookies. It distinguishes this from related cookie tools (export_cookies, import_cookies) and browser automation tools by specifying 'short-lived browser' and 'saving every resulting cookie to that profile'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context: 'Warm up a profile' and notes sequential execution, paid plans, and desktop app requirement. However, it doesn't explicitly compare with alternatives like export_cookies or start_profile, so it lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server