The Relationship Between AI Agents, Codex, and MCP

Draft A. Drafted with GPT-5.5 Pro.

Codex is an AI agent built for software development work. MCP, or Model Context Protocol, is a communication protocol that lets agents such as Codex connect to external tools, documents, and data through a standard interface.

If the reader already understands LLMs, the starting point is simple: an LLM is close to a reasoning and language-generation engine, while an AI agent is a system that wraps a model with goals, tools, workflow, state, and verification steps so it can complete multi-step work. OpenAI’s agent documentation describes agents as applications that can plan, call tools, collaborate across specialized roles, and maintain state while completing tasks. (developers.openai.com)

What Codex Is

Codex is OpenAI’s AI agent for software development. It is not merely a chatbot that answers coding questions. It is designed to read a codebase, decide what files matter, edit files, run commands, inspect test output, debug failures, review changes, and automate repetitive development work. OpenAI’s Codex documentation describes Codex as a coding agent for software development and lists use cases such as writing code, understanding unfamiliar codebases, code review, debugging, refactoring, testing, and migrations. (developers.openai.com)

The common confusion is this: if an LLM can write code, why call Codex an agent?

The difference is the work loop. A plain LLM call usually has a question-answer shape: the user asks for a fix and the model returns suggested text. An agent can go further. It can inspect the actual project, choose the relevant files, modify them, run tests, respond to failures, and present the final diff. When OpenAI introduced Codex, it described Codex as performing tasks such as writing features, answering codebase questions, fixing bugs, and proposing pull requests in isolated environments prepared with the user’s codebase. (openai.com)

A useful mental model is:

LLM
-> reasoning and language generation
 
Codex
-> a software-development agent that uses an LLM plus files,
   commands, tools, workspace state, and verification loops

This does not mean Codex is an unconstrained autonomous person. Codex works inside the goal, repository, tools, permissions, approval rules, and execution environment available to it.

What MCP Is

MCP stands for Model Context Protocol. It is an open protocol for connecting AI applications to external systems. The MCP documentation describes it as an open standard that lets AI applications connect to local files, databases, search tools, calculators, workflows, and other external systems. (modelcontextprotocol.io)

MCP is not itself an AI model. It does not generate answers, plan work, or fix code. Its job is to define how an AI application discovers tools, calls tools, receives results, reads resources, and uses reusable prompts.

The “USB-C for AI” analogy is useful only as a first approximation. More precisely, MCP is a protocol used between LLM applications and external servers to exchange context, tools, prompts, and results. The MCP specification describes communication between hosts, clients, and servers using JSON-RPC 2.0 messages, and it lets servers provide resources, prompts, and tools. (modelcontextprotocol.io)

The Relationship

Codex and MCP relate as a working agent and a standard interface for external capabilities.

Codex performs software development work. MCP gives Codex a standard way to use more external context and tools. OpenAI’s Codex MCP documentation says MCP connects models to tools and context, and that Codex can use MCP to interact with third-party documentation, browsers, Figma, and other development tools. Codex supports MCP servers in the CLI and IDE extension. (developers.openai.com)

The layers are:

1. The LLM handles reasoning and generation.
2. Codex handles the agent workflow: reading the codebase, editing files, running commands, checking results, and iterating.
3. MCP provides a connection layer to external tools and context.

Examples of MCP-backed capabilities include documentation search, Figma design inspection, browser automation, GitHub issue and pull request context, Sentry errors, and runtime logs. OpenAI lists useful MCP server examples such as OpenAI Docs MCP, Context7, Figma, Playwright, Chrome Developer Tools, Sentry, and GitHub. (developers.openai.com)

The important boundary is:

Codex is the agent doing the work.
MCP is a protocol that lets the agent talk to external systems.

Example Workflow

Suppose the user asks:

Find and fix why the checkout button fails only on mobile Safari.

Without MCP, Codex may still read the local codebase, find relevant components, run tests, and edit files. But a real diagnosis may need external context:

• production errors from Sentry,
• reproduction details from a GitHub issue,
• intended UI behavior from Figma,
• browser behavior from Playwright or Chrome DevTools,
• current documentation for the UI library.

With MCP servers connected, Codex can discover and call these tools through a common protocol instead of using a separate integration style for every service.

The flow becomes:

1. Codex reads the codebase.
2. Codex decides that external context is needed.
3. Codex inspects the MCP tools available in the session.
4. Codex calls the relevant MCP tools.
5. Codex uses the returned context to edit the code.
6. Codex runs tests or browser checks.
7. Codex presents the final change for review.

MCP does not make the judgment. Codex does the planning and interpretation. MCP opens the external capability in a standardized way.

MCP Host, Client, and Server

The word “server” can be misleading. In MCP, a server is not necessarily a large remote cloud service. It may be a local process or a remote service.

The MCP specification separates three roles: a host, a client, and a server. A host is the LLM application that starts the connection. A client is the connector inside the host that communicates with a specific MCP server. A server provides context and capabilities. (modelcontextprotocol.io)

In the Codex context:

MCP Concept	Meaning in a Codex Workflow
Host	Codex CLI or Codex IDE extension
Client	The connection component inside Codex for one MCP server
Server	A program exposing external capabilities such as docs, GitHub, Figma, Sentry, or browser control
Tool	A callable function, such as search issues, fetch documentation, or take a browser screenshot
Resource	Data the agent can read, such as files, docs, logs, or design data
Prompt	A reusable prompt or procedure exposed by the server

An MCP server tells Codex what tools and resources it can provide. Codex decides whether a task needs them.

Codex Can Work Without MCP

Codex is not MCP. Codex is an agent. MCP is a protocol.

MCP is also not Codex-specific. It can be used by Claude, ChatGPT, IDEs, enterprise assistants, and other AI applications. The MCP documentation describes MCP as a standard way to give AI applications and agents access to data sources, tools, and app ecosystems. (modelcontextprotocol.io)

Codex can do many basic coding tasks without MCP: read files, edit code, run commands, and inspect tests inside its working environment. MCP expands the external world Codex can reach. It is best understood as an extension layer, not as Codex’s brain.

Why MCP Matters

As agents become more useful, they need more tool connections. A development agent may need GitHub, Jira, Linear, Sentry, Datadog, Figma, browsers, internal docs, databases, or deployment systems.

Without a standard, every AI product would need separate integrations for every tool:

• a Figma integration for Codex,
• a Figma integration for Claude,
• a Figma integration for Cursor,
• a Figma integration for an internal company agent.

With MCP, a tool provider can expose an MCP server and AI applications can connect through MCP clients. The specification describes MCP as a standard way to share context, expose tools, and compose integrations and workflows. (modelcontextprotocol.io)

MCP reduces the repeated work of connecting every agent to every tool in a different way.

Security Boundary

MCP is powerful because it can expose files, documents, logs, browser control, GitHub, and even command execution. That also makes trust and permission boundaries important.

The MCP specification notes that MCP can provide paths to arbitrary data access and code execution, so users must understand and consent to data access and tool use. (modelcontextprotocol.io)

Codex also lets MCP server tools be allowlisted or blocked, and tool approval modes can be configured. (developers.openai.com)

Adding an MCP server is not just adding convenience. It is giving the agent a new surface area and possibly new authority. The user must decide which MCP servers are trusted, which tools are allowed, and which calls require approval.

Similar Concepts

An LLM is a model that generates text or code. An agent is a system that uses a model to pursue a goal, call tools, maintain state, and complete multi-step work.

ChatGPT is conversation-oriented. It can write and explain code, but Codex is shaped around software development workflows such as reading a repository, editing files, running commands, testing, and reviewing changes.

An API is a service-specific interface. MCP is a protocol that lets AI applications discover and use many external tools in a more uniform way. An MCP server may internally call existing APIs such as GitHub, Figma, or Sentry APIs.

A plugin is usually an extension inside one product. MCP is closer to a common connection protocol between AI applications and external tools.

An MCP server is not the external service itself. A Figma MCP server is an adapter that exposes selected Figma data or actions through MCP.

Core Takeaway

Codex is an AI agent that uses an LLM to read, modify, test, and review code. MCP is a protocol that lets agents such as Codex discover and call external documents, tools, and data sources through a standard interface.