MCP with OpenAI: Practical Guide to MCP in Apps, API, Agents, and Codex

Model Context Protocol (MCP) in the OpenAI Ecosystem 

The model context protocol (MCP) is an open standard developed by major AI providers, including OpenAI, that standardizes how language models connect to external tools, APIs, and data sources. It acts as a universal adapter, letting AI agents dynamically discover and interact with your local files, databases, or third-party apps.

In OpenAI applications, MCP can be used to give models access to remote servers, connectors, private data sources, and application-specific workflows. An MCP server can expose tools for actions, search and fetch capabilities for retrieving information, and structured outputs that the model can use in a conversation. This makes MCP useful for building ChatGPT apps, API integrations, deep research workflows, and agents that need to work with live business systems.

MCP in the OpenAI ecosystem:

• ChatGPT Apps: Connect ChatGPT apps to external tools and data through MCP servers that expose app capabilities, resources, and interaction logic.
• OpenAI Responses API: Configure hosted MCP servers so the model can discover tools, retrieve external data, and execute approved workflows during a response.
• OpenAI Agents SDK: Build agents that use local or remote MCP servers with support for tool filtering, approvals, tracing, caching, and production governance.
• OpenAI Codex: Extend coding agents with MCP servers that provide access to repositories, documentation, issue trackers, build systems, and internal development tools.

How OpenAI Supports MCP 

MCP in ChatGPT Apps

OpenAI supports MCP to connect ChatGPT apps and API-based applications to external systems through MCP servers. In a ChatGPT app, an MCP server can expose the app’s tools, resources, and interaction logic so the model can understand what the app can do and invoke the right capabilities during a conversation.

Using MCP in a ChatGPT application:

1. Build an MCP server that defines the app’s capabilities as tools. In the Apps SDK, this MCP server is required because it exposes what the ChatGPT app can do.
2. Register tools that return structured data the model can understand. For example, a tool might search a product catalog, fetch account data, create a ticket, or trigger an internal workflow.
3. Add UI templates only when the app needs an interactive interface. ChatGPT Apps can render structured MCP tool results as custom UI components inside an iframe.
4. Test the MCP server locally, then deploy it with HTTPS and the required app metadata.
5. Connect the deployed MCP server to the ChatGPT app so the model can discover the available tools and call them during the conversation.

MCP in the OpenAI Responses API

The OpenAI Responses API supports MCP as a hosted tool integration. Developers can configure an MCP tool by providing details such as the server label, server URL, authorization, and approval requirements. The model can discover tools exposed by the MCP server and call them as part of a response.

This is useful when an application needs the model to interact with an external service during a single reasoning or task-completion flow. For example, the model can use an MCP server to retrieve information from a private knowledge source, query a system, or call an approved workflow. The Responses API can also support approval controls, allowing developers to require confirmation before sensitive tools are executed.

Using MCP in Responses API:

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.5",
    tools=[
        {
            "type": "mcp",
            "server_label": "company_knowledge",
            "server_description": "Searches approved internal company knowledge.",
            "server_url": "https://mcp.example.com/sse",
            "require_approval": "always"
        }
    ],
    input="Find the latest approved positioning for our enterprise product."
)

print(response.output_text)

In this pattern, the application gives the model access to a remote MCP server through the tools array. The server requires a server_url, and the developer can decide whether tool calls are automatic or require approval before execution. This is useful for connecting the model to external systems while keeping sensitive workflows under developer control.

MCP in the OpenAI Agents SDK

The OpenAI Agents SDK supports MCP for building agents that use external tools and context through MCP servers. Agents can connect to hosted MCP tools, remote streamable HTTP servers, legacy HTTP/SSE servers, or local stdio-based servers. This allows developers to reuse existing MCP servers or build new ones for their systems.

The SDK includes controls for production agent workflows. Developers can filter which MCP tools are exposed to an agent, cache tool lists, handle tool failures, pass metadata to tool calls, trace MCP activity, and configure approval flows for sensitive actions. This makes MCP useful for simple tool access and governed, multi-tool agent systems.

Using MCP in OpenAI Agents SDK:

from agents import Agent, Runner
from agents.mcp import MCPServerStreamableHttp

async def main():
    async with MCPServerStreamableHttp(
        name="docs-server",
        params={
            "url": "https://mcp.example.com/mcp"
        }
    ) as mcp_server:
        agent = Agent(
            name="Research Agent",
            instructions="Use the MCP server to search approved documentation before answering.",
            mcp_servers=[mcp_server]
        )

        result = await Runner.run(
            agent,
            "Summarize the deployment requirements for the new integration."
        )

        print(result.final_output)

The Agents SDK can connect agents to MCP servers over multiple transports, including remote streamable HTTP servers and local stdio servers. This allows teams to reuse existing MCP servers for filesystem access, HTTP-backed tools, private connectors, or internal business systems.

For governed production use, expose only the tools the agent needs, cache tool lists where appropriate, and require approval for sensitive tools such as write actions, payments, ticket changes, or administrative operations. The SDK supports approval policies through MCP tool configuration.

MCP in OpenAI Codex

OpenAI Codex supports MCP so coding agents can connect to external development tools, services, and context sources. MCP servers can be configured for Codex through its configuration files, allowing Codex to access additional capabilities during coding workflows. These servers can provide repository-specific tools, documentation access, issue trackers, build systems, internal APIs, or other development resources.

Codex can use MCP server instructions as guidance for working with a server’s tools. This helps define cross-tool workflows, constraints, rate limits, and other operating rules used in software engineering environments. MCP extends Codex beyond local code editing by allowing it to work with the broader development ecosystem in a structured way.

Using MCP in Codex:

1. Open the Codex configuration file. User-level MCP configuration is stored in ~/.codex/config.toml; project-specific configuration can be placed in .codex/config.toml for trusted projects.
2. Add the MCP server configuration. For a remote server, include the server name and URL, and configure authentication if the server requires it.
3. Use OAuth login when supported by the MCP server, or provide the required environment variables for token-based access.
4. Restart or reload Codex so the CLI or IDE extension picks up the new configuration.
5. Ask Codex to use the connected tool during a coding workflow, such as searching internal docs, checking an issue tracker, reading repository-specific guidance, or running a build-related tool.

Example config.toml pattern:

[mcp_servers.internal_docs]
url = "https://mcp.example.com/mcp"

[mcp_servers.internal_docs.env]
DOCS_TOKEN = "your-token-here"

Codex reads MCP server instructions during initialization and uses them as server-wide guidance. These instructions can define cross-tool workflows, constraints, rate limits, and other rules that help Codex use the server correctly in software engineering tasks.

MCP OpenAI vs. OpenAI Function Calling vs. OpenAI Connectors 

In the OpenAI ecosystem, MCP is most useful when teams want a portable, reusable integration layer. An MCP server can expose many tools and data sources through a standard interface, and that server can be reused across different agents, ChatGPT apps, API workflows, or development environments. This fits organizations that want to standardize how AI systems connect to internal APIs, private knowledge bases, workflow systems, developer tools, or enterprise platforms.

OpenAI function calling is narrower and application-specific. Developers define functions directly in their application, provide schemas for the model to follow, and execute the function call in their own code. This is useful for controlled actions such as looking up an order, creating a ticket, running a calculation, or calling a backend API. Function calling gives developers direct control over execution logic, validation, and business rules, but the integration is usually tied to that application rather than exposed as a reusable protocol-based server.

OpenAI connectors connect OpenAI experiences to supported third-party or enterprise services with less custom integration work. They are useful when the goal is to let the model retrieve or work with information from known systems without building a custom tool layer. Connectors can also be used behind MCP-backed workflows, where a hosted MCP server provides standardized access to connector-backed data or tools.

In practice, the three approaches can complement each other. Use function calling when you need tightly controlled, app-specific actions. Use connectors when you want managed access to supported external systems. Use MCP when you want a standardized, reusable, and portable way to expose tools and context across OpenAI agents, ChatGPT apps, API integrations, and other AI systems.

Security Risks of Using MCP With OpenAI 

Overprivileged MCP Tools

Overprivileged MCP tools can give an OpenAI application or agent more access than needed to complete a task. For example, a tool that only needs to search documentation may also have permissions to delete files, modify records, send messages, or access sensitive repositories. If the model is tricked, misinterprets a request, or calls the wrong tool, excessive permissions can turn a minor error into a security incident.

MCP tools can become high-impact execution paths into business systems. A poorly scoped tool may expose sensitive data, enable unauthorized changes, or allow an attacker to move from a prompt-level attack into system actions. To reduce this risk, teams should design MCP tools around least privilege, narrow scopes, read-only defaults, strict input schemas, approval gates for sensitive actions, and detailed logging of every tool invocation.

Prompt Injection and Tool Misuse

Prompt injection occurs when malicious or untrusted content attempts to influence the model’s behavior, override instructions, or cause misuse of an MCP tool. This can happen through web pages, documents, tickets, emails, database records, or any external content retrieved by an MCP server. The model may be instructed to ignore prior rules, leak data, call a tool with unsafe parameters, or perform an action that benefits the attacker.

This risk is significant in MCP-enabled workflows because the model may read external content and act on it. A malicious document could try to make the agent send information to another system, approve a workflow, create a user, modify code, or retrieve unrelated sensitive data. Mitigation requires separating untrusted content from trusted instructions, validating tool arguments, limiting available tools in each context, requiring confirmation for high-risk actions, and monitoring unusual tool-call patterns.

Untrusted or Malicious MCP Servers

An MCP server is part of the trust boundary of the AI application. If a server is untrusted, compromised, or malicious, it can expose deceptive tool descriptions, return manipulated data, request excessive permissions, or provide instructions that steer the model toward unsafe behavior. This is risky when teams install community servers, connect to remote servers, or allow users to configure MCP servers without review.

A malicious MCP server can become a supply chain risk. It may exfiltrate data passed through tool calls, impersonate legitimate tools, hide risky behavior behind harmless descriptions, or change behavior after deployment. Organizations should review MCP servers before use, verify ownership and source code where possible, pin trusted versions, restrict network and credential access, isolate servers at runtime, and maintain an approved catalog of MCP servers for production use.

Best Practices for Using MCP With OpenAI 

1. Start With Narrow, Read-Only Tools

When introducing MCP into OpenAI applications, start with tools that have a narrow purpose and minimal permissions. A tool should do one defined job, such as searching documentation, retrieving a record, or checking workflow status. Avoid broad tools that perform many unrelated actions.

Read-only tools are the safest starting point. They allow the model or agent to gather context without changing external systems. Once the integration is proven, teams can introduce write-capable tools with strict input schemas, scoped permissions, validation rules, and limits on what the model can do.

2. Use Strong Authentication

MCP servers should use strong authentication to ensure that only authorized OpenAI applications, agents, users, or services can access them. Authentication should be tied to the identity and context of the request rather than shared static credentials.

For enterprise deployments, MCP authentication should support secure token handling, expiration, rotation, and revocation. Credentials should not be embedded in prompts, hardcoded into tools, or exposed to the model. Sensitive systems should enforce authorization on the server side, so even if a model requests an action, the MCP server verifies whether it is allowed.

3. Add Human Approval for Sensitive Actions

Sensitive MCP tool calls should require human approval before execution. This is important for actions that change data, send communications, modify permissions, deploy code, delete resources, approve transactions, or access sensitive information. Human approval creates a control point between model reasoning and real-world impact.

Approval flows should match the risk of the action. Low-risk actions may run automatically, while medium- or high-risk actions should present a clear explanation of what will happen, which system will be affected, and what data will be used. This helps prevent accidental misuse, prompt injection outcomes, and unauthorized changes triggered by ambiguous requests or malicious content.

4. Maintain an Approved MCP Server Catalog

Organizations should maintain an approved catalog of MCP servers that are reviewed and trusted for production use. The catalog should include server purpose, owner, supported tools, permission scope, authentication method, data access level, deployment location, version, and maintenance status. This allows teams to reuse MCP integrations without relying on unreviewed servers.

An approved catalog reduces supply chain and governance risks. Before adding an MCP server, teams should review its code or vendor trust posture, validate tool descriptions, assess data access, and confirm compliance with internal security requirements. Deprecated or unmaintained servers should be removed or disabled to prevent tool sprawl.

5. Monitor MCP Activity With SIEM and Behavioral Analytics

MCP activity should be logged and monitored like any other sensitive integration layer. Logs should capture which model, user, agent, server, and tool were involved; arguments passed; results returned; whether approval was required; and whether the action succeeded or failed.

SIEM and behavioral analytics can detect suspicious MCP activity, such as unusual tool invocation patterns, repeated failed calls, access to unexpected data sources, high-volume retrieval, risky parameter combinations, or behavior that differs from normal activity. This is valuable in enterprise environments where MCP servers connect OpenAI applications to sensitive systems, security tools, repositories, or internal knowledge bases.

Monitoring MCP and OpenAI Agent Activity with Exabeam

As organizations connect OpenAI models to MCP servers, AI agents become a new class of non-human identity operating inside business systems at machine speed and scale. Exabeam delivers advanced user and entity behavior analytics (UEBA) that uses AI and automation to help security operations teams detect, investigate, and respond to threats involving users, entities, and AI agents through Agent Behavior Analytics (ABA). By baselining what normal behavior looks like and surfacing risky deviations, Exabeam gives teams the visibility needed to govern MCP-enabled OpenAI agents and the workflows they touch.

Key capabilities of Exabeam UEBA:

• AI agent behavior analytics: ABA extends UEBA to AI agents and other non-human identities, adding behavioral visibility, centralized monitoring, and investigation support so analysts can identify suspicious agent activity and respond with better context.
• Risk-based anomaly detection: New-Scale Analytics builds behavioral baselines and uses business context to refine risk scores, identifying subtle changes across users, entities, and non-human identities; when risk meets a set threshold, a case is opened for investigation.
• Entity context: Attack Surface Insights identifies entities in parsed logs and connects attributes and contextual data to build profiles that strengthen behavioral detections across on-premises and cloud environments.
• Automated investigation timelines: Automated timelines organize related detections chronologically to visualize the full scope of a threat, while activity summaries for anomalies and prebuilt playbooks reduce manual routines so teams respond faster.
• Flexible SIEM augmentation or replacement: New-Scale Analytics runs on top of an existing SIEM to add advanced behavioral analytics, while New-Scale Fusion provides a full-featured platform for a new deployment or a SIEM replacement.

Integrating ABA with Praxen and Observra

To secure AI agents, Exabeam combines runtime analytics with open-source frameworks for telemetry and verification. Integrating Agent Behavior Analytics (ABA) with Praxen and Observra creates a comprehensive security lifecycle for autonomous machine identities.

• Standardizing Agent Telemetry with Observra: Active AI agents generate complex, unstructured activity logs. Observra acts as an open-source SDK and logging library that captures runtime agent operations, including model calls, prompt details, tool usage, system costs, and errors. It normalizes this data into a structured event format, providing the consistent telemetry stream required for advanced threat detection.
• Verifying Agent Policies with Praxen: Before an agent is deployed, Praxen serves as an open-source reference implementation for Agent Behavior Verification (ABV). It compares the declared security policy of an AI agent against its actual underlying code, deployment state, and initial behavioral logs. This ensures that discrepancies, logic flaws, or unauthorized capabilities are flagged before the agent enters production.
• Continuous Behavioral Analysis with ABA: During active operations, the ABA engine ingests normalized telemetry from Observra and leverages the policy baselines established by Praxen. The engine applies machine learning models to build behavioral baselines for each agent, scoring risks and flagging real-time anomalies. If an agent drifts from its intended role, calls unapproved tools, or accesses unauthorized data, ABA immediately raises risk scores and triggers alerts.

This combined approach allows security teams to verify AI agent behavior prior to deployment and maintain continuous, baseline-driven visibility throughout active operations.

Exabeam offers a Model Context Protocol (MCP) server for developers that connects AI assistants directly to public API documentation, enabling teams to explore endpoints, analyze request and response schemas, and generate custom integration code through natural language conversation. In parallel, LogRhythm delivers a community-released SIEM MCP server that runs locally in on-premises environments to bridge security telemetry directly with chosen large language models, allowing analysts to run automated threat-hunting queries, triage active incidents, and summarize security alarms while keeping sensitive security logs inside the private.

To see how Exabeam helps security teams monitor and secure human and AI agent activity across the agentic enterprise, explore Exabeam’s UEBA capabilities. Read our MCP for Developers page to learn more on MCP as well.