Run the solvethree MCP server in Docker

By solvethree3 min read

Build a local image from the official versioned SDK download, then have your MCP host launch it with Docker. Keep stdin open with -i and omit -t: the server speaks JSON-RPC over stdio, not a terminal protocol.

On this page

Build the local image

Save this as Dockerfile. It installs the official package on Node 22, switches to the non-root node user, and starts solvethree-mcp as the container's entrypoint. The build and run commands are included below.

Dockerfile · local stdio server
FROM node:22.23.4-alpine
RUN npm install --global https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz
USER node
ENTRYPOINT ["solvethree-mcp"]

# Build: docker build -t solvethree-mcp-local .
# Forward variables already set in the host; do not add their values to this file.
# Run: docker run --rm -i -e SOLVETHREE_API_KEY -e SOLVETHREE_PROXY solvethree-mcp-local

Before running it, set SOLVETHREE_API_KEY to your workspace API key and SOLVETHREE_PROXY to your proxy in the environment that launches Docker. Each -e NAME forwards an existing variable; it doesn't supply a value. Keep credentials out of the Dockerfile and image.

The image is built locally as solvethree-mcp-local; no Docker Hub account is needed. Running it doesn't create a hosted MCP endpoint or add browser automation.

Have your MCP host launch Docker

Configure a stdio server in your MCP host. Use Docker as the command, not solvethree-mcp: the image's entrypoint starts the executable inside the container.

MCP host launch settings
MCP host launch settings
SettingValue
Commanddocker
Arguments, in orderrun, --rm, -i, -e, SOLVETHREE_API_KEY, -e, SOLVETHREE_PROXY, solvethree-mcp-local

Don't add -t. The host needs the container's stdin and stdout for JSON-RPC. --rm removes the container when it exits.

Both environment variables must be available to the MCP host process. Setting them in a terminal won't help a host launched elsewhere unless that host inherits them. If the host restricts environment forwarding, allow both names.

For a Codex-style TOML configuration, use the mcp_servers.solvethree table with the command and arguments above. Include both variable names in env_vars, set startup_timeout_sec to 60, and set tool_timeout_sec to 100. See the MCP integration documentation for the underlying server contract.

Request a task and hand off the result

  1. 1.

    Check the available tools

    Call solvethree_capabilities after connecting. The server exposes solving tools and task retrieval; it doesn't drive a browser or fill forms.

  2. 2.

    Prepare the reCAPTCHA profile

    For reCAPTCHA, set up an active profile in Site profiles before requesting a solve. Match the hostname, capture action and reCAPTCHA type; don't assume one domain profile covers every action. Sending a task doesn't create a profile. The profile setup guide covers this prerequisite.

  3. 3.

    Create one logical task

    Call solvethree_create_recaptcha with site, action and a requestId; recaptchaType and waitMs are optional. This tool reads its single proxy from SOLVETHREE_PROXY. Each create call makes at most one task. If creation times out, reuse the same request ID with unchanged inputs to recover the existing task rather than creating another one.

  4. 4.

    Wait for a usable result

    If the task is pending or solving, retrieve it with solvethree_get_task. Only ready contains a usable solution. On failed, stop polling and inspect errorCode and error before deciding what to change.

  5. 5.

    Submit from your application

    For reCAPTCHA, submit solution.token, not the task ID. Use the returned userAgent and secChUa identity with the successful proxy. A ready task means a solution was generated, not that the target accepted your application request.

The MCP host receives private solution data. Keep those results out of shared logs; your application remains responsible for submitting them to the intended target.

Run your first task.

Start with $5 in workspace credit.

Create a workspace