← Back to blog

I added Parallel web search to Codex. 27 seconds, no API key, the URL was wrong.

I added Parallel web search to Codex. 27 seconds, no API key, the URL was wrong.

Saturday evening, agentbox, terminal open. A tweet says Parallel is "the fastest, highest quality web search tool" and gives one line to add it to Codex. I paste it. Codex says "Added". I run a test. It works.

That is the short version. The longer version has two snags that nobody puts in the tweet, and one number I did not expect.

The command as shared does not work

The command going around is this:

codex mcp add parallel-search --url search.parallel.ai/mcp

Codex accepts it. It writes the server into ~/.codex/config.toml and reports success. But search.parallel.ai/mcp is not a URL, it is a hostname with a path. Codex wants a scheme. Add it:

codex mcp add parallel-search --url https://search.parallel.ai/mcp

Small thing. It costs you ten minutes if you do not know where to look, because codex mcp list shows the server as enabled either way.

No API key, and the server still answers

I expected a login wall. Most search MCPs want a bearer token before they talk to you. So I hit the endpoint with plain curl first, no auth header:

curl -X POST https://search.parallel.ai/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}'

HTTP 200. Server name "Parallel Web Search MCP Server", version 1.27.0, two tools: web_search and web_fetch. The response headers list x-api-key and Authorization as accepted, so there is a paid lane, but the free lane opens without asking who you are.

The server also sends its own instructions to the model. The useful part, in their words: use web_search first, the excerpts are meant to be answer-ready, do not fetch every result. You can pass several search_queries in one call. Only reach for web_fetch when you need exact wording or a specific page. That is good advice for any search tool and I wish more MCP servers shipped it.

The test: 27 seconds end to end

codex exec --skip-git-repo-check --approve-for-me \
  -c model_reasoning_effort=low -C ~/sites-beheer \
  "Search with parallel-search/web_search: WordPress 6.9 release date. \
   Report which tool you called, whether it succeeded, and the top 3 sources." < /dev/null

Output, trimmed:

mcp: parallel-search/web_search started
mcp: parallel-search/web_search (completed)

Tool: parallel-search/web_search
Status: succeeded (isError: false)
1. https://wordpress.org/documentation/wordpress-version/version-6-9/
2. https://wordpress.org/download/releases/6-9/
3. https://versionlog.com/wordpress/6.9/

Wall clock for the whole codex exec run, including model startup and every other MCP server in my config waking up: 26.9 seconds. 64k tokens used. Two of the three sources are wordpress.org itself, which is the right answer for that question. A search tool that hands you the primary source first is doing the job.

I have not benchmarked it against Brave, Exa or Tavily and I am not going to claim "fastest" from one query. What I can say is that the search call itself was a small slice of those 27 seconds. Most of the wait was Codex starting up.

The second snag: `--sandbox` and `--approve-for-me` fight

My normal codex exec line has --sandbox workspace-write in it. Add --approve-for-me so MCP tool calls are allowed, and Codex refuses:

error: the argument '--sandbox <SANDBOX_MODE>' cannot be used with '--approve-for-me'

So for MCP runs you drop --sandbox. Without --approve-for-me every MCP call fails with "MCP tool call requires approval, but approval policy is never". You need one and cannot have the other. That is a Codex CLI thing, not a Parallel thing, but it is the first wall you hit after the URL.

Noise you will see and can ignore

If you also have the Cloudflare MCP servers in your config and never logged into them, every run now prints five AuthRequired errors from rmcp::transport::worker before Parallel even starts. They are harmless. They are also loud. I left them in for now; removing servers I do not use is a different chore.

Would I keep it

Yes. It is one config line, it costs nothing to try, and the excerpt-first design means the model spends fewer tokens fetching pages it does not need. The free tier will have limits I have not hit yet. When I do, that goes in an update here.

If you want to try it on your own machine, this is the complete version of the tweet's command, with the fix:

codex mcp add parallel-search --url https://search.parallel.ai/mcp
codex exec --skip-git-repo-check --approve-for-me -c model_reasoning_effort=low \
  "Search with parallel-search/web_search: <your question>" < /dev/null

Next thing to check is what web_fetch does with a page behind Cloudflare's bot rules. Half my own sites sit behind those, so that is the test that tells me whether this tool is useful for auditing my own portfolio, not just for reading docs.

Related articles

Build your first automated video

One API key for deterministic JSON-to-video plus AI video & image generation. Documented and ready for your pipeline.