What Code Mode and MCP servers are — and why a script wants to call them

The Model Context Protocol (MCP) is the open standard that connects AI models to external tools and data sources. An MCP server exposes named “tools” — query a database, read a file, search a codebase, post to Slack — to any compliant client. The ecosystem ballooned in 2026: the official MCP registry held 30,375 unique servers as of September 10, 2026, roughly three times the ~9,650 in May 2026. August 2026 alone added 6,265 servers, more than the registry’s entire first five months (dev.to: The MCP Registry by the Numbers).

“Code Mode” refers to OpenAI Codex’s focused operating mode (Codex v0.114.0+) that restricts the agent to code-focused operations — read, write, test — without broader system interaction. Inside Code Mode the agent can still reach MCP servers, and the interesting 2026 shift is how it reaches them: by writing code that calls MCP rather than by selecting pre-registered native tools.

Why would a script want to call MCP servers at all? Two reasons dominate:

• Token economics. Every connected MCP server injects its tool definitions into the model’s context. Each mcp-call you run through your shell tool is just a command; a pipeline of several MCP tools piped through jq consumes a fraction of the context that the same work would take as interactive tool calls. Anthropic reports that programmatic tool calling — processing MCP results inside a code-execution sandbox — reduces token usage by roughly 37% on complex multi-step workflows (Anthropic: Building agents that reach production systems with MCP).
• Composability. A single bash script can read a row from Postgres, search GitHub for an issue, and post the conclusion to Slack — orchestrated as plain shell, not as sequential “assistant pick a tool then interpret the result” turns.

When your coding agent should call MCP from a script instead of a native tool call

The decision is not either/or; it is about how often and how predictably the tool will be used.

Prefer native tool registration when the server is a permanent part of your workflow and the model should “see” its tools in its tool list to choose among them intelligently. Claude Code and Codex both register servers natively (claude mcp add, codex mcp add), which gives the model structured tool schemas and lets the harness handle auth, rate limits, and audit.

Prefer scripts-over-MCP when the flow is multi-step and mechanical — read, transform, write — and you want to keep the model’s context lean. This is the core mcp-cli-skill pattern: an LLM agent writes a bash script that calls several MCP tools in sequence and pipes results through jq, then runs it with its shell tool. You get one result back instead of four sequential tool calls, and the shell composition is itself readable, testable, and re-runnable (mcp-cli-skill on PyPI).

The rule of thumb mirrors the skills-vs-MCP split: MCP handles how to use a tool, while a script (or a skill) handles sequencing and presentation (Anthropic: Extending Claude with Skills and MCP servers). When the ordering of tool calls is fixed and the transformation is pure bash, script it.

Prerequisites — register the MCP server you care about

Before any script can call an MCP server, the client you use must know the server exists. Registration is configuration, not a plugin install.

Claude Code registers servers three ways, across three scopes:

Four transports are supported: stdio (default), streamable-http, sse, and ws. Use -- to separate Claude’s own flags from the server’s launch command, so arguments that look like flags land on the server, not on the client. Project-scoped .mcp.json supports environment-variable expansion — ${VAR} and ${VAR:-default} — so secrets live in your shell environment, not in git (Claude Code MCP docs).

OpenAI Codex keeps its config in ~/.codex/config.toml, where [mcp_servers.<name>] TOML tables declare servers. Manage them with codex mcp list / add / get / remove / login. For Code Mode specifically, MCP is an opt-in [EXPERIMENTAL] feature — check your Codex version, because codex mcp-server was removed in 0.154.0 and you drive remote Code Mode hosts over stdio and gRPC rather than WebSocket (WebSocket transport was dropped in v0.151) (Continuum Code: Codex config, Blake Crosley’s Codex guide).

Option 1 — Drive MCP from a Bash script with mcp-call

The centerpiece pattern for “coding-agent scripts call MCP” is mcp-call, from the mcp-cli-skill package. It calls any MCP server tool straight from the command line and is designed for shell composition.

Install it as a CLI with pipx install mcp-cli-skill or uvx mcp-cli-skill, or as a Claude Code skill alongside. It seeds its config automatically from ~/.claude/settings.json and ~/.claude.json, so servers you already registered appear without extra setup, and it supports both stdio and HTTP transports. Shell tab-completion is included (mcp-cli-skill on PyPI).

The core pattern is one script that calls multiple MCP tools and pipes them through jq:

#!/usr/bin/env bash
set -euo pipefail

# Read order status from the orders MCP server
order=$(mcp-call orders get_order --id "$1" | jq -r '.data')
# Search GitHub for the matching issue
issue=$(mcp-call github search_issues --query "$1" | jq -r '.items[0].html_url')
# Post the summary to Slack
mcp-call slack post_message --channel ops --text "Order $1: $order — issue $issue"

Because each mcp-call is a normal command, the shell is the orchestrator. The agent writes this script, runs it with its shell tool, and gets one compound result back — no need for several separate MCP tool calls, and no need to inject the intermediate JSON back into the model’s context turn after turn.

Option 2 — Write a one-shot script against the MCP SDK over stdio

When mcp-call doesn’t expose the exact tool you need, or you want tighter control, write a short Python script using the official MCP SDK. The MCP client connects to the server over stdio and calls tools programmatically:

import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def main():
    params = StdioServerParameters(command="uvx", args=["my-server"])
    async with stdio_client(params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            res = await session.call_tool("search_docs", {"query": "MCP transport"})
            print(res.content[0].text)

asyncio.run(main())

This is the “write the code, run it, read the output” pattern that Code Mode leans on heavily. The script is a durable artifact you can commit, test, and re-run — and because it runs in a code-execution sandbox, it doesn’t hold the model’s attention while it awaits interactive results. It is also the mechanism behind Anthropic’s ~37% token reduction on multi-step workflows, since programmatic tool calling keeps results out of the conversational context window (Anthropic: Building agents that reach production systems with MCP).

Option 3 — Code Mode: let the agent write code that talks to an HTTP MCP server

Code Mode (OpenAI Codex) takes the “scripts over native tools” idea to its logical endpoint: instead of the model selecting from a fixed list of tools, the model writes the tool-calling code itself, with search() and execute() paths.

The flagship demonstration is Cloudflare’s Code Mode MCP server, which collapses more than 2,500 Cloudflare API endpoints into roughly 1,000 tokens of context — a 99.9% reduction versus a tool-per-endpoint approach. Because the model writes code rather than picking from pre-defined functions, new products require no new tool definitions when they launch: the model just writes a new search() or execute() call (danielvaughan.com: Codex CLI Cloudflare Code Mode MCP). The first API call triggers an OAuth 2.1 flow that downscopes the token; setup is either /plugins in the TUI or an explicit [mcp_servers.cloudflare-api] TOML entry for CI.

This is the philosophical answer to “letting coding-agent scripts call MCP”: in Code Mode, calling MCP is writing a script. The model generates shell or Python that talks to the server, the harness executes it inside a sandbox with secret isolation and full auditability, and the result comes back as plaintext — which is also why v0.139 of Codex lets Code Mode call standalone web search directly and get plaintext results for the same reason (Blake Crosley’s Codex guide).

Keep tool context under control — the 3–5 server rule

Every connected MCP server injects its tool definitions into context. Connect ten servers and your model spends part of every turn just parsing tool names. The 2026 discipline is:

• Limit active servers to 3–5 per session. A bloated tool list degrades tool-selection quality, because the model struggles to pick among hundreds of near-duplicate names.
• Group tools by intent. Put database tools on one server, notification tools on another, so each server has a coherent, small surface.
• Use programmatic tool calling (scripts, mcp-call, SDK code) for mechanical multi-step flows so results never re-enter context — this is where the ~37% reduction comes from.
• Collapse many endpoints onto one server when possible, as Cloudflare’s Code Mode server does with its ~1,000-token footprint.

Verify and debug your scripted MCP setup

Debugging a scripted MCP pipeline is simpler than debugging native tool calls because everything is a normal process. Check your registered servers with claude mcp list or codex mcp list, and for a given server run claude mcp list <name> for details. In the Codex TUI, /mcp shows live server status.

The three failure modes to plan for:

Because the MCP protocol is line-delimited JSON over stdio, anything a server prints to stdout that is not a protocol message corrupts the stream — the classic “stdout pollution” pitfall when you wrap a chatty server in a script.

Security when scripting MCP

Scripting MCP multiplies your exposure because the agent is now executing arbitrary code that reaches remote servers. The 2026 registry data is sobering:

• 80.5% of remote-capable MCP servers declare no authentication header in their registry metadata — most won’t protect their endpoints (Scalix: State of MCP 2026).
• 62% of official-registry servers were published once and never updated; 22.9% link no source repository (37% for remote-only servers) (dev.to: The MCP Registry by the Numbers).

The translation for scripted MCP: only script against servers you can read, pin to a specific version, and review. Never pipe credentials into mcp-call arguments — use environment-variable expansion in .mcp.json or Codex’s TOML so secrets stay out of shell history and git. Use Codex’s approval_policy (untrusted / on-request / never) and per-tool approval_mode = "approve" for dangerous tools like browser_navigate, and keep sandbox_mode on (Continuum Code: Codex config). For remote endpoints, know whether your OAuth flow downscopes the token, as Cloudflare’s does via OAuth 2.1.

Also remember the protocol is young: only 17,584 of the registry’s remote endpoints use modern streamable-http while 1,073 still sit on deprecated sse, and 54.8% of servers are remote-only versus 38.9% local-only as of June 2026 (Scalix: State of MCP 2026). Prefer streamable-http where you can.

When scripts-over-MCP beat native tools — and when they don’t

The ecosystem is growing without slowing: combined core MCP SDK downloads (npm @modelcontextprotocol/sdk + PyPI mcp + fastmcp) hit roughly 523M per month in September 2026, a fivefold rise in nine months, and the governing Agentic AI Foundation grew from 49 to 247 members with Anthropic, OpenAI, Google, Microsoft, AWS, and Block among its Platinum members (AgentsCamp: MCP ecosystem statistics). That momentum means the “scripts over native calls” pattern will only get smoother — more CLIs, more SDK examples, tighter sandboxing.

FAQ

What does it mean to let a coding agent script call MCP servers? It means the agent runs a command — mcp-call in bash, a one-shot MCP SDK script in Python, or code that Code Mode generates — that invokes MCP server tools. The script is a normal process: it calls tools, pipes results through jq, and orchestrates several servers in one shell flow instead of making many interactive tool calls.

How do I call an MCP server from a bash script? Register the server once (claude mcp add or codex mcp add), then install mcp-cli-skill and run mcp-call <server> <tool> --arg value inside the script. Pipe the JSON output through jq to extract fields and compose the results from multiple servers into one answer.

What is Code Mode MCP in OpenAI Codex? Code Mode is Codex’s code-focused operating mode. For MCP, it means the agent writes the tool-calling code instead of selecting from pre-registered tools — using search() and execute() paths. Cloudflare’s server collapses 2,500+ API endpoints into about 1,000 tokens of context and needs no new tool definitions when products launch.

Is MCP better handled natively or through scripts? Native registration is better for servers used interactively and team-wide, where the model should choose among visible tool schemas. Scripts-over-MCP are better for mechanical multi-step flows because they keep results out of context and reduce token use — Anthropic reports roughly 37% savings on complex multi-step workflows with programmatic tool calling.

Is it safe to script MCP servers? Only if you verify the server. 80.5% of remote-compatible MCP servers declare no authentication, and 62% of registry servers were never updated after publishing. Script only against servers you can read and pin, never put credentials in mcp-call arguments (use environment-variable expansion), and enable Codex’s sandbox and approval policies for dangerous tools.