How to connect a SharePoint MCP with Codex (4 steps)

When developers create a Codex task, they summarize what they need. But a summary of a compliance spec isn't the same as the spec, and a paraphrase of an API contract isn't the same as the contract.

Codex writes code against what the developer described, not against what the document actually says. The result is implementation that's directionally right but wrong on the details that matter: field constraints, validation rules, the exact behavior the spec called out.

Connecting SharePoint gives Codex direct access to the source material. When a task requires context from a SharePoint doc, Codex can pull the actual file rather than relying on a developer's summary of it.

To give Codex direct access to SharePoint as it works through your coding tasks, we'll show you how to connect SharePoint with Merge Agent Handler's SharePoint MCP server.

How it works

Merge Agent Handler connects Codex to the SharePoint API through the Merge CLI. You install the CLI, authenticate once, and run a single setup command from your project root.

That command writes a Merge CLI section to your project's AGENTS.md file, which tells Codex when to call merge search-tools and merge execute-tool to reach SharePoint.

Once connected, Merge handles Microsoft OAuth credential management and Azure AD token refresh on your behalf, so you never configure an Azure AD app registration or store Graph API tokens locally.

Related: How to use the SharePoint MCP in Claude Code

Prerequisites

Before getting started, you'll need the following:

• A Merge Agent Handler account
• Codex access (available via the OpenAI platform)
• pipx installed (run pipx --version to confirm, or install via pip install pipx)
• A Microsoft 365 account with access to the SharePoint sites you want Codex to read from

If you want to connect Merge Agent Handler's SharePoint MCP with internal or customer-facing agentic products, you can follow the steps in our docs.

1. Install the Merge CLI

Install the CLI with pipx: pipx install merge-api

Verify your installation: merge --version

2. Log in to Merge

Authenticate the CLI with your Merge Agent Handler account: merge login

This links the CLI to your Merge account and stores your session credentials locally.

3. Add Agent Handler to Codex

Run the following from the root of the project where you want Codex to have access to SharePoint:

merge setup agents-md

This writes a Merge CLI section to your project's AGENTS.md file so Codex knows to use the CLI when a task requires SharePoint content. The command is idempotent, safe to re-run if you need to reset the configuration.

Commit the updated AGENTS.md so the configuration travels with the repo.

Related: A guide to integrating the SharePoint MCP with Cursor

4. Authenticate SharePoint

Create a Codex task that requires live SharePoint content.

For example: "Read the incident response runbook from SharePoint and generate a Go function that automates the triage steps it describes, with error handling for each decision point."

The first time Codex invokes a SharePoint tool, a Magic Link will appear to complete connector authentication.

Once authenticated, Codex has access to your SharePoint environment through Merge for all subsequent tasks in this project.

{{this-blog-only-cta}}

SharePoint MCP FAQ

In case you have more questions on setting up and using the SharePoint MCP with Codex, we've addressed several more commonly-asked questions below.

What can you do once the SharePoint MCP is connected to Codex?

With SharePoint connected, Codex can:

• Read a runbook before generating automation code: pull the actual runbook from a SharePoint document library at the start of a task so the generated automation reflects the real steps, decision points, and escalation paths the runbook defines

• Pull a requirements doc to scaffold a new service: retrieve the requirements document from SharePoint before generating the service skeleton so the module structure, inputs, and outputs match what was actually specified

• Read a data schema doc to generate accurate type definitions: fetch the authoritative data schema document from SharePoint and use the field names, types, and constraints it defines to produce type definitions that reflect the real data model

• Pull an API contract to generate a client stub: read the API contract or interface definition from SharePoint before scaffolding the client so method signatures, request shapes, and error handling match what the contract specifies

• Read a compliance spec to generate validation logic: retrieve the compliance requirements document from SharePoint so the validation functions Codex generates enforce the specific rules, thresholds, and conditions the spec calls out

Why use Merge Agent Handler vs. a self-hosted SharePoint MCP server?

You can build a self-hosted MCP server on top of Microsoft Graph API's SharePoint endpoints. For a solo developer with an existing Azure AD app registration, the initial setup is achievable: configure the OAuth scopes, handle token storage, and write tool schemas for the resources you need.

The prerequisite work is non-trivial before any of that happens.

Microsoft Graph requires an Azure AD app registration with SharePoint-specific API permissions, a working OAuth 2.0 flow, and per-user token storage with refresh logic. That's groundwork you complete before writing a single tool schema, and it needs to be replicated for every developer on the team who needs access.

Microsoft offers an official Work IQ SharePoint MCP server, but it requires a Microsoft 365 Copilot license per user. Not every team using Codex against SharePoint content will have or want to provision those licenses for this use case.

Merge Agent Handler handles the Azure AD and OAuth layer without requiring a Copilot license, and adds tool-level scoping on top.

A task that reads runbooks and spec documents gets the appropriate read tools. It never reaches delete or write operations unless explicitly configured. Every tool call is logged with the timestamp, tool name, and inputs.

For teams whose SharePoint environment holds compliance documentation or internal contracts, that combination of scoped access and audit logging matters before you put an autonomous agent near it.

Why connect SharePoint to Codex?

SharePoint is where a significant portion of internal documentation lives: runbooks, compliance specs, API contracts, architecture decisions, requirements docs. Codex doesn't have access to any of that unless a developer manually copies it into the task prompt.

That manual step is always lossy. Developers summarize, paraphrase, and leave things out. Codex writes against the summary, not the source. The result is generated code that misses field constraints, gets validation logic wrong, or scaffolds a service that doesn't match what the requirements document actually specified.

Connecting SharePoint gives Codex the ability to pull source documents directly when a task requires them. The runbook for the automation being coded, the compliance spec driving the validation logic, the API contract the client stub needs to match, etc. and Codex reads the original rather than the developer's interpretation of it.

Can I use Merge Agent Handler's SharePoint MCP with my employees?

Yes, Agent Handler for Employees is built to help engineering organizations provision, secure, and govern how employees connect AI tools like Codex to document repositories like SharePoint.

Common patterns include:

• Provisioning and access control via SCIM with identity providers like Okta and Microsoft Entra ID, so IT can manage which employees can access which SharePoint sites, document libraries, and lists by role or team

• DLP and policy enforcement on tool calls, so admins can block Codex tasks from reading files outside their designated project scope or prevent retrieval of confidential documents before they reach the agent's context

• User-level audit logging so security and IT teams can review which documents were accessed, which runbooks were read, and which content was used as task context, by which employee identity, and when

In practice, employees can use the SharePoint MCP to generate automation from runbooks, scaffold services from requirements docs, and produce validation logic from compliance specs, while IT keeps centralized control over which SharePoint sites and document libraries each developer's agent can reach.