How to connect a Google Slides MCP to Cursor (4 steps)

Developers building presentation automation tools need to understand the Google Slides API's object model before writing a line of code.

A presentation is a hierarchy of slides, page elements, shapes, text runs, and paragraph styles, each with its own field names and nesting depth. The API documentation describes the structure, but the actual field values, layout identifiers, and placeholder types in a real deck only reveal themselves when you fetch a live presentation.

Getting that reference data today means leaving Cursor, setting up OAuth credentials, running API calls in a separate client, and copying the JSON back into the editor.

To help your developers inspect and generate Google Slides content more easily within Cursor, 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 Cursor to the Google Slides API through the Merge CLI.

Install the CLI, authenticate once, and run a single setup command from your project root.

That command writes a ## Merge CLI section to the project's .cursorrules file, which tells Cursor's agent when to call merge search-tools and merge execute-tool to reach Google Slides.

Once connected, Merge handles OAuth token management so you never store Google credentials locally or configure auth state in the project.

Here's the registration command:

merge setup cursor

Prerequisites

Before getting started, you'll need the following:

• A Merge Agent Handler account
• Cursor installed
• pipx installed (run pipx --version to confirm, or install via pip install pipx)
• A Google account with access to the presentations you want to connect

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

Run the following to install the Merge CLI and confirm it's available: 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 account so it can make authorized requests to Google Slides on your behalf.

Related: How to use a Google Slides MCP in Claude Code

3. Connect the CLI to Cursor

Run the following from the root of the project where you want to use Merge tools: merge setup cursor

This writes a ## Merge CLI section to .cursorrules so Cursor knows to use the CLI for third-party services. The command is idempotent, so it's safe to re-run if you need to reset.

4. Authenticate Google Slides

Open a Cursor chat in your project and start with a query that reflects real development work. For example, "Fetch one of my recent Google Slides presentations and return the full JSON for the first three slides, including all page element fields, text run properties, and shape types, so I can write accurate type definitions for my presentation generation library."

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

{{this-blog-only-cta}}

Google Slides MCP FAQ

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

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

With Google Slides connected, Cursor can:

• Inspect real slide object structures while writing type definitions: fetch a live presentation to see the actual nesting of page elements, shapes, and text runs before writing the interfaces your generation or parsing library depends on

• Pull placeholder type identifiers while implementing template-based automation: retrieve a real deck's placeholder metadata to see which element IDs and placeholder types your template-filling code needs to target before writing it

• Fetch presentation metadata while building a deck search or indexing feature: query presentation titles, slide counts, and thumbnail URLs inline while writing a search or catalog feature, rather than hard-coding assumptions about what the metadata response contains

• Read text run properties while coding a content extraction tool: retrieve the font, size, bold, and color data attached to specific text elements to understand what fields your extraction logic needs to handle across different slide styles

• Check speaker notes structure while implementing a notes-aware summarization tool: fetch slides with their associated notes content to verify the field path your summarization logic needs to traverse before testing it on production decks

• Verify shape and layout field names while writing a slide generation library: pull the element structure of an existing slide with a known layout to confirm that the objectId, size, transform, and style fields your generation code writes match the actual schema

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

You can build a self-hosted MCP server on top of the Google Slides API. For a solo developer generating decks from their own Google account, the setup is manageable: create a Google Cloud project, configure OAuth credentials, write tool schemas, and point Cursor at your local server.

The complications arrive with scope and team use.

Google OAuth credentials stored locally carry access to everything the account can reach across Drive and Slides, not just the decks you intend to expose. There's no tool-level controls preventing an agent from reading presentations it shouldn't access or creating new decks outside the intended scope.

At team scale, every developer runs their own OAuth setup with their own credentials, their own token rotation schedule, and their own version of the tool schemas. There's no central view of what agents are reading or modifying across the team's shared presentations.

Merge Agent Handler adds a control layer on top.

You can define exactly which operations each agent can call: a read-only extraction agent, for example, can only access get_presentation and list_presentations but never reache create_presentation or add_slide unless those tools are explicitly included. Every call is also logged.

For teams where presentations hold roadmaps, financial data, or unreleased product plans, that combination of scoped access and audit logging gives you a deployment you can defend.

Why connect Google Slides to Cursor?

The Google Slides API has a complex object model.

Developers building tools that generate, parse, or modify presentations need to understand the actual field structure of live decks before the code can be correct. Documentation describes the schema in the abstract; a real presentation response shows you the placeholder IDs your template-filling code needs to target, the nesting depth your parser needs to traverse, and the transform values your layout logic needs to produce.

With the Google Slides MCP connected, Cursor can fetch real presentation data inline during a coding session. When you're writing a slide generation library and need to see what a title placeholder's objectId and size fields actually look like, you pull them directly. When you're building a content extraction tool and need to understand how text runs nest inside shapes, you fetch a real deck and read it in the same session where the extractor is being written, and so on.