Run the solvethree MCP server in Docker
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.
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-localBefore 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.
| Setting | Value |
|---|---|
| Command | docker |
| Arguments, in order | run, --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.
Check the available tools
Call
solvethree_capabilitiesafter connecting. The server exposes solving tools and task retrieval; it doesn't drive a browser or fill forms. - 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.
Create one logical task
Call
solvethree_create_recaptchawithsite,actionand arequestId;recaptchaTypeandwaitMsare optional. This tool reads its single proxy fromSOLVETHREE_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.
Wait for a usable result
If the task is
pendingorsolving, retrieve it withsolvethree_get_task. Onlyreadycontains a usable solution. Onfailed, stop polling and inspecterrorCodeanderrorbefore deciding what to change. - 5.
Submit from your application
For reCAPTCHA, submit
solution.token, not the task ID. Use the returneduserAgentandsecChUaidentity 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.
Sources and API reference
Run your first task.
Start with $5 in workspace credit.