How to connect a Google Slides MCP with Codex (4 steps)

Architecture decisions, technical specs, and system designs often live in slide decks. When developers create a Codex task, they describe what they need in prose, but the slide deck that captured the design decision is the actual source of truth.

Codex writes code against the task description it's given, not against the deck the developer had in mind when they wrote it. That gap shows up in implementation: the module structure doesn't match the architecture diagram, the field names diverge from what the spec slide defined, the data flow logic misses a step that was clearly diagrammed three slides in, and more.

Connecting Google Slides gives Codex direct access to the presentation. When a task requires context from a deck, Codex reads the slides directly rather than relying on whatever the developer thought to include in the task description.

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

How it works

Merge Agent Handler connects Codex to the Google Slides 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 Google Slides.

Once connected, Merge handles OAuth token storage and refresh on your behalf, so you never embed Google credentials in your repo or manage rotation yourself.

Related: How to use the Google Slides 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 Google account with access to the presentations you want Codex to query

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

1. Install the Merge CLI

Install with pipx: pipx install merge-api

Verify it installed correctly: merge --version

2. Log in to Merge

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

This links the CLI to your 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 Google Slides:

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 Slides data. The command is idempotent, meaning it's 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 Google Slides MCP with Cursor

4. Authenticate Google Slides

Create a Codex task that requires live Slides data.

This can be something like: "Read the architecture deck for our payments service and generate the corresponding Go package structure, including file names, package declarations, and interface definitions that match the component diagram."

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

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

{{this-blog-only-cta}}

Google Slides MCP FAQ

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

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

With Google Slides connected, Codex can:

• Read an architecture deck before generating integration code: pull the system design presentation directly so the scaffolded services, interfaces, and dependencies reflect what the architecture slide actually shows, not a developer's prose summary of it

• Pull a requirements deck before scaffolding a feature: retrieve a requirements or product spec presentation so the generated code covers the behaviors, edge cases, and acceptance criteria that the slides define

• Read a data flow diagram slide to generate the corresponding code structure: fetch a deck that diagrams how data moves between systems and use the actual component names, transformation steps, and service boundaries shown to produce accurate code

• Pull a technical spec deck to generate accurate API client code: read a presentation that defines an API contract, field naming conventions, or response structure and generate a client that matches what the spec slide specifies

• Reference an onboarding or standards deck before writing boilerplate: retrieve a presentation that captures team coding conventions, module patterns, or project structure standards so the generated scaffolding conforms to what the team has already agreed on

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

You can build a self-hosted MCP server that calls the Google Slides API directly. For a solo developer, the setup is manageable: create a Google Cloud project, configure OAuth credentials, write tool schemas, and point Codex at the server.

Where it breaks down is at the team level. Google OAuth credentials stored locally carry access to everything the account can reach across Drive and Slides. There are no tool-level controls to limit a Codex task to read-only access or prevent it from reaching presentations outside its intended scope.

At team scale, credential management compounds the problem. Each developer runs their own OAuth setup with no central visibility into what Codex tasks are reading, no consistent way to scope access by project or role, and no clean revocation path when someone leaves.

Merge Agent Handler adds a control layer on top.

You define exactly which operations each agent can call, so a Codex task reading a spec deck never gets access to create_presentation or add_slide unless those tools are explicitly included. Every call is logged with the tool name, inputs, and response metadata.

For teams where slide decks hold unreleased roadmaps, financial data, or architecture decisions that aren't public, that combination of scoped access and audit logging gives you a deployment you can defend.

Why connect Google Slides to Codex?

Most engineering organizations store their architecture decisions, technical specs, and system design context in Google Slides.

Codex doesn't have access to any of that unless a developer manually copies it into the task description.

That manual step is always lossy. Developers paraphrase, omit edge cases, and leave out the detail that turns out to matter. Codex writes against the description, not the original slide.

Connecting Google Slides gives Codex the ability to pull the actual deck when a task requires it. The architecture diagram that defined the service boundaries, the spec slide that called out a non-obvious constraint, the data flow diagram that shows exactly which system owns a transformation: Codex reads the original rather than the developer's interpretation of it.

The output reflects what the decks actually say. That closes the gap between what was designed and what gets built.

Can I use Merge Agent Handler's Google Slides 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 collaboration tools like Google Slides.

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 presentations by role or team
• DLP and policy enforcement on tool calls, so admins can restrict Codex tasks from reading presentations outside their designated project scope or block retrieval of confidential decks before they reach the agent's context
• User-level audit logging so security and IT teams can review which presentations were accessed, which slides were read, by which employee identity, and when

Put together, employees can use the Google Slides MCP to ground Codex tasks in live architecture decks, pull spec presentations before generating code, and reference design decisions captured in slides, while IT keeps centralized control over which presentations each developer's agent can reach.